On Thu, Nov 11, 2021 at 11:46:39AM +0000, Richard Hughes wrote: > On Thu, 11 Nov 2021 at 10:33, Mika Westerberg > <mika.westerberg@xxxxxxxxxxxxxxx> wrote: > > OK, I see from your patch that it uses the direct mapped read-only > > region to read this data. > > Sorry for the delay in replying here. What I like about Hans-Gert's > patch is that it's always going to work on x64 -- if the system > firmware isn't available at that offset then the platform just isn't > going to boot. It's super simple, and means we can read out the hugely > complex UEFI blob without asking the user to turn off kernel lockdown > and secure boot so we can run the security verification tools. At the > moment we're in this strange situation where we ask the user to > cripple their platform security to run the platform security tools. I'm not sure I understand why the platform security needs to be turned off? Sorry if that was already mentioned somewhere in the thread, I did not read all of them throughly. > > Do we know what information exactly fwupd needs? I mean exposing all of > > this might not be good idea from security perspective (but I'm not an > > expert). > > Ideally, fwupd needs the entire IFD partition which contains all the > EFI File Volumes. We already parse these when the user is booting > without secure boot using the Intel SPI controller and doing *evil* > hacks to make the PCI device visible. The reason we want to parse the > BIOS can be explained pretty easily; at startup we look at the TPM > PCRs and we know very quickly and easily if the system firmware event > has changed. If the checksum changed, then the firmware was modified > in some way. However, saying to the user that "checksum changed" isn't > useful at all. What we want to do is say something like "an EFI binary > called RootKitz.efi was added" or "the AmiTcgPlatformPeiAfterMem.efi > binary changed" and actually report what was done. At the moment we > can do this, but not if /dev/mem cannot be used. I think exposing /dev/mem opens another can of worms that we want to avoid. Is there anything preventing to add a sane interface from say the intel-spi driver (can be something else too) that exposes the minimal set you need? That can be in the mainline kernel and is secure (and safe) enough that distros (and users) can enable it? Don't we already expose some of the EFI stuff under /sys/firmware? > > However, we can perhaps expose some of it through intel-spi, > > and make that work so that distros can enable it safely. > > I think, if we're being honest, that Intel has no plans to make > intel-spi available as a RO interface of any sort. There's some sort > of hardware errata or misdesign that nobody can mention that makes the > RO access unsafe. I think it's probably more than missing arbitration. No that's not the reason. The real reason I'm concerned (as the author and maintainer of that thing) is that last time the driver was accidentally enabled in Ubuntu (around 2019) there was a driver bug (which was fixed already but it was not yet in the Ubuntu kernel) that turned some Lenovo based systems' BIOSes to read-only. It has nothing to do with my employer or hardware errata/misdesign. I just don't want to spend yet another Christmas holiday trying to fix angry peoples laptops :( Having said that the hardware sequencer used in the recent CPUs should be much safer in that sense. It should not allow things like this to happen (the affected systems used software based sequencer).
