linux-kernel - [PATCH v3 0/2] Incorporate DRAM address in EDAC messages

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: <e78b6556-24c0-469b-81d5-98380aee1f6b@amd.com>
Date: Tue, 14 Oct 2025 12:13:36 -0500
From: "Naik, Avadhut" <avadnaik@....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,
 Yazen Ghannam <yazen.ghannam@....com>
Subject: [PATCH v3 0/2] Incorporate DRAM address in EDAC messages



On 10/14/2025 08:52, Yazen Ghannam wrote:
> 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.
> 
Adding to what Yazen mentioned, the algorithm employed for translating
physical or normalized address into DRAM Address is somewhat complex.
As such, user space tools might not incorporate the support required
for translation.
Having DRAM Address as part of kernel messages and tracepoints ensures
that any memory error related information is not skipped.

Does this alleviate your concerns?
If yes, will add this information to commit messages and resend.

> Thanks,
> Yazen

-- 
Thanks,
Avadhut Naik