Am Do., 11. Nov. 2021 um 14:34 Uhr schrieb Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx>: > > On Thu, Nov 11, 2021 at 01:22:25PM +0000, Richard Hughes wrote: > > 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. > > Okay, thanks for explaining. > > > > 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. > > I see. > > > > 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. > > I think Mauro proposed something different, basically exposing RO parts > of the driver only. > > The intel-spi driver is being moved from MTD to SPI because the MTD > SPI-NOR maintainers (not me) said that it needs to be done before we can > add any new feature to the driver. That includes also Mauro's patch. > > I have v4 of the conversion patch series done already but since it is a > middle of the merge window I'm holding it until v5.16-rc1 is released > (next sunday). I can CC you too and I suppose Hans and Mauro (who else, I'd be delighted. > let me know). Once the MTD maintainers are happy we can progress adding > features what fwupd needs there too (and the features we, Intel, want to > add there). Hans-Gert
