aboutsummaryrefslogtreecommitdiff
path: root/util
AgeCommit message (Collapse)AuthorFilesLines
4 daysReapply "Fix test_fips in google3"HEADmasterBob Beck2-22/+26
This reverts commit f01108e4761e1d4189cb134322c3cb01dc71ef87. Change-Id: I323b12966ad7c15602504865ddc4a2c44b948f70 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/69647 Reviewed-by: David Benjamin <davidben@google.com> Auto-Submit: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
4 daysRevert "Fix test_fips in google3"Bob Beck2-32/+23
This reverts commit 26468aea6483135b156fb03a5693c495dbad2e0f. Change-Id: I50951239b4b79544f7e8914a6f86d2b38c098a2d Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/69627 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com> Auto-Submit: Bob Beck <bbe@google.com> Commit-Queue: Bob Beck <bbe@google.com>
4 daysFix test_fips in google3Bob Beck2-23/+32
This makes test_fips build and link even when not building FIPS. (as google3 does). The module hash function is just #defined away to abort() as we won't ever get that far when test_fips is actually run without FIPS. Change-Id: I5d55f0bd1b3f29298aaa6216ebee633e8b4ac6fe Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/69307 Reviewed-by: David Benjamin <davidben@google.com>
8 daysMake BoringSSL initialization-lessDavid Benjamin1-2/+0
Now that we don't depend on external CRYPTO_library_init calls or the static initializer to initialize CPU capabilities, we can drop a ton of code. This makes CRYPTO_library_init, and all its wrappers, into no-ops and drops the (non-FIPS) static initializer. I've added an internal OPENSSL_init_cpuid function for the places where the library actually needs to initialize the CPU vector. Note this slightly changes the default, previously static-initializer-full build: previously, CRYPTO_library_init was a no-op and we relied on the static initializer. Now we uniformly use CRYPTO_once. This should be an atomic read in the steady state and essentially free. We can restore the static initializer by default if this ends up being a problem, but having only one mode is more straightforward. This also avoids problems if an application calls into BoringSSL during its own static initializer. Static initializers are not coherently ordered. Update-Note: The BORINGSSL_NO_STATIC_INITIALIZER build option and CRYPTO_library_init are now unnecessary. Once updating past this revision, those options can now be cleaned up from downstream projects. Fixed: 40644931 Change-Id: Idc2e6ea7a73d6352e0360fd886c46d88dba3568c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/69508 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
8 daystest_fips: two tweaksAdam Langley1-0/+11
1. Ensure that the output is line buffered so that nothing is lost when tests fail. 2. Check that FIPS_mode returns the expected mode so that we have evidence for this during testing. Change-Id: Ib294e890a21e8002d5e2a646f08b49a03e645cb2 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/69487 Auto-Submit: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
9 daysAdd EDDSA support for fetching and uploading vectorsSven Biebaut1-0/+1
As EDDSA is similar to ECDSA with respect to the vectors, the existing ECDSA handling code can be used, avoiding duplications. This modification does not support the 'run' or 'exec' commandline uses. Change-Id: I95f5c3de063539cf881f9116c6e631f4883ef2fd Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/69467 Auto-Submit: Sven Biebaut <svenbiebaut@google.com> Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
10 daystest_fips: don't forget a couple of \n'sAdam Langley1-2/+2
Change-Id: I64c125ca8aaeacb6bc588d2b02be2a5846f481eb Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/69447 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com> Auto-Submit: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-06-10Remove Knights Landing and Knights Mill logicDavid Benjamin1-2/+0
Intel has removed support for Knights Landing and Knights Mill chips (Xeon Phi) from GCC, LLVM, and SDE. The last of which means we can no longer test the special-case to optimize for them. These special cases date to OpenSSL's 64d92d74985ebb3d0be58a9718f9e080a14a8e7f, which describes it as a "salvage operation" because they have Silvermont-like performance issues and "ADCX/ADOX instructions are effectively mishandled at decode time". In principle, this is not very much code to continue "salvaging" them, but we don't like having code we cannot test, so follow Intel's lead in removing all support. With this change, Xeon Phi chips should keep working (assuming their CPUID reports capabilities accurately), but will likely perform much worse. This should unbreak the SDE builders on CI. Change-Id: I00c3c435222fc53c1a6c9fddf961146f837dee7d Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/69187 Commit-Queue: Bob Beck <bbe@google.com> Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2024-06-07Update other CI toolsDavid Benjamin4-7/+7
Change-Id: I6acff65f952a6d96df918d692c1fe8d2ae469ff7 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/69167 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: Bob Beck <bbe@google.com> Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-06-07Allow local labels in symbol expressionsDavid Benjamin4-2288/+2303
Newer GCCs emit code like `.long 3f - 2f`. Change-Id: I0af4d31def5e5ef88251e5f9e3d18944921cd38b Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/69149 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-06-07Handle notrack instructions in delocate outputDavid Benjamin7-1910/+2063
GCC on newer Ubuntu seems to enable this by default now, which is breaking our CI. I haven't yet tested if delocate's output passes CET, but at least we shouldn't mangle the output. Change-Id: Idf035193dba24294b4c59b991e375d74a4f3ab87 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/69148 Reviewed-by: Bob Beck <bbe@google.com>
2024-06-07Update Clang in CIDavid Benjamin1-2/+2
Hoping this will fix MSan in CI, since it picks up the change in https://github.com/google/sanitizers/issues/1614#issuecomment-2010316781 Change-Id: Iab62caed53ec1d0e9fb1bb39b55af420f9c08c75 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/69130 Reviewed-by: Bob Beck <bbe@google.com>
2024-05-30Fix the indentation in gen/sources.bzlDavid Benjamin1-3/+6
It seems that some presubmit in the internal repository is now checking such things. This also means that GN and Bazel don't quite have the same syntax because they have different canonical indentations. Change-Id: Ied7eb69669d1cb00550ff52ecb7a6a6a50501936 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68947 Reviewed-by: Bob Beck <bbe@google.com> Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-05-24Fix the "-with-bazel" branchesDavid Benjamin1-138/+11
Now that the master branch has a Bazel build, the synthesized branches get confused. Rather than introduce more modifications to the synthesized branches, it seems to work to just treat src as a subpackage and alias the targets. Fixed: 733 Change-Id: I667c5266b2924d4f884fc5f76147ace95f878848 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68767 Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: Bob Beck <bbe@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2024-05-23Add error string to JSON test result outputRoland Shoemaker2-8/+15
Useful for third-party bogo users. Change-Id: I8f456c714ca689bed8b6a44e4adb5f9103b994c7 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68747 Commit-Queue: Roland Shoemaker <bracewell@google.com> Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-05-20Expose the FIPS module hash at build- and run-time.Adam Langley2-1/+11
In order to provide evidence that a given build is being used when testing the module (as part of validation), this change prints the module hash during the build process and makes it available for logging at run time. Change-Id: Ib128858cc429655e86444ee86dd04f1467abc735 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68528 Reviewed-by: David Benjamin <davidben@google.com> Auto-Submit: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-05-16Re-add a way to run embed_test_data.go for nowDavid Benjamin1-0/+14
Android have a lot of build systems and we have not yet managed to wrangle all of them to just consume the test data directly. (Apparently passing test data to tests is a great unsolved problem in computer science.) Since this is mostly a backup mechanism now, and we don't want to apply this to *all* Android's builds, this flag works differently from before. Now it just drops crypto_test_data.cc somewhere. It is the caller's responsibility to link this into crypto_test and also build test_support with -DBORINGSSL_CUSTOM_GET_TEST_DATA. Bug: 542 Change-Id: I7faad4fa80dfacfdadd533b3cd7de95bf9e258d4 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68468 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2024-05-15Add crypto_test_data to the AndroidCMake buildDavid Benjamin1-0/+2
This really needs to get unified with the other builds but, in the meantime, go add the source list it will need. Bug: b:340911818 Change-Id: Ie0914becbd28afdd3b0c918a48e80881751f4690 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68467 Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com>
2024-05-14ACVP updates.Adam Langley1-8/+29
Tweaks to the ACVP regcap in light of FIPS 186-5. These are needed for future validations. Change-Id: Ib3d478a21b3ffebbf2ac8aa05a70dc787520087a Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68447 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com> Auto-Submit: Adam Langley <agl@google.com>
2024-05-10Re-remove redundant OPENSSL_IA32_SSE2 from perlasm commandsDavid Benjamin1-3/+3
See https://boringssl-review.googlesource.com/c/boringssl/+/65869. I accidentally reintroduced them with the new tool due to a mismerge. (This doesn't change the output.) Change-Id: I2393d120d5be27355f2cbd7b05a687e65e34dd4a Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68290 Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-05-08Re-apply dilithium and make it work with a limited stackBob Beck1-0/+1
This reverts commit a56407d27da6ebf63ae9817dc19587a0ae98ef4a. On top of this it then makes changes to make dilithium work without consuming excessive stack space.. This makes DILITHIUM_sign and DILITHIUM_generate_key and friends fallible for malloc failures. It removes the abort() calls that were previously present if CBB allocations did not work and rolls them into the malloc failure case. Change-Id: Ibcd70a98bb500c76df8885c0a7d06f8e9f5b18c3 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67027 Commit-Queue: Bob Beck <bbe@google.com> Reviewed-by: Adam Langley <agl@google.com> Reviewed-by: Guillaume Endignoux <guillaumee@google.com> Reviewed-by: Sophie Schmieg <sschmieg@google.com>
2024-05-01[DEPS] Migrate from Chromium git to CIPDAaron Knobloch1-11/+8
The primary reason for this change is to resolve https://crbug.com/boringssl/653. It has the side benefit of having much more performant checkout times ( 1.5 mins to ~10 seconds locally). Note that this change should be transparent to BoringSSL, but there are some minor differences in the packages being pulled. Firstly, we will not have Chromium-local changes. See the changelog here: https://chromium.googlesource.com/android_ndk/+log Additionally, this change goes from the base r23 to r23c. Bug: crbug.com/boringssl/653 Test: Local checkout, then relying on infra Change-Id: Id394eb254d00884c0e9aeb74c2103908c23fb8c3 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68187 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2024-04-26Add a standalone Bazel buildDavid Benjamin6-0/+367
Now that we can generate build files, we can actually maintain a Bazel build in HEAD, without synthesizing a separate "-with-bazel" branch. (Though we'll still need both for a transition, and until all the other build modes have migrated.) Note this has a slightly different directory structure than the old -with-bazel branch. But the targets are the same and #include <openssl/whatever.h> still works, so hopefully it's compatible. For now, I'm only setting this up with the new bzlmod scheme. Also since pulling in googletest is much less tedious with bzlmod, I've wired up tests and everything. https://bazel.build/external/overview#bzlmod To build, run commands like: bazelisk build ... bazelisk test ... bazelisk run :bssl The thinking is we can also go add this to CI and whatnot. This is also intended to replace the boringssl module in the bazel-central-registry which someone else set up already. To ease the transition, I've seeded the compatibility_level value with theirs. (I think we want to never bump it. Although we don't do SemVer, I think bzlmod's MVS version selection scheme is generally reasonable. Bumping it just introduces hiccups into the update process where projects need to coordinate updates, and we do not want that.) I wasn't clear on what to put in the version field in the tree, so I just went with 0.0.0-dev so we don't have to change it, but it's still vaguely analogous to the versions already in there. As part of this, I've added support for Bazel's runfiles mechanism in crypto/test/test_data.cc. This is completely undocumented and I had to figure out how it works by guessing, but I believe this is the officially supported way to make cc_test(data = ...) work? The official documentation says to use devtools_build::GetDataDependencyFilepath, but that API does not exist in the first place. I've also made it build with C++17 for now, so we can build libpki, but C++14 consumers should still be able to use this module, just not build libpki. To that end, one difference between this and the old module is that we no longer specify the C++ version in the build. From what I can tell, Bazel does *not* want libraries to set the C/C++ version and prefers it only come from the root. Unfortunately, they provide zero tools to effectively manage this. I've followed this pattern for C++ versions, as we can assume that Bazel projects are very aware of their C++ version, but I've explicitly ignored it for the C version. Projects tend not to change ABIs by C version, so it should be fine to set it internally. For context when reviewing, the unreadable MODULE.bazel.lock is automatically generated. I think the idea is that subsequent diffs will be more readable?? Bug: 542 Change-Id: I88f68b2602a75f58cc6d18832a956f01dc054f58 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67301 Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: Bob Beck <bbe@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2024-04-04delocate: handle more SVE2 forms.Adam Langley4-841/+1567
After getting further with 672efb1f8e it turns out that there are more SVE2 instruction forms that we need to be able to recognise. Change-Id: Ia180c12ecf702e2c5536adbe1c30ac5ebd43fe75 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65727 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com> Auto-Submit: Adam Langley <agl@google.com>
2024-03-29Install the Windows toolchain under util/botDavid Benjamin1-0/+2
Combined with https://crrev.com/c/5346536, this should, I believe, avoid needing to re-download the toolchains over and over on every CI run once the caches all fill. Change-Id: I4991cf61dd164d7d39da91184ba7051ac59ce3f1 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67347 Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2024-03-29Reflect latest FIPS updates, including 186-5.Adam Langley2-57/+42
Change-Id: Iaa166136b4b7700e59c3a7643ec1b4aacf43c647 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66747 Auto-Submit: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-03-29Update CI build toolsDavid Benjamin4-8/+18
Change-Id: I569110a8648f0504897b9ea94b115cd038149ace Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67327 Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: Bob Beck <bbe@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2024-03-25Update run_android_tests to exit on invalid ABIAaron Knobloch1-1/+1
Change-Id: I3663a5efe1f71192e69e3e04821a481043d145bb Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67467 Commit-Queue: Aaron Knobloch <aknobloch@google.com> Reviewed-by: David Benjamin <davidben@google.com> Auto-Submit: Aaron Knobloch <aknobloch@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-03-23Move fips_fragments into bcm.internal_hdrs in build.jsonDavid Benjamin1-7/+1
This is sliiiightly weird because we can't quite decide whether these are headers with the wrong extension or standalone C files. But since most of our build does the former, I've done this for now. I expect we'll need to iterate on this one a bit. Bug: 542 Change-Id: Ib50332c0804efb5a1aa37fe445f129156260835a Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67300 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2024-03-23Move internal headers to build.jsonDavid Benjamin1-16/+7
CMake doesn't use these, but a lot of our other build systems need it. Bug: 542 Change-Id: I74388751b832921ac121abd3d5755880f352a449 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67299 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-03-23Flatten crypto/CMakeLists.txt into the top-levelDavid Benjamin1-4/+4
This avoids needing to rebase the source lists. It also means that libcrypto.a and libssl.a end up directly in the build directory, which makes it a bit easier to pass it to, say, gcc -L when testing things. That file is, alas, getting a bit large. delocate is a pretty large amount of code. I tried to abstract things into functions to toss into a cmake/delocate.cmake, but CMake is really bad at making abstractions. Bug: 542 Change-Id: I084d7a6bdd4c21ac27859b8b0c9d7a84829f2823 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67298 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-03-23Move crypto_sources to build.jsonDavid Benjamin1-12/+3
Bug: 542 Change-Id: Ie5590a0a68431903587fa87d70c1acac4161e9b9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67297 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2024-03-23Specify public headers in build.jsonDavid Benjamin1-24/+3
The CMake build doesn't use it, but this will be needed for the other builds to be driven by util/pregenerate. Bug: 542 Change-Id: If95cbcef1803e30ffc5ab7c9227fdcc6c53adf34 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67296 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2024-03-23Rework the test data storyDavid Benjamin1-24/+10
We originally embedded test data because of deficiencies in Android's build. Android had no way to specify test data with tests. That has since been resolved, and the embedding mechanism has gotten unwieldy. This unifies pki_test and crypto_test's test data story, and does so in a way that all tests can participate in. (We can now use FileTest in decrepit_test.) Update-Note: This will require some tweaks to downstream builds. We no longer emit an (unwieldy) crypto_test_data.cc file. Instead, tests will expect test data be available at the current working directory. This can be overridden with the BORINGSSL_TEST_DATA_ROOT environment variable. Callers with more complex needs can build with BORINGSSL_CUSTOM_GET_TEST_DATA and then link in an alternate implementation of this function. On the off chance some project needs it, I've kept the embed_test_data.go script around for now, but I expect we can delete it in the future. Fixed: 681 Change-Id: If181ce043e1eea3148838f1bb4db9ee4bfda0d08 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67295 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2024-03-23Move the rest of sources.cmake into util/pregenerateDavid Benjamin1-40/+8
Bug: 542 Change-Id: I23c3c5c01ae41bd98f605b34e09269a6602a2c49 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67294 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-03-22Use source lists to find pki_test data in run_android_tests.goDavid Benjamin4-43/+64
We now have (some of) our test sources in an easily parseable form. run_android_tests.go no longer needs to crawl the source tree. Note this required fixing the .gitignore rules. If a .gitignore line doesn't have a slash at the start or middle, it applies to subdirectories as well. This is confusing, so I just stuck a leading slash in front of all of them. Bug: 681 Change-Id: I389c2a0560594fbd23c60b5b614b0ccfedf28926 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67293 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-03-22Move test data lists to util/pregenerateDavid Benjamin1-3/+3
Since we can now handle glob patterns, make those shorter. Bug: 542 Change-Id: I971d9785bce0db7b2e8c41c8c82468afde64540d Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67292 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2024-03-22Support glob patterns in build.jsonDavid Benjamin2-10/+62
This is primarily in preparation for pki_test's data list. That thing is 80% of source.cmake. glob patterns are normally not great, but since we're checking the result in, that should be fine. Bug: 542 Change-Id: I6ccf69f4a2ce08b153de5eb9dfb2f9b01654e1ce Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67290 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2024-03-22Check in pre-generated perlasm and error data filesDavid Benjamin5-154/+856
This adds a tool for managing pre-generated files, aligning our CMake and non-CMake builds. The plan is roughly: The source of truth for the file lists will (eventually) be build.json. This describes the build in terms of the files that we directly edit. However, we have a two-phase build. First a pregeneration step transforms some of the less convenient inputs into checked in files. Notably perlasm files get expanded. This produces an equivalent JSON structure with fewer inputs. The same tool then outputs that structure into whatever build systems we want. This initial version pre-generates err_data.c and perlasm files. I've not wired up the various build formats, except for CMake (for the CMake build to consume) and JSON (for generate_build_files.py to parse). build.json is also, for now, only a subset of the build. Later changes The upshot of all this is we no longer have a Perl build dependency! Perl is now only needed when working on BoringSSL. It nearly removes the Go one, but Go is still needed to run and (for now) build the tests. To keep the generated files up-to-date, once this lands, I'll update our CI to run `go run ./util/pregenerate -check` which asserts that all generated files are correct. From there we can land the later changes in this patch series that uses this more extensively. My eventual goal is to replace generate_build_files.py altogether and the "master-with-bazel" branch. Instead we'll just have sources.bzl, sources.gni, etc. all checked into the tree directly. And then the normal branch will just have both a CMake and Bazel build in it. Update-Note: generate_build_files.py no longer generates assembly files or err_data.c. Those are now checked into the tree directly. Bug: 542 Change-Id: I71f5ff7417be811f8b7888b345279474e6b38ee9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67288 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-03-20Move ssl and decrepit sources to sources.cmakeDavid Benjamin2-4/+3
Bug: 542 Change-Id: Iec0348555b988f8eb8eb24394a867e015b125c20 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67227 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-03-17Make ninja run_tests output less confusingDavid Benjamin1-1/+1
We say "all tests passed" but we actually mean only the unit tests. Now the output is: Running Go tests ok boringssl.googlesource.com/boringssl/ssl/test/runner/hpke (cached) ok boringssl.googlesource.com/boringssl/util/ar (cached) ok boringssl.googlesource.com/boringssl/util/fipstools/acvp/acvptool/testmodulewrapper (cached) ok boringssl.googlesource.com/boringssl/util/fipstools/delocate (cached) Running unit tests ssl_test [shard 1/10] ... pki_test [shard 8/10] All unit tests passed! Running SSL tests 0/0/5481/5481/5481 PASS ok boringssl.googlesource.com/boringssl/ssl/test/runner 21.110s all_tests.go really should be called unit_tests.go, but renaming it will probably be too annoying. Change-Id: I7ff6684221930e19152ab3400419f4e5209aaf46 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67107 Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: Bob Beck <bbe@google.com>
2024-03-17Filter out DW.ref.__gxx_personality_v0 in read_symbols.goDavid Benjamin1-1/+1
As documented, the symbol prefixing mechanism is experimental and unsupported. There are several corners where we know it doesn't give the correct output. Nonetheless, this is an easy one to fix. Fixed: 707 Change-Id: I69a3e61a3198a193cb90f822218f1efbaa31fb1a Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67067 Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
2024-03-12Fix spelling of IdentifierBob Beck1-1/+1
Make google3 common typos stop complaining in the future. Change-Id: Ib5156335afa691427dbe618c8b29797665cef35f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66947 Auto-Submit: Bob Beck <bbe@google.com> Commit-Queue: Bob Beck <bbe@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2024-03-09Revert "Add a Dilithium implementation."Bob Beck1-1/+0
This reverts commit 9b34a3224062c456ff0d0b77fd9a34c5ad08dfea. Sadly this blow's up google3 because of stack usage being higher than google3's limits Change-Id: I8f1493a158e5fcab508593841ac3a37eb8404dcc Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66847 Auto-Submit: Bob Beck <bbe@google.com> Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-03-06Add a Dilithium implementation.Guillaume Endignoux1-0/+1
This is a reference implementation, not intended to be optimized, but reasonably efficient to be usable and (best-effort) constant time. Change-Id: I47489b566f65e946edd519aa168aee359d1e9f1a Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/63685 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com>
2024-03-06Move spx from internal to include/openssl/experimentalBob Beck1-1/+2
Change-Id: I5c8db3bbca774c7f503538b43f79077421574b0f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66487 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Bob Beck <bbe@google.com>
2024-03-04runner: Use go:embedDavid Benjamin1-13/+0
This removes the need to ship the PEM files with the built runner. Instead we can use go:embed to pick up the key files. We do, annoyingly, need to write the Channel ID file to a temporary, but it's not a huge deal. When/if we rework all this to JSON, we can avoid this. Change-Id: Ie0d187a5396546dc157906430639c26b3cc59ca2 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66627 Reviewed-by: Bob Beck <bbe@google.com> Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: Bob Beck <bbe@google.com>
2024-02-28Generate certs on the fly in runner, pass trusted cert to shimRoland Shoemaker1-10/+1
Rather than using the pre-generated certificates, generate them on the fly. This allows TLS stacks for which certificate validation and verification are coupled to work as expected. Certificates and keys are written to temporary files which are then passed to the shim, and cleaned up on exit. This requires reworking how testCase passes certs/keys by adding a new field, sendCertificate, rather than manually setting the -cert-file and -key-file flags. Incidentally the rsaChainCertificate is removed, since it was essentially unused, and all tests that used it also work with rsaCertificate. Finally, include a single SAN ("test") in all certificates, which fixes some TLS stacks which require this to operate (such as rustls, which currently regenerates all the certificates currently in the tree to add a SAN). Additionally, add a new flag, -trust-cert, which tells the the shim which certificates it should trust. Shims for TLS stacks which can completely decouple validation and verification of X509 certificates (like BoringSSL) can ignore this flag, but for stacks where this functionality is somewhat more intertwined (like Go), this allows the shim to properly process the sent certificates. Change-Id: Ic5c63e18fb2b852cc693aacb3b06cfe7993bc90c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/62565 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2024-02-27Make pki_sources available to SoongChidera Olibie1-0/+1
This allows building libpki in aosp with some changes to the downstream bp file Bug: b/322154153 Change-Id: I68773079ec44929b71c1990d13bd3198a4c57ea7 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66587 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-02-26Finish documenting x509.hDavid Benjamin1-1/+1
It took 3.5 years, but this header is now DONE! I opted to add a section for each extension just because there were so many functions. It's a little weird because, for example, we don't have a section for key usage because it's just BIT STRING. But I think this is better than having a great big "types for built-in extensions" section. Fixed: 426 Change-Id: Ifc7684cc6ff6a211ea1f5065eff67663adf004b3 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66392 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
generated by cgit v1.1 at 2024-06-29 01:49:12 +0000