Conversation
Member
Author
|
FYI. Very interesting debugging story @nicholasbishop @kraxel might be interesting to you too as you introduced the HTTPS test last year in #1614 |
phip1611
force-pushed
the
bump-ovmf
branch
2 times, most recently
from
June 14, 2026 16:22
b30480d to
8a394ef
Compare
phip1611
changed the title
phip1611
commented
Jun 14, 2026
2 tasks
phip1611
commented
Jun 14, 2026
| // Keep this endpoint compatible with edk2's TLS policy. Newer OVMF | ||
| // defaults OpenSSL to security level 3, so RSA <3072-bit leaf certs | ||
| // can make Request() fail before any HTTP response is available. | ||
| fetch_http(*h, "https://example.com/") |
Member
Author
There was a problem hiding this comment.
I can reproduce the CI issue on an aarch64 machine and will continue debugging
Member
Author
There was a problem hiding this comment.
EDK2 for aarch64 is built with -DEDK2_OPENSSL_NOEC=1 ... this basically prevents connections to any TLS/HTTPS host out there. I temporarily deactivate this test for aarch64.
phip1611
force-pushed
the
bump-ovmf
branch
4 times, most recently
from
June 15, 2026 08:59
6c88952 to
0457f3d
Compare
We update OVMF to include the latest bugfixes and overall most recent version. This influences the version of OFMF (edk2) that we use in our integration tests (`cargo xtask run`).
This is the last version in edk2 with IA32 support. We will therefore never update OVMF for IA32 in our test infrastructure. New tests that are conflicting will be disabled for IA32 to maintain a solid base for IA32 without hindering progress for the main architectures x86_64 and ARM.
## 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
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.
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.
phip1611
enabled auto-merge
June 15, 2026 09:12
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
Jun 15, 2026
Merged
Contributor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
We update OVMF to include the latest bugfixes and overall most recent
version. This influences the version of OFMF (edk2) that we use in our
integration tests.
This will unblock #1728