hw rng attempt to read value from arm64 devices.

[devnexen]

No description provided.

[codecov-commenter]

Codecov Report

Patch coverage has no change and project coverage change: -0.09% ⚠️

Comparison is base (51b06ca) 88.22% compared to head (7ec19e0) 88.13%.
Report is 364 commits behind head on master.

❗ Current head 7ec19e0 differs from pull request most recent head 32940a0. Consider uploading reports for the commit 32940a0 to get more accurate results

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3228      +/-   ##
==========================================
- Coverage   88.22%   88.13%   -0.09%     
==========================================
  Files         617      609       -8     
  Lines       70386    68193    -2193     
  Branches     6818     6797      -21     
==========================================
- Hits        62095    60100    -1995     
+ Misses       5431     5268     -163     
+ Partials     2860     2825      -35     

Files Changed	Coverage Δ
src/lib/rng/processor_rng/processor_rng.cpp	86.11% <ø> (+0.39%)	⬆️
src/lib/utils/cpuid/cpuid.cpp	65.21% <ø> (-22.92%)	⬇️

... and 380 files with indirect coverage changes

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

[randombit]

I don't see any reason to here (or elsewhere in the file) guard against macOS/iOS - if CPUID doesn't indicate support, the code will never be invoked, and the only way CPUID can detect support is with getauxval which doesn't exist on Apple.

[devnexen]

in fact it s more because the assembly does not compile on these.

[randombit]

Oh that's unfortunate.

Maybe instead we can use __builtin_aarch64_rndrrs / __builtin_arm_rndrrs builtins? And then only enable support if the builtins exist.

[devnexen]

ah good point

[randombit]

You'll also need to update processor_rng/info.txt to mark that the code can compile on aarch64

[randombit]

Seems like this is stalled - should we close?

[devnexen]

Seems like this is stalled - should we close?

It s ready for review.

[randombit]

Seems OK but needs to be rebased to address the conflict

[coveralls]

coverage: 91.659% (+0.003%) from 91.656%
when pulling 5568ea8 on hardware_rng_fetch_arm64_linux
into 1a8a90b on master.

[randombit]

src/lib/rng/processor_rng/processor_rng.cpp: In member function ‘virtual void Botan::Processor_RNG::fill_bytes_with_input(std::span<unsigned char>, std::span<const unsigned char>)’:
src/lib/rng/processor_rng/processor_rng.cpp:173:1: error: unrecognizable insn:
  173 | }
      | ^
(insn 55 54 56 10 (parallel [
            (set (reg:DI 132)
                (unspec_volatile:DI [
                        (const_int 0 [0])
                    ] UNSPEC_RNDRRS))
            (set (reg:CC_Z 66 cc)
                (unspec_volatile:CC_Z [
                        (const_int 0 [0])
                    ] UNSPEC_RNDRRS))
        ]) "src/lib/rng/processor_rng/processor_rng.cpp":83:37 -1
     (nil))
during RTL pass: vregs
src/lib/rng/processor_rng/processor_rng.cpp:173:1: internal compiler error: in extract_insn, at recog.c:2770
0x185906c internal_error(char const*, ...)
	???:0
0x6adbf9 fancy_abort(char const*, int, char const*)
	???:0
0x68d0ed _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
	???:0
0x68d10f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
	???:0

We may need a newer compiler here?