This feature is unused and, if I recall, doesn't actually work. (OpenSSL
1.1.0 or so had to rework the feature significantly.) It would actually
be nice to embed some fields, but I think that's better done by just
switching the parsers to imperative CBS/CBB calls.
One less feature to support in the new parsers.
Bug: 548
Change-Id: If10a0d9f1ba5eb09c7e570ab7327fb42fa2bd987
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56189
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Currently, the only EXTERN type is X509_NAME. Implicitly tagging an
X509_NAME didn't work anyway because of the cached encoding. Moreover,
even if it did work, it'd be invalid. Name in RFC 5280 is actually a
one-element CHOICE type, and CHOICE types can never be implicitly
tagged. So just remove support.
One thing of note: I'm thinking EXTERN can be used later to retain
ASN1_ITEM compatibility, once X509 and friends no longer use the
template machinery. That means we're not only assuming X509_NAME is
never implicitly tagged, but also that external callers using
<openssl/asn1t.h> won't implicitly tag a built-in type.
This removes a case we need to handle in the rewritten tasn_enc.c. (In
particular, crypto/asn1 and crypto/bytestring use a different tag
representation and I'd like to minimum the number of conversions we
need.)
Update-Note: IMPLEMENT_EXTERN_ASN1 can no longer be used outside the
library. I found no callers using this machinery, and we're better off
gradually migrating every <openssl/asn1t.h> user to CBS/CBB anyway.
Bug: 548
Change-Id: I0aab531077d25960dd3f16183656f318d78a0806
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56186
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
I didn't quite handle this case correctly in
https://boringssl-review.googlesource.com/c/boringssl/+/49350, which
made it impossible to express an OPTIONAL, doubly-tagged type in
crypto/asn1.
For some background, an ASN1_ITEM is a top-level type, while an
ASN1_TEMPLATE is roughly a field in a SEQUENCE or SET. In ASN.1, types
cannot be OPTIONAL or DEFAULT, only fields, so something like
ASN1_TFLG_OPTIONAL is a flag an ASN1_TEMPLATE.
However, there are many other type-level features that are applied as
ASN1_TEMPLATE flags. SEQUENCE OF T and SET OF T are represented as an
ASN1_TEMPLATE with the ASN1_TFLG_SEQUENCE_OF or ASN1_TFLG_SET_OF flag
and an item of T. Tagging is also a feature of ASN1_TEMPLATE.
But some top-level ASN.1 types may be SEQUENCE OF T or be tagged. So one
of the types of ASN1_ITEM is ASN1_ITEM_TEMPLATE, which is an ASN1_ITEM
that wraps an ASN1_TEMPLATE (which, in turn, wraps an ASN1_ITEM...).
Such an ASN1_ITEM could then be placed in a SEQUENCE or SET, where it is
OPTIONAL.
We didn't correctly handle this case and instead lost the optional bit.
Fix this and add a test. This is a little interesting because it means
asn1_template_ex_i2d may get an optional bit from the caller, or it may
get one from the template itself. (But it will never get both. An
ASN1_ITEM_TEMPLATE cannot wrap an optional template because types are
not optional.)
This case doesn't actually come up, given it doesn't work today. But in
my pending rewrite of tasn_enc.c, it made more sense to just make it
work, so this CL fixes it and adds a test ahead of time.
Bug: 548
Change-Id: I0cf8c25386ddff992bafae029a5a60d026f124d0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56185
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
All evidence we have points to these devices no longer existing (or at
least no longer taking updates) for years.
I've kept CRYPTO_has_broken_NEON around for now as there are some older
copies of the Chromium measurement code around, but now the function
always returns zero.
Change-Id: Ib76b68e347749d03611d00caecb6b8b1fdbb37b1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56765
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
This is an unexported API, so it's okay to change it. Many extension
types work by parsing a list of key:value pairs and then setting fields
based on it. If a key appears twice, it'll just overwrite the old value.
But X509V3_get_value_int forgot to free the old value when doing so.
Bug: oss-fuzz:55572
Change-Id: I2b39aa7e9214e82fb40ee2e3481697338fe88e1a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56745
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Also add some tests for this syntax. The error-handling here is slightly
subtle. Although we do call GENERAL_NAME_free on the temporary
GENERAL_NAME on error, GENERAL_NAME's value is freed based on the
type field. That means if you add an object to the value but don't set
the type, it won't be freed.
Only the OTHERNAME codepath was affected by this, and a malloc
failure-only case in the is_string path. I've gone ahead and reworked
all the paths so setting the type happens at the same time as setting
the value, so this invariant is more locally obvious.
This only impacts the unsafe, stringly-typed extensions-building APIs
that no one should be using anyway.
Bug: oss-fuzz:55569
Change-Id: I6390e4ac1142264cdc86f95fd850f1b8f81e3fc9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56725
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
One less patch Envoy needs to apply. It should only matter when building
as a shared library on Windows, but the CMake build sets it
unconditionally, so match.
Change-Id: I96a2696d587839048184c448c2324cab836138a4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56726
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Now that all assembly files are conditionalized, we no longer need to
detect platforms at the build level. This is convenient because
detecting platforms in Bazel is a bit of a mess.
In particular, this reduces how much we depend on @platforms being
correct. gRPC's build appears to still be using some legacy modes which
seem cause it to, on cross-compiles, report the host's platforms rather
than the target. See https://github.com/grpc/grpc/pull/31938
gRPC should eventually fix this, but it is apparently challenging due
to complexities in migrating from Bazel's legacy system the new
"platforms" mechanism. Instead, try to sidestep this problem by not
relying on the build to do this.
Now, we primarily rely on os:windows being accurate, and cross-compiling
to/from Windows is uncommon. We do also need os:linux to be accurate
when Linux is the target OS, but if Linux is the host and gRPC mislabels
the target as os:linux, this is fine as long as the target is not
FreeBSD, Apple, or another platform that cares about _XOPEN_SOURCE. (In
particular, Android is ambivalent.)
I've also renamed a few things based on what they were actually
selecting. posix_copts was really copts for toolchains with GCC-style
flags. Unfortunately, it's not clear how to condition on the compiler,
rather than the platform in Bazel, so we'll do the wrong thing on
non-MSVC Windows toolchains, but that was true before.
Bug: 542
Change-Id: I7330d8961145ae5714d4cad01259044230d96bcd
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56465
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
gopls was warning about this.
Change-Id: Ida8ff67bcb9ada253fb075a8a800cbefd432ca8f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56545
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
I assume this came from a bad conversion and then got copy-and-pasted
everywhere.
Change-Id: Id596623608266ce6350d70dff413f38e9fdf13b3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56526
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
gopls currently litters our project with a sea of red, because it
assumes Go files are part of a package, but we have a lot of standalone
Go scripts. (If there are C files in the same directory as the script,
it gets upset about cgo. If there are multiple standalone scripts in the
same directory, it gets uspet about duplicate files.)
Per https://github.com/golang/go/issues/49657 and
https://github.com/golang/tools/blob/master/gopls/doc/settings.md#standalonetags-string,
the convention seems to be a go:build ignore tag. Newer versions of
gopls run in a "standalone" mode, so we still get all the nice LSP
features.
As part of this, I had to align the license header comments from /*
block comments */ to // line comments. Go build constraints can only be
preceded by blank lines and line comments. Block comments apparently
aren't allowed. (See https://pkg.go.dev/cmd/go#hdr-Build_constraints.)
If I leave the file unconverted, go fmt will immediately move the
comment to above the license block.
Change-Id: I47c69255522e9aae2bdb97a6e83fcc6ce0cf29d5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56525
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Having two of these is tedious and I hope, eventually, we can align
them. But for now, sync them manually:
- Bump the minimum CMake versions to match
- Align the C/C++ version directives
- Simplify architecture detection
- Trim some Windows defines that date to our overly aggressive warnings
- Use the Threads package
- Only use _XOPEN_SOURCE on Linux because it's a glibc-specific problem.
I've tested this manually, but we don't particularly test this build
right now (I forget if anyone is even using it), so this is mostly
relying on finding out from others if it breaks something. In the long
term, we should merge the two CMake builds.
Bug: 542
Change-Id: Icccc466464306967275d29a6982c0e9859fc972c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56445
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
CONF_VALUEs are a mess. They show up in three forms:
- When parsed from a config file (in a CONF), I believe name and value
are never NULL.
- Internally, CONF represents sections as funny CONF_VALUEs where name
is NULL, and value is a STACK_OF(CONF_VALUE) of the wrong type. This
is ridiculous and should be a separate type, though I don't believe it
ever leaks outside the public API.
- When created by X509V3_parse_list, it is possible for them to be
value-less, with a NULL value.
v2i functions can see the last case, and set_dist_point_name comes from
a v2i function. Add a missing NULL check. This only impacts the unsafe,
stringly-typed extensions-building APIs that no one should be using
anyway.
Also fix the name of the test I added in the previous CL. I didn't quite
follow the existing convention.
Fixed: oss-fuzz:55558
Change-Id: I1a2403312f3ce59007d23fe7e226f2e602653019
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56705
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
See also upstream's abcf241114c4dc33af95288ae7f7d10916c67db0.
Fixed: oss-fuzz:55555, oss-fuzz:55556, oss-fuzz:55560
Change-Id: I3b015822806ced39a498017bd2329323ed8dfbf0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56685
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Since we started supporting higher tag numbers, this function needed to
call parse_asn1_tag, which is internally bounds-checked.
Change-Id: I19202fb1256240155fa1b53dd31f2b96fd0e8d40
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56188
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
While information is contradictory on this subject, investigation
of several implementaions and Posix appears to indicate that it
is possible to change the behaviour of isdigit() with locale.
Change-Id: I6ba9ecbb5563d04d41c54dd071e86b2354483f77
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56625
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This fuzzes the config file parser, and the converrsion to X.509
extensions. The initial corpus was computed by:
1. Import every file from OpenSSL 1.1.1 that ends in .cnf.
2. For each section in each such file, add a copy with that section
copied to the top (the "default") section.
3. Also add a file for each unit test.
4. Minimize the corpus.
While I'm here, sort the targets in fuzz/CMakeLists.txt.
Change-Id: I0cfc1ae8e2be3e67dae361605ad19833aec3fe4d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56167
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This improves the error-handling and uses CBB instead. It also resolves
a pile of -Wshorten-64-to-32 warnings. It also removes some of the calls
to ASN_put_object within the library.
The parsing uses NUL-terminated strings a bit because several of the
functions called at the end actually rely on the string being
NUL-terminated. Rather than pipe through (ptr, len) versions through
everything, I just used const char * or CBS based on whether the string
could be assumed to have a trailing NUL.
As part of this, I've made it reject [UNIVERSAL 0], matching all our
parsers. Rejecting that value means, since we don't have a nice
Option<T> in C, we can use zero in all the recursive calls to mean "no
implicit tag".
This does tighten the forms allowed for UTCTime a bit. I've disabled
allow_timezone_offset, while crypto/asn1 broadly still allows it. The
reasoning is this is code for constructing new certificates, not
consuming existing ones. If anything is calling this (hopefully not!) to
accidentally generate an invalid UTCTime, it should be fixed.
Update-Note: This code is reachable from the deprecated, string-based
X.509 extensions API. I've added tests for this, so it should behave
generally compatibly, but if anything changes for a caller using these
APIs, this CL is the likely cause. (NB: No one should be using these
APIs. They're fundamentally prone to string injection vulnerabilities.)
Bug: 516
Change-Id: I87f95e01ffbd22c4487d82c89ac098d095126cc1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56166
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
ASN1_BOOLEAN has these ASN1_FBOOLEAN and ASN1_TBOOLEAN variants that
behave slightly strangely. Add some tests to ensure we don't break them
in the rewrite.
In doing so, fix a bug: ASN1_BOOLEAN canonically represents TRUE as
0xff, to match DER. But ASN1_TBOOLEAN is initialized with it->size,
which is 1, not 0xff. Fix it to be 0xff. (This shouldn't actually matter
because the encoder is lax and ASN1_TBOOLEAN doesn't encode TRUE
anyway.)
Bug: 548
Change-Id: I4e7fdc2a3bc87603eaf04a7668359006a1480c2e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56187
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Between the type being sometimes a tri-state and capturing the
underlying DER/BER representation, this type is a bit confusing. Add
constants for these.
I've left a case in ASN1_TBOOLEAN unconverted because it's actually
wrong. It will be fixed in a subsequent CL.
Change-Id: I75d846af14f6b4cd5278c3833b979e89c92c4203
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56487
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
The real isspace may give locale-dependent results, so use our own.
This also lets us simplify some of the silliness asn1_string_canon needs
to go through to never pass high bytes into isspace and islower. (I'm
otherwise leaving that function alone because I plan to, later, convert
the whole thing to CBS/CBB.)
Change-Id: Idd349095f3e98bf908bb628ea1089ba05c2c6797
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56486
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
These values figure into X509_LOOKUP_hash_dir's on-disk format, so they
must remain stable. Record a couple of values to ensure this remains the
case.
Change-Id: I63afa970f8564e0836d78d00375eb5cd6d383bea
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56485
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
This removes TRUST_TOKEN_ISSUER_redeem and renames
TRUST_TOKEN_ISSUER_redeem_raw to TRUST_TOKEN_ISSUER_redeem.
Change-Id: Ifc07c73a6827ea21b5f2b0469d4bed4d9bf8fa84
Update-Note: Callers of TRUST_TOKEN_ISSUER_redeem_raw should remove the _raw.
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56365
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Auto-Submit: Steven Valdez <svaldez@google.com>
We no longer have a need to support ppc64le, nor do we have any testing
story.
Update-Note: BoringSSL no longer supports ppc64le.
Change-Id: I016855e40e9a56f96d6d043fb4f970835eabe3b4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56389
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Inline functions have type signatures, unlike macros. This seems to be
compatible with existing callers and matches OpenSSL 3.0. Additionally,
while Rust bindgen cannot deal with either inline functions or macros
right now, it seems a future version will fix the former.
Change-Id: I6966ff55910cf70e23117fe5f70a0bd286e26d56
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56405
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
We no longer have a need to support ppc64le, nor do we have any testing
story for the assembly we previously had. Remove all ppc64le-specific
assembly.
This CL stops short of removing it from base.h. That'll be done in a
follow-up CL, just to separate which removals are for the assembly and
which removals remove all support.
Update-Note: After this change, ppc64le builds drop assembly
optimizations and will fallback to a generic C-based AES implementation.
Change-Id: Ic8075638085761d66cebc276eb16c4770ce03920
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56388
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
ASN1_generate_v8 has a number of calls to strtoul. strtoul has two
problems for that function.
First, strtoul keeps reading until NUL, but all the functions in that
file act on pointer/length pairs. It's fine because the underlying
string is always NUL-terminated, but this is fragile.
Second, strtoul is actually defined to parse "-1" as
(unsigned long)(-1)! Rather than deal with this, extract the decimal
string parser out of the OID parser as a CBS strotul equivalent.
Change-Id: I1b7a1867d185e34e752be09f8c8103b82e364f35
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56165
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
The ppc assembly opened directly to STDOUT while all the other ones open
to OUT and then reassign *STDOUT. I don't know why this makes a
difference, but only the latter works on Windows.
Bug: 542
Change-Id: I5b21bcf11c356ea4f2b6bc124a4a300bbd13be43
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56386
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Template operator() instead of the type. This fixes converting
subclasses with bssl::UniquePtr. std::unique_ptr<T, D> can be converted
to std::unique_ptr<U, E> requires either D == E or for D to be
implicitly convertable to E, along with other conditions. (Notably T*
must be convertible to U*.)
In the real std::unique_ptr, we rely on std::default_delete<T> being
convertable to std::default_delete<U> if T* is convertible to U*. But
rather than write all the SFINAE complexity, I think it suffices to
move the template down a later. This simplifies SSLKeyShare::Create a
little.
Change-Id: I431610f3a69a72dd9def190d3554c89c2d3a4c32
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56385
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
I'm not sure why I conditioned C11 on non-Clang MSVC. I think I meant to
invert that condition to NOT MSVC OR CLANG. But given that it worked,
just do it across the board.
(Though we support VS2017, which doesn't support a C11 mode, so this is
slightly curious. It may just be that pre-VS2019, this option is a
no-op.)
Change-Id: I271ffd2a913c1aa676fea7ec41f30c1896bb5955
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56325
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This follows up on
https://boringssl-review.googlesource.com/c/boringssl/+/55626, to make
the CMake build rely on the C preprocessor, rather than CMake. While not
as disasterous as pre-@platforms Bazel, CMake's build-level platform
selection is not ideal:
- CMAKE_SYSTEM_PROCESSOR is very inconsistent. There are multiple names
for the same architecture, and sometimes, e.g., building for 32-bit
Windows will still report "AMD64".
- On Apple platforms, there is a separate and technically multi-valued
CMAKE_OSX_ARCHITECTURES. We map that to CMAKE_SYSTEM_PROCESSOR, but
don't support the multi-value case.
Instead, broadly detect whether we expect gas or nasm, and then pull in
every matching file, relying on the C preprocessor to exclude files as
needed. This also fixes a quirk in generate_build_files.py, where it
needed to use the filename to detect the architecture of a perlasm
script in CMake.
This CL only applies to the standalone CMake build. The generated file
lists do not change. I'm not sure yet whether this strategy will be
appropriate for all those builds, so this starts with just the CMake
one.
This hits a pair of nuisances with the Apple linker. First, Apple has
two ways to invoke the linker. The new way is libtool, the old way is
ranlib. Warnings are different between the two.
In both libtool and ranlib, for x86_64 but not aarch64, we get a warning
about files with no symbols. This warning fires for us, but this change
makes it much, much noisier. Oddly, this warning does not trigger when
building for aarch64, just x86_64. I'm not sure whether this is because
aarch64 hits new behavior or it happens that aarch64 object files always
contain some dummy symbol.
libtool has a -no_warning_for_no_symbols flag to silence this warning.
Unfortunately, CMake uses ranlib and there is no way, from what I can
tell, to pass this flag to ranlib. See
https://gitlab.kitware.com/cmake/cmake/-/issues/23551#note_1306698
Since this seems to be a broader CMake limitation, and we were already
living with some of these warnings, I've left this alone. But this CL
does make macOS x86_64 CMake builds very noisy.
I haven't used it here, but LLVM has a pile of CMake goo that switches
CMake to using libtool and passes in that flag. Trialing it out reveals
*different* issue, which I have worked around:
When invoked as libtool, but not as ranlib, the Apple linker also warns
when two object files have the same name. This appears to be a holdover
from static libraries using ar, even though ld does not actually invoke
ar. There appears to be no way to suppress this warning.
Though we don't use libtool, we can probably assume most non-CMake
builds will be using the modern spelling. So I've suffixed each perlasm
file with the OS. This means, in generate_build_files.py, we no longer
need a separate directory for each platform. For now, I've kept that
alone, because some update scripts rely on that spelling to delete old
files.
Update-Note: If the CMake build fails to build somewhere for an
assembly-related reasons, it's probably from this CL.
Bug: 542
Change-Id: Ieb5e64997dc5a676dc30973a220d19015c8e6120
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56305
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
If you pass an empty assembly file into nasm, it crashes. Add a dummy
instruction which the static linker will hopefully dropped. (This is a
no-op unless you try to link all the assembly files together for a
simpler build.)
Bug: 542
Change-Id: Idd2b96c129a3a39d5f21e3905762cc34c720f6b2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56326
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
97873cd1a5 removed the HRSS assembly, but that file was special-cased in
generate_build_files.py and so an update is also needed there.
Change-Id: I3c99989da5faee6b39a3b90fee5fa89c20997c64
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56345
Auto-Submit: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
More than one post-quantum group is now defined so it would be possible
for two PQ groups to be 1st and 2nd preferences. In that case, we
probably don't want to send two PQ initial key shares.
(Only one PQ group is _implemented_ currently, so we can't write a test
for this.)
Change-Id: I51ff118f224153e09a0c3ee8b142aebb6b340dcb
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56226
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
While this assembly implementation is faster in microbenchmarks, the
cache pressure makes it slightly worse than the C code in larger
benchmarks.
Before:
Did 7686 HRSS generate operations in 1056025us (7278.2 ops/sec)
Did 90000 HRSS encap operations in 1010095us (89100.5 ops/sec)
Did 28000 HRSS decap operations in 1031008us (27157.9 ops/sec)
After:
Did 3523 HRSS generate operations in 1045508us (3369.7 ops/sec)
Did 43000 HRSS encap operations in 1017077us (42278.0 ops/sec)
Did 17000 HRSS decap operations in 1011170us (16812.2 ops/sec)
Change-Id: Ia7745b50393f2d2849867e7c5c0af59d651f243d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55885
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
The only callers of this function were reaching into RSA internals.
We cannot fix all the issues with RSA state management when callers do
this. Those have since been fixed, so unexport this function.
Update-Note: This removes a function that can only be used by accessing
one of BoringSSL's private locks.
Change-Id: I0f067b5650ead38d2dbb7302bad4ddd0b2512458
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56286
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
This generator script once lived in Chromium, so we put the Chromium
copyright on the output. But we've long since moved it into BoringSSL,
so use the BoringSSL license header consistently. This avoids an
unnecessary mixed of licenses in the generated branch.
Bug: 542
Change-Id: I813a088d97af9671c8a4d7c9c707ae9d835f0349
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56285
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Some profiling systems cannot unwind with CFI and benefit from having a
frame pointer. Since this code doesn't have enough register pressure to
actually need to use rbp as a general register, this change tweaks
things so that a frame pointer is preserved.
As this would invalidate the SEH handler, just replace it with proper
unwind codes, which are more profiler-friendly and supportable by our
unwind tests. Some notes on this:
- We don't currently support the automatic calling convention conversion
with unwind codes, but this file already puts all arguments in
registers, so I just renamed the arguments and put the last two
arguments in RDI and RSI. Those I stashed into the parameter stack
area because it's free storage.
- It is tedious to write the same directives in both CFI and SEH. We
really could do with an abstraction. Although since most of our
functions need a Windows variation anyway.
- I restored the original file's use of PUSH to save the registers.
This matches what Clang likes to output anyway, and push is probably
smaller than the corresponding move with offset. (And it reduces how
much thinking about offsets I need to do.)
- Although it's an extra instruction, I restored the original file's
separate fixed stack allocation and alloca for the sake of clarity.
- The epilog is constrained by Windows being extremely picky about
epilogs. (Windows doesn't annotate epilogs and instead simulates
forward.) I think other options are possible, but using LEA with an
offset to realign the stack for the POPs both matches the examples in
Windows and what Clang seems to like to output. The original file used
MOV with offset, but it seems to be related to the funny SEH handler.
- The offsets in SEH directives may be surprising to someone used to CFI
directives or a SysV RBP frame pointer. All three use slightly
different baselines:
CFI's canonical frame address (CFA) is RSP just before a CALL (so
before the saved RIP in stack order). It is 16-byte aligned by ABI.
A SysV RBP frame pointer is 16 bytes after that, after a saved RIP and
saved RBP. It is also 16-byte aligned.
Windows' baseline is the top of the fixed stack allocation, so
potentially some bytes after that (all pushreg and allocstack
directives). This too is required to be 16-byte aligned.
Windows, however, doesn't require the frame register actually contain
the fixed stack allocation. You can specify an offset from the value
in the register to the actual top. But all the offsets in savereg,
etc., directives use this baseline.
Performance difference is within measurement noise.
This does not create a stack frame for internal functions so
frame-pointer unwinding may miss a function or two, but the broad
attribution will be correct.
Change originally by Clemens Fruhwirth. Then reworked from Adam
Langley's https://boringssl-review.googlesource.com/c/boringssl/+/55945
by me to work on Windows and fix up some issues with the RBP setup.
Bug: b/33072965, 259
Change-Id: I52302635a8ad3d9272404feac125e2a4a4a5d14c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56128
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
https://boringssl-review.googlesource.com/c/boringssl/+/56109 tried to
simplify the X509V3_CTX story by automatically handling the second half
of initialization, but it turns out not all callers specify both values.
Instead, align with OpenSSL 3.0's behavior. Now X509V3_set_ctx
implicitly zeros the other fields, so it is the only mandatory init
function. This does mean callers which call X509V3_set_nconf before
X509V3_set_ctx will break, but that's true in OpenSSL 3.0 too.
I've retained the allowance for ctx being NULL, because whether
functions tolerate that or not is still a bit inconsistent. Also added
some TODOs about how strange this behavior is, but it's probably not
worth spending much more time on this code.
Change-Id: Ia04cf11eb5158374ca186795b7e579575e80666f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56265
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
The ABI test already uses CHECK_ABI_SEH, so this is covered under tests.
As part of the conversion, we no longer rely on the assembler generating
a specific encoding and can just write the code normally.
Bug: 259
Change-Id: I47cbf81073237f2b95971a782848b85d230b6bf6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56127
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
This implements similar directives as MASM, so we do not need to build
all the structures by hand. It does not provide any help to abstract
between Win64 and SysV differences, however.
This is pulled together from some old draft CLs I had, one of which
actually synthesized CFI directives from SEH, so it should be possible.
I've intentionally omitted that however, as it also brings in questions
about how to handle the calling convention differences (the existing
machinery won't *quite* work). I've uploaded just this for now, so
review can focus on the basic mechanism.
I've also preserved perlasm's weird mixed tabs and spaces indentation
convention for now, though it is a bit tedious.
Bug: 259
Change-Id: Ib3f46a27751a5319b758d12c462c660cf9f3e632
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56126
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
There was a typo and inhibitPolicyMapping updated the wrong value. With
this fixed, we pass the PKITS tests (as imported into Chromium).
Change-Id: I3b80eb56561ae5ae88023fa639d697a9f1757b21
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56205
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
This reimplements policy handling using a similar DAG structure as in
https://chromium-review.googlesource.com/c/chromium/src/+/4111415. The
main difference is that, being C, we don't have std::set or std::map
easily available. But the algorithm can be implemented purely with
sorted lists, while remaining subquadratic.
This implementation relies on two assumptions:
1. We do not return the policy tree. This was removed in
https://boringssl-review.googlesource.com/c/boringssl/+/53327
2. We do not return the final set of certificate policies. I.e.,
certificate policy checking is only used for evaluating policy
constraints and X509_V_FLAG_EXPLICIT_POLICY.
The second assumption is not very important. It mostly simplifies
has_explicit_policy slightly.
In addition, this new implementation removes the per-certificate policy
cache. Instead, we just process the policy extensions anew on
certificate verification. This avoids a mess of threading complexity,
including a race condition in the old logic. See
https://boringssl-review.googlesource.com/c/boringssl/+/55762 for a
description of the race condition.
Change-Id: Ifba9037588ecff5eb6ed3c34c8bd7611f60013a6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56036
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This inline is not defined when OPENSSL_NO_ASM.
Change-Id: I11b90fe4f53281a36674a11dc19c6c61e3afaa68
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56145
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This is purely cosmetic, but makes it consistent with the DW, etc.,
lines in the block above. The SEH unwind code support will emit a mix of
DW and DB directives and this makes them look more consistent.
Bug: 259
Change-Id: Ia16166ab2495aa813d6076d55af5b62511933c28
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56125
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This relaxes two caller requirements:
First, although one needs to initialize X509V3_CTX in two parts, some
callers forget to this. This works some of the time on accident,
because most codepaths read ctx->db. But if one were to read it, it'd
be uninitialized. Since all the entrypoints take a CONF anyway, and
always match them, just implicitly initialize the CONF half of the
X509V3_CTX with the provided one.
Second, allow X509V3_CTX to be NULL. Some codepaths in the library
check for NULL (or don't use it) and some do not. Enough codepaths
don't check that it really cannot be considered to work, but enough
do that a caller could mistakenly pass in NULL and have it mostly
work. I've seen one caller mistakenly do this. Since we have to copy
the X509V3_CTX for the first relaxation anyway, allow it to be NULL
and fill in an empty one when omitted.
Update-Note: If using different CONFs in the X509V3_CTX and the function
parameter, the function parameter is now always used. No callers do
this, and it's somewhat arbitrary which is used. (The generic code
always uses the one in ctx. The @section syntax uses the parameter. Then
the per-extension callbacks use the ctx.)
Change-Id: I9fc15a581ea375ea06c4b082dcf0d6360be8144f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56109
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Squat fewer unprefixed macros.
Update-Note: CTX_TEST appears to be unused. If affected, switch to using
X509V3_set_ctx_test instead.
Change-Id: I43b86c0b6f147bbca85b8bc6b43602fc4f6697c1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56108
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
David Benjamin
Bob Beck
Steven Valdez
Adam Langley
Adam Langley