Summary: | sys-boot/efibootmgr - arch must match kernel arch to work correctly | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Phattanon Duangdara <phattanon> |
Component: | [OLD] Core system | Assignee: | Mike Gilbert <floppym> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | Matt_Domsch, spiderx, yannick.schaeffer |
Priority: | Normal | Keywords: | PATCH |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | efibootmgr efivars read/write workaround patch |
Description
Phattanon Duangdara
2012-08-19 20:13:20 UTC
This was an intentional design decision when the kernel EFI Variables module (efivars) was first written in ~2001. There are EFI spec-defined fields which are of type LONG which differs between 32-bit and 64-bit EFI environments and kernels, and therefore userspace. Matthew Garrett (Red Hat) was working on a new efivars kernel module that also removes the restriction on variables being only 1024 bytes max which was in a pre-1.0 spec but was removed by EFI 1.0, but which unfortunately lives on in both efivars and efibootmgr today. I don't know the status there. With that complete, it may be possible that the new userspace interface would not be 32-bit or 64-bit specific, at which point efibootmgr could be updated to use the new interface. For now I'd say either "working as designed", or "feel free to fix efivars, and then fix efibootmgr, but you can't fix efibootmgr without fixing efivars first." Created attachment 321730 [details, diff]
efibootmgr efivars read/write workaround patch
Attached (dirty) fixes on efivars reading/writing of efibootmgr when running kernel architecture is different from userland.
Since current efivars have no mechanism to detect if it use 64bit or 32bit long variable. I think we just leave it as is. It will work as long as userland (efibootmgr) and kernel match. So specific case require updated efibootmgr to check what correct data structure to use when read/write sysfs, which my patch does by uname(), but patch does not correct data write by --test option. I seems to lucky because I use recent kernels, it was updated to do more strict validation. Writing invalid values to efivars to older kernel may corrupt firmware, and therefore may cause by this case. I also found that booting 32bit kernel in 64bit UEFI results kernel OOPs on efivars module. I guess 32bit kernel try to use 32bit EFI data structure when booting UEFI 64bit, if it do so it definitely a kernel BUG. So efivars need to be fixed, anyway and at least provide some variables to detect what UEFI platform is using. And efibootmgr will determinate how to handle it. If this is still a problem, please re-open. |