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>
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>
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>
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>
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>
Functions typically just push their own error codes.
Change-Id: Iac83bfdf56ce436bd3a9b8af5c43ca67fb4b9b15
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56107
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Our NCONF_get_section doesn't silently handle NULLs, so add a check to
the caller.
Change-Id: I133d10c7a5dec22469a80b78cb45f479f128ada2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56106
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
And specifically that it also counts at the leaf, which was a bug I'd
nearly introduced. (RFC 5280 is written somewhat confusingly. The
wrap-up and prepare procedures have some duplicate processing.)
Change-Id: Iea901b96f64e12199fec426dc936bfbde16f88a4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56035
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Such mappings should be ignored.
Change-Id: Ic75d3c17e3f2d25da75b15d59e38177f9bc1c044
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56034
Reviewed-by: Matt Mueller <mattm@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
There is no Kyber implementation in BoringSSL so these stubs assume that
you are locally patching such an implementation in.
Change-Id: I274b9a93e60f0eb74301c8d58f05c235687643e1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55930
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Cost: 6.3KiB, based on the size of the .o file. (The bssl tool size
doesn't really change, probably due to padding somewhere.)
This code originally came from ARM but David has merged the AES-128 and
AES-256 specific code into a function that works across AES sizes.
Speeds from an M1 Pro:
Did 16546000 AES-128-GCM (16 bytes) seal operations in 1000018us (16545702.2 ops/sec): 264.7 MB/s
Did 10450500 AES-128-GCM (256 bytes) seal operations in 1000011us (10450385.0 ops/sec): 2675.3 MB/s
Did 2822500 AES-128-GCM (1350 bytes) seal operations in 1000042us (2822381.5 ops/sec): 3810.2 MB/s
Did 547000 AES-128-GCM (8192 bytes) seal operations in 1000826us (546548.6 ops/sec): 4477.3 MB/s
Did 279000 AES-128-GCM (16384 bytes) seal operations in 1000411us (278885.4 ops/sec): 4569.3 MB/s
Did 16991250 AES-256-GCM (16 bytes) seal operations in 1000001us (16991233.0 ops/sec): 271.9 MB/s
Did 9257000 AES-256-GCM (256 bytes) seal operations in 1000072us (9256333.5 ops/sec): 2369.6 MB/s
Did 2398000 AES-256-GCM (1350 bytes) seal operations in 1000002us (2397995.2 ops/sec): 3237.3 MB/s
Did 465000 AES-256-GCM (8192 bytes) seal operations in 1001108us (464485.4 ops/sec): 3805.1 MB/s
Did 240000 AES-256-GCM (16384 bytes) seal operations in 1002704us (239352.8 ops/sec): 3921.6 MB/s
Did 16670000 AES-128-GCM (16 bytes) seal operations in 1000054us (16669099.9 ops/sec): 266.7 MB/s
Did 11450750 AES-128-GCM (256 bytes) seal operations in 1000014us (11450589.7 ops/sec): 2931.4 MB/s
Did 3830000 AES-128-GCM (1350 bytes) seal operations in 1000097us (3829628.5 ops/sec): 5170.0 MB/s
Did 790000 AES-128-GCM (8192 bytes) seal operations in 1000379us (789700.7 ops/sec): 6469.2 MB/s
Did 400000 AES-128-GCM (16384 bytes) seal operations in 1000980us (399608.4 ops/sec): 6547.2 MB/s
Did 16877000 AES-256-GCM (16 bytes) seal operations in 1000052us (16876122.4 ops/sec): 270.0 MB/s
Did 10438000 AES-256-GCM (256 bytes) seal operations in 1000067us (10437300.7 ops/sec): 2671.9 MB/s
Did 3419000 AES-256-GCM (1350 bytes) seal operations in 1000158us (3418459.9 ops/sec): 4614.9 MB/s
Did 698000 AES-256-GCM (8192 bytes) seal operations in 1000557us (697611.4 ops/sec): 5714.8 MB/s
Did 355000 AES-256-GCM (16384 bytes) seal operations in 1001900us (354326.8 ops/sec): 5805.3 MB/s
Change-Id: Id88f6e14482f09591fe95145bf4089de1ab68380
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55926
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
They don't work because ASN1_mbstring_ncopy doesn't recognize them.
Change-Id: Id036252f4c6790714a73c5d0666149e13050fd4a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56105
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This aligns with upstream OpenSSL, so it's hopefully more compatible.
Code search says no one outside of the project uses this function, so
it's unlikely to break anyone.
Whether it makes things better is a bit of a wash: OBJ_dup and
OPENSSL_strdup loose a pointless wrapper. X509_NAME_dup gains one, but
hopefully that can be resolved once we solve the X509_NAME
const-correctness problem. CRYPTO_BUFFER_up_ref gains one... really
FOO_up_ref should have type const T * -> T *, but OpenSSL decided it
returns int, so we've got to cast.
Change-Id: Ifa6eaf26777ac7239db6021fc1eafcaed98e42c4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56032
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
These APIs should not be used, but far too many callers use them. In the
meantime, at least test this behavior (so it can be rewritten) and write
down why it should not be used.
In doing so, I noticed that we actually broke some cases in the
ASN1_generate_v3 logic. I think it broke in
https://boringssl-review.googlesource.com/c/boringssl/+/48825. But since
no one's noticed, I've just kept it broken.
Bug: 430
Change-Id: I80ab1985964fc506c8aead579c769f15291b1384
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56029
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
We've removed them in other files.
Change-Id: I14ea99c85fd3a21094beeac88cb669e7aa9e2763
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56028
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Constructing extensions from a config file should not modify the config
file or input certificates, so everything here should be const.
While I'm here, fix various missing sk_FOO_push malloc failure checks.
Change-Id: Ic29b21248a9d9243050c771fd0ce1e1d77f7ce7f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56027
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
In the X.509 policy rewrite, I'll be using sorted stacks to keep the
overall algorithm subquadratic. Fix up sk_FOO_is_sorted in these edge
cases so the asserts work more smoothly.
Change-Id: I369f53543f0c2219df6f62a81aead630a9dbcd8d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56031
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This adds function to allow for issuing and redeeming tokens derived
from a particular message rather than a completely random nonce.
Change-Id: Ia29ae06ca419405ffff79ab6defadbed4f184b29
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55565
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Nothing external ever defines X509V3_CONF_METHOD. Removing this allows
us to remove X509V3_section_free altogether because the returned
sections are always owned by the CONF object anyway.
For ease of review, I've split out some of the const-correctness to a
follow-up CL.
Update-Note: X509V3_CONF_METHOD is removed. Code search says no one uses
this.
Change-Id: I66ed6e978b85d40c6849e9f4f45e1bcbf9a0f6a9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56026
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
These are used inside the various extension implementations and aren't
used outside the library. In doing so, delete a bunch of functions that
aren't used anyway.
Change-Id: I7e4d049682155d20b8ae9bd7c239be96c1261d98
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56025
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
This is currently called "aesni", but a following change will add
support on Aarch64. This change thus makes the naming more generic.
Change-Id: I6acb135a91e61570ea250f2f4133b47f11cd51ad
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55865
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
(Unclear if we'll get the security policy in docx format this time but
it's always on NIST's site in PDF form.)
Change-Id: I831738b36873c7adafcc74d02748f69c1e94f501
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55931
Auto-Submit: Adam Langley <agl@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
anyPolicy causes crypto/x509 to synthesize policy nodes in places. Add
some test coverage for this.
Change-Id: I1b1dcba35088d6cabce6b40e36e478ec4756effa
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55753
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
If a certificate has policy constraints, but the certificate policies
extension is either missing or unsuitable (in a way not caught by the
parser), the policy constraints object is leaked.
As part of this, add some basic tests for policy constraints.
Change-Id: I4a2c618019d1f92b0f3b9ad4cf6e29d4926e3095
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55752
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
X509 objects do some deferred parsing. Make sure we cover that code with
fuzzers.
Change-Id: I618e90aaf4d8decbc3af59f36910feb9949a8cd2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55751
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
X509_policy_check returns -1 if some certificate had an unparseable
extension, in which case it sets EXFLAG_INVALID_POLICY on it. The
calling code then iterates over the certificates to find the offending
one, so the callback has a chance to undo it. But it skips i = 0, the
leaf, and instead just silentely returns success.
We really should cut down on the callback's ability to mess things up
here but, in the meantime, fix this. Also add a test covering this case.
While I'm here, I've updated make_invalid_extensions.go, which I pulled
some code from, to rename fooOrPanic to mustFoo. That seems to be the
convention in the Go standard library. (regexp.MustCompile, etc.)
Change-Id: Ib07c9f4175e66483bd7c0f7d49aea931bf36e53f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55748
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
David Benjamin
Steven Valdez
Adam Langley
Adam Langley
Ilya Tokar