Re: [PATCH] firmware: export x86_64 platform flash bios region via sysfs

[Hans-Gert Dahmen]

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