[third_party/pigweed/src] Roll 49 commits

bbcdd74e4ed9487 roll: clang-next
94e4d0343de0191 [fuchsia_infra] Roll 29 commits
c5c79519d115f29 targets/rp2040: Additional bazel build file covera
8404cdab3d652f7 pw_stream_uart_mcuxpresso: Fix unused parameter wa
2eb14f7a17d5b3f pw_clock_tree: Introduce new ClockDivider class
086f478dfaf5958 pw_clock_tree: ClockTree support Element ops
e27b0834c0b4a96 pw_clock_tree: Introduce Element may_block()
b658add873a975a bazel: Explicitly load rules_python in BUILD.bazel
e0af1981782a05e targets/rp2040: Enable thread high water accountin
8c1118fc91c259d rp2040: Renable tests that pass with larger stack
2ee9bbd280bae2f pw_web: Add split/resize view guide in docs
a90dc693295df7a pw_web: Implement split log views with resize
37233cc5c5bdc8d pw_unit_test: Don't execute multiple test suites a
f80cb7eb38f8b1a pw_grpc: Fix warnings in format strings
d1e6ed01ef0eb80 pw_assert: Add missing dep in Android.bp
709debd4945818c docs: Add notes about GitHub Actions
51f54036ba2fc9a pw_build: Add deps support to pw_linker_script
1e0836bd99fd09a pw_allocator: Refactor optional Allocator methods
8b5396011e33fcb docs: Instructions for freertos.BUILD.bazel
38c302a47fda3b8 docs: Create files in current directory
4551fc59f3ea7e1 pw_env_setup: PyPI version bump to 0.0.16
a395729f779fe3e pw_env_setup: Build an extra example pypi distribu
24001c6dc9f34a6 targets/rp2040: Update docs to add missing picotoo
5d11e2666a40e4c targets/rp2040: Save test run log files
fc8c9140a89e057 pw_allocator: Make Init methods infallible
e1cb6243812c803 targets/rp2040: Increase RPC thread stack size to
ffdc28a85c2563e pw_preprocessor: Remove PW_HAVE_FEATURE
0f76642cb22927c OWNERS: Add link to format
e3c80f8354ef2ba freertos: Clarify Bazel documentation
c4cf469a53bed01 pw_allocator: Reduce Block fragmentation
5e6b6c962de2402 pw_allocator: Fix #if PW_HAVE_FEATURE(__cpp_rtti)
83644e88fe7aa51 pw_uart: Add pw_uart to CMakeLists
506466d72aa5cbf pw_channel: Consistent datagram/byte channel alias
cd15ca3178ec45e pw_allocator: Track requested sizes in blocks
cae40e3337b2234 pw_toolchain: Add clang-apply-replacements plugin
a2504dc03eab921 targets/rp2040: Allow using rp2040 devices in boot
f86d3492dd95f8b pw_allocator: Fix Android build
9cb235f1396327e pw_*: Fix typo succesfully->successfully
af6e0482c7015f1 pw_log_basic: Fixing sign conversion error for log
ea9a81f748e5b60 pw_spi_mcuxpresso: Remove unnecessary debug messag
4d84714f44de7d6 pw_cpu_exception_cortex_m: Fix checks for ARMv8
bb558ed3c239189 rp2040: Raise minimal stack size to 1KB
dc5c87c532e5c75 pw_system: Simplify pw_system usage in Bazel
eeec5566194948d targets/rp2040: Refresh target docs
905d4268e336ff1 pw_clock_tree: Generic clock tree management
de0813bee2778fe pw_allocator: Move large values to test fixtures
22a0e55b88e62a5 *: Update Android.bp after GetAlignedSubspan move
6e1b3f4d2039aa1 pw_chre: Update CHRE revision
a13c1efc6afb86f targets/rp2040: Update openocd flashing instructio

https://pigweed.googlesource.com/pigweed/pigweed
third_party/pigweed/src Rolled-Commits: 49dd44fcb1a0b68..bbcdd74e4ed9487
Roller-URL: https://ci.chromium.org/b/8746829530389365681
GitWatcher: ignore
CQ-Do-Not-Cancel-Tryjobs: true
Change-Id: Ib26b913595068f10d3a4010b839eb2671b8ece9c
Reviewed-on: https://pigweed-review.googlesource.com/c/open-dice/+/211791
Lint: Lint 🤖 <android-build-ayeaye@system.gserviceaccount.com>
Bot-Commit: Pigweed Roller <pigweed-roller@pigweed-service-accounts.iam.gserviceaccount.com>
Commit-Queue: Pigweed Roller <pigweed-roller@pigweed-service-accounts.iam.gserviceaccount.com>
1 file changed
tree: 0f4de7544ea5e9662a107faf2fa34487afa136e2
  1. build_overrides/
  2. docs/
  3. dpe-rs/
  4. images/
  5. include/
  6. src/
  7. third_party/
  8. toolchains/
  9. tools/
  10. .clang-format
  11. .gitignore
  12. .gitmodules
  13. .gn
  14. banner.txt
  15. bootstrap.sh
  16. BUILD.gn
  17. BUILDCONFIG.gn
  18. generate_test_values.py
  19. LICENSE
  20. navbar.md
  21. OWNERS
  22. pigweed.json
  23. pyproject.toml
  24. README.md
  25. run_fuzzer.sh
  26. rustfmt.toml
README.md

Open Profile for DICE

This repository contains the specification for the Open Profile for DICE along with production-quality code. This profile is a specialization of the Hardware Requirements for a Device Identifier Composition Engine and DICE Layering Architecture specifications published by the Trusted Computing Group (TCG). For readers already familiar with those specs, notable distinctives of this profile include:

  • Separate CDIs for attestation and sealing use cases
  • Categorized inputs, including values related to verified boot
  • Certified UDS values
  • X.509 or CBOR certificates

Mailing List

You can find us (and join us!) at https://groups.google.com/g/open-profile-for-dice. We're happy to answer questions and discuss proposed changes or features.

Specification

The specification can be found here. It is versioned using a major.minor scheme. Compatibility is maintained across minor versions but not necessarily across major versions.

Code

Production quality, portable C code is included. The main code is in dice.h and dice.c. Cryptographic and certificate generation operations are injected via a set of callbacks. Multiple implementations of these operations are provided, all equally acceptable. Integrators should choose just one of these, or write their own.

Tests are included for all code and the build files in this repository can be used to build and run these tests.

Disclaimer: This is not an officially supported Google product.

Thirdparty Dependencies

Different implementations use different third party libraries. The third_party directory contains build files and git submodules for each of these. The submodules must be initialized once after cloning the repo, using git submodule update --init, and updated after pulling commits that roll the submodules using git submodule update.

Building and Running Tests

Quick setup

To setup the build environment the first time:

$ git submodule update --init
$ source bootstrap.sh
$ gn gen out

To build and run tests:

$ ninja -C out

More details

The easiest way, and currently the only supported way, to build and run tests is from a Pigweed environment on Linux. Pigweed does support other host platforms so it shouldn't be too hard to get this running on Windows for example, but we use Linux.

There are two scripts to help set this up:

  • bootstrap.sh will initialize submodules, bootstrap a Pigweed environment, and generate build files. This can take some time and may download on the order of 1GB of dependencies so the normal workflow is to just do this once.

  • activate.sh quickly reactivates an environment that has been previously bootstrapped.

These scripts must be sourced into the current session: source activate.sh.

In the environment, from the base directory of the dice-profile checkout, run ninja -C out to build everything and run all tests. You can also run pw watch which will build, run tests, and continue to watch for changes.

This will build and run tests on the host using the clang toolchain. Pigweed makes it easy to configure other targets and toolchains. See toolchains/BUILD.gn and the Pigweed documentation.

Porting

The code is designed to be portable and should work with a variety of modern toolchains and in a variety of environments. The main code in dice.h and dice.c is C99; it uses uint8_t, size_t, and memcpy from the C standard library. The various ops implementations are as portable as their dependencies (often not C99 but still very portable). Notably, this code uses designated initializers for readability. This is a feature available in C since C99 but missing from C++ until C++20 where it appears in a stricter form.

Style

The Google C++ Style Guide is used. A .clang-format file is provided for convenience.

Incorporating

To incorporate the code into another project, there are a few options:

  • Copy only the necessary code. For example:

    1. Take the main code as is: include/dice/dice.h, src/dice.c

    2. Choose an implementation for crypto and certificate generation or choose to write your own. If you choose the boringssl implementation, for example, take include/dice/utils.h, include/dice/boringssl_ops.h, src/utils.c, and src/boringssl_ops.c. Taking a look at the library targets in BUILD.gn may be helpful.

  • Add this repository as a git submodule and integrate into the project build, optionally using the gn library targets provided.

  • Integrate into a project already using Pigweed using the gn build files provided.

Size Reports

The build reports code size using Bloaty McBloatface via the pw_bloat Pigweed module. There are two reports generated:

  • Library sizes - This report includes just the library code in this repository. It shows the baseline DICE code with no ops selected, and it shows the delta introduced by choosing various ops implementations. This report does not include the size of the third party dependencies.

  • Executable sizes - This report includes sizes for the library code in this repository plus all dependencies linked into a simple main function which makes a single DICE call with all-zero input. It shows the baseline DICE code with no ops (and therefore no dependencies other than libc), and it shows the delta introduced by choosing various ops implementations. This report does include the size of the third party dependencies. Note that rows specialized from ‘Boringssl Ops’ use that as a baseline for sizing.

The reports will be in the build output, but you can also find the reports in .txt files in the build output. For example, cat out/host_optimized/gen/*.txt | less will display all reports.

Thread Safety

This code does not itself use mutable global variables, or any other type of shared data structure so there is no thread-safety concerns. However, additional care is needed to ensure dependencies are configured to be thread-safe. For example, the current boringssl configuration defines OPENSSL_NO_THREADS_CORRUPT_MEMORY_AND_LEAK_SECRETS_IF_THREADED, and that would need to be changed before running in a threaded environment.

Clearing Sensitive Data

This code makes a reasonable effort to clear memory holding sensitive data. This may help with a broader strategy to clear sensitive data but it is not sufficient on its own. Here are a few things to consider.

  • The caller of this code is responsible for buffers they own (of course).
  • The ops implementations need to clear any copies they make of sensitive data. Both boringssl and mbedtls attempt to zeroize but this may need additional care to integrate correctly. For example, boringssl skips optimization prevention when OPENSSL_NO_ASM is defined (and it is currently defined).
  • Sensitive data may remain in cache.
  • Sensitive data may have been swapped out.
  • Sensitive data may be included in a crash dump.