lkml.org 
[lkml]   [2021]   [Nov]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] firmware: export x86_64 platform flash bios region via sysfs
On Tue, Nov 9, 2021 at 1:12 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Tue, Nov 09, 2021 at 10:55:54AM -0300, Mauro Lima wrote:
> > Hi all,
> >
> > On Tue, Nov 9, 2021 at 3:16 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Tue, Nov 09, 2021 at 01:01:30AM +0100, Hans-Gert Dahmen wrote:
> > > > Make the 16MiB long memory-mapped BIOS region of the platform SPI flash
> > > > on X86_64 system available via /sys/kernel/firmware/flash_mmap/bios_region
> > > > for pen-testing, security analysis and malware detection on kernels
> > > > which restrict module loading and/or access to /dev/mem.
> > >
> > > That feels like a big security hole we would be opening up for no good
> > > reason.
> > Please, can you explain why this could be a security hole?
>
> We restricted /dev/mem and now you want to open a portion of it back up,
> hence my worry that now you can read information that previously you
> could not read.

Thanks for the explanation, I understand the worry about changing this
again but still I don't understand what advantage it can give an
attacker to be able to read the binary :(.

> > IMO if the host is compromised the attacker already has information
> > about the BIOS version, and after a quick lookup they know the BIOS
> > vulnerabilities or the lack of them.
>
> So you are saying that you do NOT need this access to get the BIOS
> information if you have root access? If not, then why is this needed?

Sorry if I did not express myself clearly, but the information I was
talking about, could be the BIOS version number for example. If the
host is compromised you can get the BIOS version and check what
vulnerabilities are not fixed in that version and exploit them.
You don't need the binary for this, just with the number you can go
and check on vendor sites for unpatched vulnerabilities for that
version.
But, if you could take this binary, somehow compare it to a certified
blob given by your vendor and see if they match or not (corrupted),
could be a good reason for this.

> confused,

Sorry again and thanks for your time.

> greg k-h

Thanks, Mauro.

\
 
 \ /
  Last update: 2021-11-09 18:24    [W:0.099 / U:1.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site