Am Do., 11. Nov. 2021 um 13:46 Uhr schrieb Andy Shevchenko <andy.shevchenko@xxxxxxxxx>: > > On Thu, Nov 11, 2021 at 1:46 PM Richard Hughes <hughsient@xxxxxxxxx> wrote: > > On Thu, 11 Nov 2021 at 10:33, Mika Westerberg > > <mika.westerberg@xxxxxxxxxxxxxxx> wrote: > > > 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. > > Well, it's _usual_ case, but in general the assumption is simply > incorrect. Btw, have you checked it on Coreboot enabled platforms? > What about bare metal configurations where the bootloader provides > services to the OS? No it is always the case. I suggest you go read your own Intel specs and datasheets before spreading further FUD. I have experienced u-root and coreboot developers sitting right next to me in my office and they were among the ones suggesting my patch. This is just laughable, please stop it Andy. > > > Ideally, fwupd needs the entire IFD partition which contains all the > > EFI File Volumes. > > Well, can't it be part of the EFI subsystem in the kernel then? (+Ard) > > > 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. > > > > > 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. > > > > -- > With Best Regards, > Andy Shevchenko Hans-Gert
