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: <20251014135206.GA361227@yaz-khff2.amd.com>
Date: Tue, 14 Oct 2025 09:52:06 -0400
From: Yazen Ghannam <yazen.ghannam@....com>
To: Borislav Petkov <bp@...en8.de>
Cc: Avadhut Naik <avadhut.naik@....com>, linux-edac@...r.kernel.org,
	john.allen@....com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 0/2] Incorporate DRAM address in EDAC messages

On Tue, Oct 14, 2025 at 12:00:19AM +0200, Borislav Petkov wrote:
> On Mon, Oct 13, 2025 at 07:34:47PM +0000, Avadhut Naik wrote:
> > Currently, the amd64_edac module only provides UMC normalized and system
> > physical address when a DRAM ECC error occurs. DRAM Address is neither
> > logged nor exported through tracepoint.
> > 
> > Modern AMD SOCs provide UEFI PRM module that implements various address
> > translation PRM handlers. These PRM handlers can be leveraged to convert
> > UMC normalized address into DRAM address at runtime on occurrence of a
> > DRAM ECC error. This translated DRAM address can then be logged and
> > exported through tracepoints.
> 
> And?
> 
> I read all three commit messages to figure out *why* those DRAM addresses want
> to be logged. But it seems they don't want to be logged. Because there's not
> a single reason why they should be, AFAICT. Without a proper justification,
> this looks like a bunch of unnecessary code to me...
> 

Good point. I overlooked this myself.

The "DRAM address" helps memory vendors analyze failures. System
builders want to collect this data and pass it along to the memory
vendors. The DRAM address is not contained in architectural data like
MCA info, and getting the address from MCA requires using additional
system-specific hardware info. It's much more reliable to get the DRAM
address from the system with the error rather than try to post-process
it later.

Thanks,
Yazen

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ