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
