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

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]

Message-ID: <YNRviIrdvrjAMCXG@kroah.com>
Date:   Thu, 24 Jun 2021 13:42:00 +0200
From:   "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
To:     Hans-Gert Dahmen <hans-gert.dahmen@...u.ne>
Cc:     David Laight <David.Laight@...lab.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "philipp.deppenwiese@...u.ne" <philipp.deppenwiese@...u.ne>
Subject: Re: [PATCH] firmware: export x86_64 platform flash bios region via
 sysfs

On Thu, Jun 24, 2021 at 01:20:28PM +0200, Hans-Gert Dahmen wrote:
> 
> On 23.06.21 14:40, gregkh@...uxfoundation.org wrote:
> > > On Wed, Jun 23, 2021 at 02:17:54PM +0200, Hans-Gert Dahmen wrote:
> > > Hi,
> > > Yes. The window is part of the DMI interface and the south bridge or PCH
> > > converts the bus cycles to SPI reads. It is because this region contains the
> > > reset vector address of your CPU and the very first instruction it executes
> > > after a reset when the internal setup is done will actually be loaded from
> > > the serial SPI bus. It is AFAIK part of AMD's original 64-bit specification.
> > The point is that you will never be able to do this for all devices.
> > You should ONLY be allowed to have this module bind to the hardware that
> > you KNOW it will work with.
> > 
> > So please work off of a DMI table, or some such hardware description,
> > instead of just blindly enabling it for all systems.
> 
> I was referring to the DMI/QPI/PCI interface that connects the ICH/PCH/south
> bridge to the CPU. I have gone through all datasheets of intel ICH and PCH
> and they state that the address range from 0xff000000 through 0xffffffff is
> a fixed mapping that cannot be changed (no BAR) except for the original ICH
> (dating back to 1999) where the window is only 8MB. The original ICH is for
> 32-bit systems only so all 64-bit Intel systems that exist have this
> feature. I have talked to somebody who works with future Intel hardware and
> the person indicated that it is not likely to change.
> 
> This is why I made the module depend on X86_64. I still have to do the same
> complete research for AMD systems which is a little harder to do, so I am
> proposing to check if the root complex has Intel's vendor ID and only load
> the module on 64-bit Intel systems until I can confirm the same behavior for
> all 64-bit AMD systems. Then I could check if the root complex is Intel or
> AMD. Would that suffice as "some such hardware description"?

That would help, yes.  Especially given the other types of Intel-like
cpus we are seeing in the wild these days (not all the world is Intel
and AMD...)

But what is this really going to be used for?  What userspace tools need
this type of direct access to do something useful?

thanks,

greg k-h