On Tue, Nov 9, 2021 at 1:12 PM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx> 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.
