Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Armv8.5 RNDR as prediction resistance #2029

Open
wants to merge 11 commits into
base: randomness_generation
Choose a base branch
from

Conversation

torben-hansen
Copy link
Contributor

@torben-hansen torben-hansen commented Dec 3, 2024

Description of changes:

Adds Arm as a hardware source for prediction resistance, if supported. This covers Linux+Armv8.5-A that impements rndr. For exmaple, this should be enabled on Graviton3/Graviton4+Amazon Linux.

Call-outs:

Wrap the libcrypto inlined functions to workaround the Arm capability vector having internal linkage.

Apple doesn't implement FEAT_RNG on any of their M's. Might be able to implement for Windows. But I don't see a way to probe for the instruction here https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-isprocessorfeaturepresent.

Added s3_3_c2_c4_0 as a known symbol to the delocator to avoid it from interpreting the string as an external symbol that needs a trampoline... It's not really a symbol... And this was the quickest way to move forward.

Testing:

Tested that the function is executed successfully on a Graviton3 instance. This might also be executed through codebuild depending on which instances are spawned.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and the ISC license.

@codecov-commenter
Copy link

codecov-commenter commented Dec 3, 2024

Codecov Report

Attention: Patch coverage is 70.83333% with 7 lines in your changes missing coverage. Please review.

Project coverage is 78.73%. Comparing base (8d54d64) to head (2b68e5d).

Files with missing lines Patch % Lines
crypto/fipsmodule/rand/entropy/entropy_sources.c 44.44% 5 Missing ⚠️
crypto/fipsmodule/rand/entropy/internal.h 50.00% 2 Missing ⚠️
Additional details and impacted files
@@                    Coverage Diff                    @@
##           randomness_generation    #2029      +/-   ##
=========================================================
- Coverage                  78.74%   78.73%   -0.02%     
=========================================================
  Files                        605      607       +2     
  Lines                     102682   102692      +10     
  Branches                   14563    14564       +1     
=========================================================
- Hits                       80859    80854       -5     
- Misses                     21123    21139      +16     
+ Partials                     700      699       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@torben-hansen torben-hansen marked this pull request as ready for review December 4, 2024 14:40
@torben-hansen torben-hansen requested a review from a team as a code owner December 4, 2024 14:40
crypto/fipsmodule/cpucap/internal.h Outdated Show resolved Hide resolved
CRYPTO_rndr:
cbz x1, .Lrndr_error // len = 0 is not supported
mov x4, x1 // len: requested number of bytes
mov x2, #0 // Counts number of bytes generated
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do you need this? I think you can update x4 until it becomes 0?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's just for a small extra check in the end

cmp x2, x4                  // Ensure correct number of bytes were generated

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know but it seems superfluous to me, couldn't you just check x1 == 0 in the end? that way you could get rid of both x2 and x4

crypto/fipsmodule/rand/asm/rndr-armv8.pl Outdated Show resolved Hide resolved
crypto/fipsmodule/rand/asm/rndr-armv8.pl Outdated Show resolved Hide resolved
mrs x3, s3_3_c2_c4_0 // rndr instruction
cbz x3, .Lrndr_error // Check if RNDR failed

cmp x1, #8 // Sets N if strictly less than 8 bytes left
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what's N?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Condition flags. Input are to be interpreted as unsigned though, so should be checking for C being set and use blo. The case of C not being set is the case where x1 < 8 and we need to handle bit-by-bit.
I changed that.

crypto/fipsmodule/rand/asm/rndr-armv8.pl Show resolved Hide resolved
@torben-hansen torben-hansen requested a review from dkostic December 8, 2024 16:31

open OUT,"| \"$^X\" $xlate $flavour $output";
*STDOUT=*OUT;

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it'd be easier to follow the code if you assigned variable names to the registers you are using. For example:

my ($out, $len, $cnt, $res) = ("x0", "x1", "x2", "x3")

CRYPTO_rndr:
cbz x1, .Lrndr_error // len = 0 is not supported
mov x4, x1 // len: requested number of bytes
mov x2, #0 // Counts number of bytes generated
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know but it seems superfluous to me, couldn't you just check x1 == 0 in the end? that way you could get rid of both x2 and x4

crypto/fipsmodule/rand/asm/rndr-armv8.pl Show resolved Hide resolved
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants