Add UEFI target support

[xiaoyuxlu]

build.rs:

ABI of rust UEFI target x86_64-unknown-uefi is like windows. So add an AsmTarget like windows and it also need preassemble.

Currently must use Clang to compile c code for rust UEFI target.

rand.rs:

use rdrand-x86_64.pl from BoringSSL to generate random numbers.

[briansmith]

Since we need to force clang for this target, mk/install-build-tools.sh can be modified here to add this target:

--target=i686-unknown-linux-musl|--target=x86_64-unknown-linux-musl)
  use_clang=1

Please make the analogous change in mk/cargo.sh.

This should make CI work and will also make it easier for anybody, especially me, to build locally.

[briansmith]

Does CPUID work reliabily (as expected) in the UEFI environment?

[briansmith]

Also, are there any limitations or special considerations on CPU features (AVX2, AES-NI, etc.) for the EUFI environment?

[xiaoyuxlu]

A few days ago was China National Day. Sorry for the late reply. I appreciate you for watching the pull request carefully and give a lot of comments.

I will continue to work on it and make this patch better.

Thanks for this.

In .github/ci.yml where have some blocks like this:

          - target: aarch64-apple-darwin
            host_os: macos-latest
            # GitHub Actions doesn't have a way to run this target yet.
            cargo_options: --no-run

Please add an analogous one for the x86_64 UEFI target.

Similarly there is:

        target:
          - aarch64-apple-ios
          - ...
          - x86_64-unknown-linux-gnu

Add the x86_64 UEFI target to that.

Also, could you point me to a way that we could emulate the UEFI environment well enough to run tests? It would be ideal if we could get this emulated environment working in GitHub Actions, but if this is a large amount of work, we can go with the build-only approach for now.

Currently, I don't have a good way to run tests. I will try to find a way. I think we can build-only for now.

Does CPUID work reliabily (as expected) in the UEFI environment?

I think so. UEFI environment always run in long-mode, in x86_64 it always run in 64bit.

Also, are there any limitations or special considerations on CPU features (AVX2, AES-NI, etc.) for the EUFI environment?

There is no special things. REF: https://github.com/rust-lang/rust/blob/master/compiler/rustc_target/src/spec/x86_64_unknown_uefi.rs#L15

[jyao1]

@briansmith, would you please review this patch to see if there is any other comment?

[tiziano88]

This patch would be useful to us too as part of https://github.com/project-oak/oak , is there anything in particular that is blocking it? Can we help resolve it? Thanks @xiaoyuxlu and @briansmith for the work so far

[jyao1]

This has been there for half a year.

@briansmith, would you please review this patch to see if there is any other comment?

[dnovick]

Just wondering what the status of this pull request is. Are there any blocking issues remaining? Thanks.

[briansmith]

This is a very old PR. If you were to rebase it onto today's main, most of it would go away as explained above. If/when this is ready, I will release a 17.x update that adds UEFI support.

[xiaoyuxlu]

This is a very old PR. If you were to rebase it onto today's main, most of it would go away as explained above. If/when this is ready, I will release a 17.x update that adds UEFI support.

You're right. Will do. Thank you very much.

[hugusmaximus]

Hi there! I'm not a developer nor I am too familiarized with some specific OS internals and faced a problem trying to compile "tiny_http" crate with "rustls" support on a aarch64 platform and Hermit (https://github.com/hermit-os/hermit-rs/tree/main) unikernel. After reading this thread I think I may be facing the same problem as other people trying to compile on other platforms... This is my error:

error[E0425]: cannot find function `fill_impl` in this scope
   --> /home/hugo/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ring-0.16.20/src/rand.rs:160:9
    |
160 |         fill_impl(dest)
    |         ^^^^^^^^^
    |
help: you might have meant to call the method
    |
160 |         self.fill_impl(dest)
    |         +++++

For more information about this error, try `rustc --explain E0425`.
error: could not compile `ring` (lib) due to 1 previous error

@briansmith does the release 17.x of ring solve my problem too? Any hint on how I need to proceed to solve that? Does it require intervention of the developer of Hermit OS?

(Edited: found this in case this can help: https://github.com/rust-random/getrandom/issues/199)

Best,