Hi,
On 12/13/19 7:49 PM, Ard Biesheuvel wrote:
On Fri, 13 Dec 2019 at 13:29, Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
Hi,
On 13-12-2019 10:11, Ard Biesheuvel wrote:
EFI mixed mode is a nice hack, since it allows us to run 64-bit Linux
on low end x86_64 machines that shipped with 32-bit UEFI as they were
built to run 32-bit Windows only.
Mixed mode relies on the ability to convert calls made using the
64-bit calling convention into calls using the 32-bit one. This
involves pushing a 32-bit word onto the stack for each argument
passed in a 64-bit register, relying on the fact that all quantities
that are the native size or smaller (including pointers) can be safely
truncated to 32 bits. (In the pointer case, we rely on the fact that
we are still executing in the firmware context, which uses a 1:1
mapping that can only access the lower 4 GB of the address space)
For types that are explicitly 64 bits wide, such as EFI_PHYSICAL_ADDRESS
or UINT64, this assumption doesn't hold. The correct way to marshall
such a call would be to push two consecutive 32-bit words onto the
stack, but given that the naive thunking code has no knowledge
whatsoever of the prototype of the function it is invoking, all we can
do is avoid calling such functions altogether.
The FreePages() boot service is affected by this, so we should not call
that at all in mixed mode. In practice, this doesn't change much, since
in the past, these calls would have been made with a bogus address, and
so we were leaking this memory already. Note that the scope of this leak
is the EFI execution context only, so it makes no difference for Linux.
The other piece of functionality that we need to disable is loading files
passed via file=xxxx on the command line, given that the Open() method
takes two UINT64s as well.
Signed-off-by: Ard Biesheuvel <ardb@xxxxxxxxxx>
Just ignoring the file= arguments is fine with me, as you say this has
been broken on mixed-mode since forever so likely no-one is using it:
Acked-by: Hans de Goede <hdegoede@xxxxxxxxxx>
Thanks.
Do you have any recommendations on how to test this? Are you using GRUB to boot?
I am trying to test the random.c failure using QEMU+OVMF, which
implements the EFI_RNG_PROTOCOL on top of virtio-rng-pci, but I cannot
reproduce the failure.
I hit the random.c issue when testing a 5.5-rc1 x86_64 kernel on a Bay Trail
tablet. Almost any Bay Trail hw will come with 32 bit uefi because when Bay
Trail tablets (and 2-in-1s) first hit the market the 64 bit Windows drivers
were not ready yet and running 32 bit Windows requires a 32 bit UEFI
(Bay Trail devices do not have a classic bios mode / CSM).
A popular model example machine of such a setup is The Asus T100TA 2-in-1.
I'm using a standard Fedora install on these machines which goes:
UEFI -> 32-bit-secureboot-shim -> 32-bit-uefi-grub -> 64 bit kernel
Regards,
Hans
