On Sun, 25 Jun 2023 at 21:22, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > ... > > Yes, those are presumably mostly old EFI setups, but that is kind of > the basic problem here. Many of these EFI calls are much more tested > and reliable in the context of EFI boot services, and *much* less > reliable in the context of "runtime services". > Many of these systems shipped with Vista or older booting in BIOS emulation mode (CSM), so the OS visible API surface was barely tested, not even by booting Windows (which appears to be the gold standard for EFI compliance testing according to the OEMs building Windows PCs) > EFI runtime services have been a major PITA over the years. And it's > possible that it's just entirely broken on Sami's laptop. > Agreed. The virtual remapping stuff is particularly nasty, and a constant source of problems, also on arm64, even though it is completely pointless on 64-bit architectures. So I'm generally not a fan of wiring up more of the EFI runtime stuff, but I did not anticipate issues like this one with the varstore API that we already use in various other places. > I'm not entirely sure which laptop it is, with laptop manufacturers > often re-using model names over several years, but "HP 6730b" seems to > be basically from July 2008 (going by the service manual I found). So > we're talking 15 years ago, and yes, EFI was likely *much* less > reliable back then. > Yeah. What we might consider is keying off of the UEFI revision field at a certain cutoff value (e.g., only support this for ~v2.4 or higher), but this would be somewhat arbitrary, of course. I'd rather have an explicit opt-in, but that is policy, making user space a more appropriate venue for this.
