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

[Andy Shevchenko]

On Wed, Nov 10, 2021 at 11:17 AM Hans-Gert Dahmen
<hans-gert.dahmen@xxxxxxx> wrote:
> Am Mi., 10. Nov. 2021 um 10:05 Uhr schrieb Andy Shevchenko
> <andy.shevchenko@xxxxxxxxx>:
> > On Wed, Nov 10, 2021 at 10:37 AM Hans-Gert Dahmen
> > <hans-gert.dahmen@xxxxxxx> wrote:
> > > Am Mi., 10. Nov. 2021 um 07:35 Uhr schrieb Andy Shevchenko
> > > <andy.shevchenko@xxxxxxxxx>:
> > > > On Tuesday, November 9, 2021, Hans-Gert Dahmen <hans-gert.dahmen@xxxxxxx> wrote:
> > > >> Am Di., 9. Nov. 2021 um 13:42 Uhr schrieb Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>:
> >
> > > >> > Do you have a pointer to these complex and buggy drivers anywhere?
> > > >>
> > > >> I am talking about the linux-mtd intel-spi driver for example, but I
> > > >> feel that this gets the discussion in the wrong direction.
> > > >
> > > > This is the driver that covers all BIOSes on modern x86\64. What’s wrong with it? Why do you need this?!
> > > >
> > > > If it’s buggy, where is the bug reports from you or somebody else?
> > >
> > > Please see Mauro's mail in this thread from yesterday below:
> >
> > I didn't get this. What's wrong with the response from the author of
> > intel-spi (since we are speaking about it, let me add him to the
> > thread)?
> > What you are trying to do is to sneak around with ugly hack behind the
> > proper subsystem's back.
> >
> > NAK as I already said.
>
> There is nothing wrong with the response. Also we are not trying to
> sneak anything into the kernel. This just is no mtd or spi driver, it
> is not even a driver. What this does is it opens back up a portion of
> memory that can not be read anymore through /dev/mem on locked down
> systems with SecureBoot enabled. This portion of memory is actively
> being used by userspace programs. We, 9elements, Eclypsium, fwudp and
> immune are among those who rely upon this to improve the security of
> x86_64 linux devices.

I appreciate this.

x86_64 starting from long time ago has more or less standard hardware
interface for BIOS chip, i.e. SPI NOR. PCH usually has a separate host
controller and we have the driver in the kernel for that (coverage of
the systems may not be 100%, but close enough). Now you are trying to
repeat something that is _already_ provided by the kernel. Correct?

> Now what happens is that more distros start to
> lock down their kernels and require signed modules. With the mtd
> driver not working on those machine to read the bios binary, you are
> effectively forcing users into less secure system configurations (i.e.
> opening up the whole /dev/mem and/or disabling SecureBoot) just to be
> able to run fwupd or other tools to assess firmware information. The
> issue of being able to assess and compare the bios binary to the one
> publicly available from the vendors is increasingly getting important
> in the wake of recent CVEs about supply-chain attacks where UEFI
> malware was pre-installed. So we are not even doing anything new here,
> you are just making life harder for everybody.

Why me? As far as I got it from above the bottleneck is the distros
which do not enable the driver. So why not go and work with them?

-- 
With Best Regards,
Andy Shevchenko