On Mon, May 2, 2022 at 5:29 PM Jeremy Linton jeremy.linton@arm.com wrote:
On 4/6/22 12:57, Neal Gompa wrote: (trimming)
- NVIDIA graphics
- Broadcom wireless
The former case is excessively common, and the latter case is fairly common with HP and Dell machines as well as some smaller OEMs. I literally helped someone this past week with both[1][2][3]. The Workstation WG has been tracking both issues for years now[4][5]. This situation is *worse* now because we have Fedora Linux preloaded on computers, and OEMs basically have to disable Secure Boot to make things "work". How's that for improving security?
I too have been a bit surprised at some of the difficulties of hibernate/secure boot on recent fedora releases. It seems people are entirely unaware that ACPI/S3 standby is gone from most consumer laptops, and the modern standby replacement implementations tend to work very poorly WRT conserving battery with the lid closed in Linux.
It's a kernel problem. I'm not sure to what degree upstream is aware of it. But there's not a lot we can do about it except file bugs and ask for improvement.
So, on a recent fedora machine, it took me more than 4 hours to get a hibernation file on btrfs plus LUKS encrypted partition working. The documentation for that wasn't to be found anywhere on the fedora/RH sites and required compiling a tool to do the block offset calculations and manually adding the resume_offset options to grub/etc. All while avoiding the mass of incorrect information found on the internet. And of course it also requires disabling swap on zram (which was nonsense on the machine anyway, given the disks are faster than it can compress/decompress pages).
I don't think it requires disabling swap on zram per se - from what I've been told the hibernation code knows it can't use it for the hibernation image, not least of which is it's not big enough for a contiguous write of the image. The issue might be that so much needs to be swapped out, to free ~50% RAM, which is used to create the hibernation image in memory before it's written out. We need a clear reproducer with logs and get it posted to the Linux memory management mailing list to see what's going wrong. Since zram is threaded, it's pretty unlikely drive writes are faster than memory writes with compression. LZO+RLE is computationally pretty cheap.
And of course the lockdown patches in the kernel still aren't smart enough to be able to detect that the swapfile is actually encrypted, so it also requires disabling secure boot (this IMHO is frankly unacceptable, that one can't have both options enabled at the same time).
Encryption isn't enough to ensure the image is valid. It needs to be signed. But in any case this is also upstream effort required, including discovering the offset via a standard API for all file systems.
So, this is really less about BIOS/EFI and more about some pretty basic functionality being broken in the distro.