In the spirit of commit 4a8266f570 ("OvmfPkg: Work around issue seen
with kvm + grub2 (efi)") build the package without using MMX and SSE
instruction sets.
This is done to work around GCC generating MOVAPS (aligned move) to
save/restore MMX registers in functions of EFI runtime services and
causing a misaligned accesses by not keeping the stack aligned to 16
bytes. Saving/restoring the registers is a side-effect of MS ABI
calling conventions on those functions. The misaligned accesses are a
problem when an OS configures CPU to trap such accesses like FreeBSD
kernel does.
Had to make an exception for CrScreenshotDxe which is used before any OS
had a chance to run. A cleaner fix is to inline one function there, so
it compiles with `-mno-mmx -mno-sse`, but then need to fork that
submodule or send the change upstream first.
The original idea was to add flags related to alignment, but that did
not produce expected results. The alignment looked correct only with
`-mpreferred-stack-boundary=4 -mincoming-stack-boundary=3` which is
basically lying that the caller uses 8 byte alignment when it's not the
case (UEFI requires the caller to align the stack to 16 bytes) and
doesn't seem to be a nice workaround. Also couldn't make GCC generate
MOVUPS (unaligned move) instead of MOVAPS.
Not using MMX/SSE in the firmware should not affect functionality and
reduces stack usage while getting rid of lots of moves.
Example of bad alignment:
```
00000000000011a3 <VariableServiceGetVariable>:
11a3: 41 57 push %r15
11a5: 41 56 push %r14
11a7: 41 55 push %r13
11a9: 49 89 d5 mov %rdx,%r13
11ac: 41 54 push %r12
11ae: 55 push %rbp
11af: 57 push %rdi
11b0: 56 push %rsi
11b1: 53 push %rbx
# should really be $0x100 vvvvv
11b2: 48 81 ec f8 00 00 00 sub $0xf8,%rsp
# alternatively, need `and $0xfffffffffffffff0,%rsp` here
11b9: 48 85 d2 test %rdx,%rdx
11bc: 0f 94 c0 sete %al
11bf: 4d 85 c9 test %r9,%r9
11c2: 0f 29 74 24 50 movaps %xmm6,0x50(%rsp)
```
Some more details can be read in [0]. This behaviour may very well be a
bug in GCC, see [1], [2], [3], [4] for similarly-looking issues.
[0]: https://github.com/Dasharo/dasharo-issues/issues/1001#issuecomment-3307379806
[1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49001
[2]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56597
[3]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
[4]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90065
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
At least some bootloaders (e.g., one in FreeBSD) use the first console
of ConOut as the primary one. Putting serial console first leads to
interactive output going to serial where most users won't even see it.
OVMF and likely other firmware built with EDK put graphical output
before the serial, so this shouldn't cause any breakage although some
changes in behaviour is possible.
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Boot logo is shown before any pop-up. Dismissing a pop-up or letting it
disappear causes the screen to remain black, because screen is cleared
afer each pop-up. Repaint the logo on the screen after each pop-up to
improve UX.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
When a pop-up is shown and dismissed with ENTER key, the platform does
not react later to hotkey presses, e.g. to enter setup. The input from
from pop-up dismiss is consumed by boot manager hotkey service, because
ENTER is already registered in the hotkey service when pop-ups are shown.
This results in the hotkey service detecting an ENTER hotkey press and
immediate execution of action bound to the ENTER key, i.e. continue boot.
Because of that VBO010.001 test failed.
Move the ENTER hotkey registration right before the prompts are printed,
so that the ENTER key is not mistakenly treated as continue action when
pop-ups are shown.
TEST=Pass Verified Boot test suite on ODROID-H4.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Avoid timing out in PtpCrbRequestUseTpm() for weird CRB chips that
sometimes reset "granted" bit when switching (or maybe staying) in the
Idle state for some time. The function was waiting for the bit to be
set by the TPM which did not do it, so check an active locality and just
return if nothing needs to be done.
This has been observed with Intels fTPM on Jasper Lake Protectli V1210
and V1610 devices.
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
FaultTolerateWrite is enabled and employed, but no recovery was
performed. Not even sure how it happens without coreboot, there is
something in MdeModulePkg/Universal/Variable/Pei and
MdeModulePkg/Universal/Variable/Pei, but operation of tha code isn't
obvious. Either way, it doesn't kick in for coreboot.
Here is how it works:
1. SmmStorePei uses data from CBMEM to create gVariableFlashInfoHobGuid
HOB
2. FaultTolerantWritePei consumes gVariableFlashInfoHobGuid through
VariableFlashInfoLib and produces gEdkiiFaultTolerantWriteGuid
3. BlSupportPei consumes gEdkiiFaultTolerantWriteGuid and uses it to
decide which boot mode to use
4. When SmmStoreFvbRuntime gets initialized it looks up
gEdkiiFaultTolerantWriteGuid and if needed finishes the operation
interrupted by a reboot
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
On ODROID-H4 platform where IBECC option is enabled, the form setup overwrites
the IBECC variable despite the option is not modified in the setup. It happens
that if the IBECC option is after IBG_STATUS in DASHARO_FEATURES_DATA, the value
of the UEFI avriabel changes, which may indicate some alignment problems of the
structures in memory and how the code accesses it.
When IBECC option is before IBG_STATUS, everything works as expected. Move
the IBECC option before IBG_STATUS as a workaroudn until the root cause is found
and fixed.
Addresses issue: https://github.com/Dasharo/dasharo-issues/issues/1544
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
The variable is being checked in DasharoCapsulesCanPersistAcrossReset().
An error from gRT->GetVariable() about missing variable is effectively
ignored (ASSERT_EFI_ERROR() does nothing) and default assumption of ME
is enabled which ended up preventing use of capsules even after
HAP-disabling ME.
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
This causes crash on writing capsule to /dev/efi_capsule_loader in
Linux. The Print() function is asserting in this case and apparently
ends up accessing a pointer memory that was not updated on
SetVirtualAddressMap().
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Some hashes were simply ignored (lack of all CompareGuid in
conditions) and it caused the browser to enter an infinite loop.
Because CertList variable was never updated, the exit condition
for the while loop never met.
Also add formatting for displaying image hashes or certificate
hashes instead of prue GUIDs.
Fixes https://github.com/Dasharo/dasharo-issues/issues/1365
TEST=Enroll DTS grubx64.efi to DB then delete its signature
from DB using the Secure Boot menu on QEMU OVMF.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Microsoft certificates in DB and KEK must have the Signature Owner
GUID set to 77fa9abd-0359-4d32-bd60-28f4e78f784b in the signature
list structure. By default EDK2 used gEfiGlobalVariableGuid as
signature owner.
For reference see Windows Secure Boot Key Creation and Management
Guidance on https://learn.microsoft.com/
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
DB default was missing the Microsoft Option ROM UEFI CA 2023.
Microsoft has separated the signing of Option ROMs from regular
PE binaries.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Collect paths to drivers as they being saved and pass to
GenerateOutputJson() for inclusion into the output JSON file.
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
When a capsule is signed, --decode printed a warning if neither openssl
nor signtool was configured via command-line options. And yet, it then
proceeded to attempt the verification anyway.
Current implementation only ever uses --trusted-public-cert during
verification, so there could be some logic to this behaviour. However,
it's still confusing, so don't attempt to verify anything if it's not
expected to work.
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Michał Kopeć
miczyg1andMichał Kopeć
Michał Żygowski
