Since edk2-stable202511, the default OpenSSL security level has been
raised from 0 to 3, which rejects older RSA-based keys. Unfortunately,
the EDK2 aarch64 build forcefully disables all EC-based keys
(-DEDK2_OPENSSL_NOEC=1), effectively preventing connections to most
HTTPS/TLS hosts. Temporarily disable this test on aarch64 until EC-based
keys are supported there.
We do not have control over the TLS certificates of these hosts. To
ensure non-flaky tests, we add a list of potential hosts where at least
one must succeed.
## TL;DR
Switch from https://raw.githubusercontent.com to https://example.com
as GitHub's host is currently not accepted by OpenSSLs security level 3
(was 0 in older edk2).
## Root cause
The failure is not caused by a stale `cacerts.bin` or by a missing OVMF
TLS build option. It is caused by edk2 commit
`fb43f0c085045771bc2dee2f867d87298de2facb` (2025-09-19):
```text
CryptoPkg: Add support to set TLS security level.
```
That commit changed `CryptoPkg/Library/TlsLib/TlsInit.c` from:
```c
SSL_set_security_level (TlsConn->Ssl, 0);
```
to:
```c
SSL_set_security_level (TlsConn->Ssl, 3);
```
OpenSSL security level 3 rejects RSA end-entity certificates below 3072
bits. `raw.githubusercontent.com` currently serves a 2048-bit RSA leaf
certificate, so the TLS handshake is rejected as too weak.
## Evidence
The regression starts between these OVMF prebuilts:
- `edk2-stable202502`: GitHub HTTPS test works.
- `edk2-stable202602`: GitHub HTTPS test fails.
- `edk2-stable202605`: GitHub HTTPS test fails.
The failure is endpoint-specific. With the new OVMF, changing only the
HTTPS test URL to `https://example.com/` makes
`cargo xtask run --headless` pass.
Host OpenSSL reproduces the policy failure:
```sh
openssl s_client -4 \
-connect raw.githubusercontent.com:443 \
-servername raw.githubusercontent.com \
-verify_return_error \
-auth_level 3 \
-brief
```
Expected error:
```text
verify error:num=66:EE certificate key too weak
```
At auth level 2, the same endpoint verifies successfully:
```sh
openssl s_client -4 \
-connect raw.githubusercontent.com:443 \
-servername raw.githubusercontent.com \
-verify_return_error \
-auth_level 2 \
-brief
```
## Solution
Although edk2 now has an internal `TlsSetSecurityLevel()` helper, it is
not exposed through `EFI_TLS_PROTOCOL`, and `HttpDxe` does not let an
HTTP client lower the level. A firmware-side alternative would be to
patch edk2 to make the security level configurable, or lower the default
to level 2.
For uefi-rs, we stop using `raw.githubusercontent.com` as the HTTPS
integration test endpoint. We use a stable endpoint whose certificate
satisfies OpenSSL security level 3, for example ECDSA P-256 or
RSA 3072+. We go with `https://example.com`.
Assisted-by: Codex:GPT-5.5
The parameter in `uefi-raw` was wrong. This parameter is supposed to be
a null-terminated array of handles. Changed it to `*const Handle`
accordingly.
This makes the `uefi` wrapper a little ugly, since the equivalent if
`&[Option<Handle>]`, and the user must ensure that the last element of
the slice is `None`. Fortunately this parameter is usually unused, and
the user can just pass in `&[]`, so the API ugliness should be OK.
On real hardware, Status::TIMEOUT is common even during normal
operation, not just on failure. The previous implementation treated it
as a hard error, silently dropping bytes. Retrying until all bytes are
sent makes the fmt::Write impl reliable and match the expectations of
its callers.
This uses an the same endless loop protection mentioned earlier.
Since recently, example.com isn't sending a Content-Length header and
uses a chunked encoding. It is not trivial to implement this so we skip
this situation for now.
- Refactored return type from standard BTreeSet to custom PciTree struct
- Removed special FullPciIoAddress type, since segment number is PciRoot dependent
- During enumeration, skip branches we have already seen
- During enumeration, collect tree topology information (which child bus linked from where)
- Add complicated pci structure in integration test vm
- Print child busses for every device entry in integration test
The var() and vars() functions wrap the UEFI get_env() implementation to
retrieve a single and multiple environment variables respectively.
The set_var() function wraps the UEFI set_env() variable to set the value
of an environment variable.
Co-authored-by: Philipp Schuster <phip1611@gmail.com>
Please note that some structs that are low-level types and
UEFI-facing still use EfiIpAddr instead. This includes for
example
```rust
/// This struct contains optional parameters for [`BaseCode::discover`].
///
/// Corresponds to the `EFI_PXE_BASE_CODE_DISCOVER_INFO` type in the C API.
#[repr(C)]
#[derive(Debug, Pointee)]
pub struct DiscoverInfo {
use_m_cast: bool,
use_b_cast: bool,
use_u_cast: bool,
must_use_list: bool,
server_m_cast_ip: EfiIpAddr,
ip_cnt: u16,
srv_list: [Server],
}
```
Once https://github.com/rust-osdev/uefi-rs/issues/1642 is resolved,
this can be improved.
In many places, especially doc comments, `Status` was referred to as
`uefi::Status` or `crate::Status`. Consistently use `Status` instead, adding
imports as needed. Note that in cases where `Status` is only used in docstrings,
the `use` is gated by `#[cfg(doc)]`. (This avoids needing a bunch of manual
`Status::*` links in docstrings.)
This is mostly a mechanical find-replace change, except for adding imports where
needed.
