lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 10 Nov 2021 10:17:34 +0100
From:   Hans-Gert Dahmen <hans-gert.dahmen@...u.ne>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Philipp Deppenwiese <philipp.deppenwiese@...u.ne>,
        Mauro Lima <mauro.lima@...ypsium.com>,
        Richard Hughes <hughsient@...il.com>,
        "platform-driver-x86@...r.kernel.org" 
        <platform-driver-x86@...r.kernel.org>
Subject: Re: [PATCH] firmware: export x86_64 platform flash bios region via sysfs

Am Mi., 10. Nov. 2021 um 10:05 Uhr schrieb Andy Shevchenko
<andy.shevchenko@...il.com>:
>
> On Wed, Nov 10, 2021 at 10:37 AM Hans-Gert Dahmen
> <hans-gert.dahmen@...u.ne> wrote:
> > Am Mi., 10. Nov. 2021 um 07:35 Uhr schrieb Andy Shevchenko
> > <andy.shevchenko@...il.com>:
> > > On Tuesday, November 9, 2021, Hans-Gert Dahmen <hans-gert.dahmen@...u.ne> wrote:
> > >> Am Di., 9. Nov. 2021 um 13:42 Uhr schrieb Greg KH <gregkh@...uxfoundation.org>:
>
> > >> > 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. 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.

>
> --
> With Best Regards,
> Andy Shevchenko

Hans-Gert

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ