On Thu, 11 Nov 2021 at 13:01, Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> wrote: > I'm not sure I understand why the platform security needs to be turned off? Sorry to be unclear, I meant we had to turn off Secure Boot (and thus also kernel lockdown) so that we could use /dev/mem to verify that OEMs have set up the IFD, BLE, BIOSWP etc correctly. You'd be surprised just how many vendors don't read the specifications correctly and get this wrong. We also need port IO to use the intel-spi driver so we can parse the BIOS contents from userspace, which you can't obviously do when SB is turned off. The eSPI controller is hidden on some hardware now, and we need to play games to make it visible again. > I think exposing /dev/mem opens another can of worms that we want to > avoid. Ohh it's not all of /dev/mem, it's just the 16MB BIOS region that has to be mapped at that address for the hardware to boot. > Don't we already expose some of the EFI stuff under /sys/firmware? Yes, some information, but not the file volumes themselves. I don't think the kernel wants to be in the game of supporting every nested container and compression format that EFI supports. It's also the wrong layer to expose platform attributes like BLE, but that's an orthogonal thing to the patch Hans-Gert is proposing. > I just don't want to > spend yet another Christmas holiday trying to fix angry peoples laptops :( Completely understood, I don't think any of us want that. > Having said that the hardware sequencer used in the recent CPUs should > be much safer in that sense. FWIW, I'd be fine if we had RO access for HWSEQ flash access only. If I understood correctly that's what Mauro proposed (with a patch) and instead was told that it was being rewritten as a mtd driver completion time unknown. Richard.
