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, 23 Jun 2021 14:40:07 +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 Wed, Jun 23, 2021 at 02:17:54PM +0200, Hans-Gert Dahmen wrote:
> Hi,
> 
> these are some good points.
> 
> On 23.06.21 00:18, David Laight wrote:
> > Are you saying that my 15 year old 64bit Athlon cpu and bios
> > have this large SPI flash
> 
> No. The reads will wrap, i.e. if your flash is 2MB then it would be repeated
> 8 times in the 16MB window.
> 
> > and the required hardware to
> > convert bus cycles to serial spi reads?
> 
> 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.
> 
> However, after reading your mail I understand that I should have looked up
> the exact explanations in the respective specs. So to definitively answer
> your question I need to know which south bridge there is in your 15 year old
> system and have a look into its datasheet. Do you know which one it is by
> any chance?

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.

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ