Add UEFI target support #1406

xiaoyuxlu · 2021-09-30T10:39:16Z

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

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.

build.rs

src/rand.rs

briansmith · 2021-09-30T18:39:29Z

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 · 2021-09-30T18:40:26Z

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

briansmith · 2021-09-30T18:41:07Z

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

xiaoyuxlu · 2021-10-09T05:39:39Z

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

Rust UEFI target `x86_64-unknown-uefi` using BoringSSL's `CRYPTO_rdrand` & `CRYPTO_rdrand_mutiple8_buf` to obtain random numbers under the X86_64 architecture.

Because UEFI needs to be compiled without std in nightly toolchain. So add CI separately.

jyao1 · 2022-01-17T01:26:32Z

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

tiziano88 · 2022-03-29T16:48:43Z

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

…th/ring#1406

Ring has been cloned cloned into third_party, using commit 32b2c6c39ef459aad47f476fe9139b8d57532ab1 from https://github.com/briansmith/ring. This is done so that we will be able to later port our own patch onto it, specifically UEFI compatibility from: briansmith/ring#1406. The cloned version is the unreleased version 0.17, which contains some API changes. Our code has been updated to accomodate them.

Ring has been cloned cloned into third_party, using commit 32b2c6c39ef459aad47f476fe9139b8d57532ab1 from https://github.com/briansmith/ring. This is done so that we will be able to later port our own patch onto it, specifically UEFI compatibility from: briansmith/ring#1406. The cloned version is the unreleased version 0.17, which contains some API changes. Our code has been updated to accommodate them.

Ring has been cloned cloned into third_party, using commit 32b2c6c39ef459aad47f476fe9139b8d57532ab1 from https://github.com/briansmith/ring. This is done so that we will be able to later port our own patch onto it, specifically UEFI compatibility from: briansmith/ring#1406.

* Clone ring from the head of the ring repository into third_party Ring has been cloned cloned into third_party, using commit 32b2c6c39ef459aad47f476fe9139b8d57532ab1 from https://github.com/briansmith/ring. This is done so that we will be able to later port our own patch onto it, specifically UEFI compatibility from: briansmith/ring#1406. * exclude ring from workspace * format * increment cache version

jyao1 · 2022-04-13T11:17:24Z

This has been there for half a year.

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

dnovick · 2022-04-13T11:18:10Z

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

briansmith

Instead of all the rdrand stuff, please add a less-safe-getrandom-rdrand non-default feature to ring. Then change rand.rs so to add UEFI to the lost of supported operating systems/environments if and only if that feature is also enabled.

Presumably then SGX and similar would do likewise.

briansmith · 2023-10-10T18:36:20Z

.github/workflows/ci.yml

+          override: true
+          components: rust-src
+
+      # Currently, there is no 'rust-std' for target 'x86_64-unknown-uefi'.


Is this still the case? Or can we simplify all this now?

briansmith · 2023-10-10T18:36:33Z

Cargo.toml

@@ -82,6 +82,7 @@ include = [
    "crypto/fipsmodule/modes/asm/ghash-x86.pl",
    "crypto/fipsmodule/modes/asm/ghash-x86_64.pl",
    "crypto/fipsmodule/modes/asm/ghashv8-armx.pl",
+    "crypto/fipsmodule/rand/asm/rdrand-x86_64.pl",


This can go away since we'd use getrandom.

briansmith · 2023-10-10T18:36:40Z

build.rs

@@ -64,6 +64,7 @@ const RING_SRCS: &[(&[&str], &str)] = &[
    (&[X86_64], "crypto/fipsmodule/ec/asm/p256-x86_64-asm.pl"),
    (&[X86_64], "crypto/fipsmodule/modes/asm/aesni-gcm-x86_64.pl"),
    (&[X86_64], "crypto/fipsmodule/modes/asm/ghash-x86_64.pl"),
+    (&[X86_64], "crypto/fipsmodule/rand/asm/rdrand-x86_64.pl"),


briansmith · 2023-10-10T18:37:18Z

build.rs

@@ -222,7 +223,7 @@ const ASM_TARGETS: &[AsmTarget] = &[
        preassemble: true,
    },
    AsmTarget {
-        oss: &[WINDOWS],
+        oss: &[WINDOWS, UEFI],


This deserves a comment about why UEFI uses Windows ASM stuff unlike everything else.

briansmith · 2023-10-10T18:37:45Z

build.rs

@@ -381,8 +384,9 @@ fn pregenerate_asm_main() {
        perlasm(&perlasm_src_dsts, asm_target);

        if asm_target.preassemble {
-            // Preassembly is currently only done for Windows targets.
-            assert_eq!(&asm_target.oss, &[WINDOWS]);
+            // Preassembly is currently done for Windows and UEFI targets.


let's just remove the comment since there's now a preassemble field that makes this clear, and it duplicates the assertion below.

briansmith · 2023-10-10T18:38:35Z

build.rs

@@ -460,7 +464,7 @@ fn build_c_code(

        // For Windows we also pregenerate the object files for non-Git builds so
        // the user doesn't need to install the assembler.
-        if use_pregenerated && target.os == WINDOWS {
+        if use_pregenerated && supports_preassembly(&target.arch, &target.os) {


Change this to look at the preassemble field.

briansmith · 2023-10-10T18:38:45Z

build.rs

@@ -554,7 +558,7 @@ fn compile(p: &Path, target: &Target, include_dir: &Path, out_dir: &Path) -> Str
        p.to_str().expect("Invalid path").into()
    } else {
        let out_file = obj_path(out_dir, p);
-        let cmd = if target.os != WINDOWS || ext != "asm" {
+        let cmd = if !supports_preassembly(&target.arch, &target.os) || ext != "asm" {


briansmith · 2023-10-10T18:39:02Z

build.rs

@@ -627,17 +632,25 @@ fn cc(file: &Path, ext: &str, target: &Target, include_dir: &Path, out_file: &Pa
        }
    }

+    // UEFI is a baremental freestanding environment without stdlib.
+    let freestanding = target.os == UEFI;


Is this still true? I heard there is a libstd now.

briansmith · 2023-10-10T18:39:44Z

build.rs

+    let mut c = Command::new(&get_command(
+        "NASM_EXECUTABLE",
+        "./target/tools/windows/nasm/nasm",
+    ));


Please move this to a separate PR.

briansmith · 2023-10-10T18:42:47Z

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 · 2023-10-13T01:22:59Z

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 · 2023-12-30T19:43:14Z

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: rust-random/getrandom#199)

Best,

briansmith requested changes Sep 30, 2021

View reviewed changes

build.rs Outdated Show resolved Hide resolved

build.rs Outdated Show resolved Hide resolved

build.rs Outdated Show resolved Hide resolved

build.rs Outdated Show resolved Hide resolved

src/rand.rs Outdated Show resolved Hide resolved

xiaoyuxlu force-pushed the upstream/uefi_support branch from 8379e3e to 7d7c8b9 Compare October 13, 2021 01:28

xiaoyuxlu requested a review from briansmith October 13, 2021 01:45

Xiaoyu Lu added 3 commits October 19, 2021 09:16

UEFI target support: Prepare rand_impl for uefi target

df48d32

Rust UEFI target `x86_64-unknown-uefi` using BoringSSL's `CRYPTO_rdrand` & `CRYPTO_rdrand_mutiple8_buf` to obtain random numbers under the X86_64 architecture.

Add UEFI target support

e98c5df

Add UEFI target in CI/CD

c3598c9

Because UEFI needs to be compiled without std in nightly toolchain. So add CI separately.

xiaoyuxlu force-pushed the upstream/uefi_support branch from 9776f47 to c3598c9 Compare October 19, 2021 03:12

This was referenced Feb 22, 2022

Allow the remote_attestation crate to be buildable on x86_64 UEFI targets project-oak/oak#2557

Closed

Make remote_attestation crate no_std compatible project-oak/oak#2556

Merged

jul-sh added a commit to jul-sh/oak that referenced this pull request Apr 4, 2022

Make ring UEFI compatible using the version from on open PR: briansmi…

b50fac9

…th/ring#1406

jul-sh mentioned this pull request Apr 4, 2022

Make our remote attestation crate UEFI compatible using the ring version from on open PR project-oak/oak#2659

Closed

jul-sh mentioned this pull request Apr 4, 2022

Use vendored version of ring in remote attestation project-oak/oak#2661

Merged

jul-sh mentioned this pull request Apr 5, 2022

Clone ring from the head of the ring repository into third_party project-oak/oak#2681

Merged

This was referenced Apr 6, 2022

Build remote attestation for UEFI project-oak/oak#2693

Merged

Test remote attestation in UEFI app project-oak/oak#2703

Merged

briansmith requested changes Oct 10, 2023

View reviewed changes

This was referenced Oct 10, 2023

Is there a way to use ring with os=none, for random ? #1380

Closed

Document how to port *ring* to a no_std-only platform #744

Open

Port to SGX #775

Open

Add support for x86_64-fortanix-unknown-sgx target #738

Closed

briansmith mentioned this pull request Oct 13, 2023

provide a mechanism to mark a custom getrandom implementation as being SecureRandom #1734

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add UEFI target support #1406

Add UEFI target support #1406

xiaoyuxlu commented Sep 30, 2021 •

edited

briansmith left a comment

briansmith commented Sep 30, 2021

briansmith commented Sep 30, 2021

briansmith commented Sep 30, 2021

xiaoyuxlu commented Oct 9, 2021 •

edited

jyao1 commented Jan 17, 2022

tiziano88 commented Mar 29, 2022

jyao1 commented Apr 13, 2022

dnovick commented Apr 13, 2022

briansmith left a comment

briansmith Oct 10, 2023

briansmith Oct 10, 2023

briansmith Oct 10, 2023

briansmith Oct 10, 2023

briansmith Oct 10, 2023

briansmith Oct 10, 2023

briansmith Oct 10, 2023

briansmith Oct 10, 2023

briansmith Oct 10, 2023

briansmith commented Oct 10, 2023

xiaoyuxlu commented Oct 13, 2023

hugusmaximus commented Dec 30, 2023 •

edited

Add UEFI target support #1406

Are you sure you want to change the base?

Add UEFI target support #1406

Conversation

xiaoyuxlu commented Sep 30, 2021 • edited

build.rs:

rand.rs:

briansmith left a comment

Choose a reason for hiding this comment

briansmith commented Sep 30, 2021

briansmith commented Sep 30, 2021

briansmith commented Sep 30, 2021

xiaoyuxlu commented Oct 9, 2021 • edited

jyao1 commented Jan 17, 2022

tiziano88 commented Mar 29, 2022

jyao1 commented Apr 13, 2022

dnovick commented Apr 13, 2022

briansmith left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

briansmith commented Oct 10, 2023

xiaoyuxlu commented Oct 13, 2023

hugusmaximus commented Dec 30, 2023 • edited

xiaoyuxlu commented Sep 30, 2021 •

edited

xiaoyuxlu commented Oct 9, 2021 •

edited

hugusmaximus commented Dec 30, 2023 •

edited