linux-kernel - Re: [PATCH 1/3] powerpc/pseries: Correct secvar format representation for static key management

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] [day] [month] [year] [list]

Message-ID: <416c529c-529e-4b3e-8ee7-218c091e47e8@linux.ibm.com>
Date: Mon, 12 May 2025 15:46:29 +0530
From: Srish Srinivasan <ssrish@...ux.ibm.com>
To: Andrew Donnellan <ajd@...ux.ibm.com>, linux-integrity@...r.kernel.org,
        linuxppc-dev@...ts.ozlabs.org
Cc: maddy@...ux.ibm.com, mpe@...erman.id.au, npiggin@...il.com,
        christophe.leroy@...roup.eu, naveen@...nel.org, zohar@...ux.ibm.com,
        nayna@...ux.ibm.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] powerpc/pseries: Correct secvar format representation
 for static key management


On 5/12/25 3:25 PM, Andrew Donnellan wrote:
> On Wed, 2025-05-07 at 00:29 +0530, Srish Srinivasan wrote:
>>> I think you should handle this as the existing code does: if it's
>>> ENOENT, return 0, and for other codes print an error and return -
>>> EIO.
>> Currently, the other layers in the boot stack assume static key mode
>> for
>> any failure in reading SB_VERSION. We added the same interpretation
>> in the kernel to keep it consistent with the other layers, and
>> represent
>> the same to the user. This is the reason for not parsing the error
>> codes
>> when trying to read SB_VERSION, and defaulting to the static key
>> management mode. However, we want the exact error code to be logged
>> for debugging purposes. And, it does make sense to have logging only
>> for
>> error codes other than -ENOENT and -EPERM, as you suggested.
>> Does this sound okay?
> Okay, maybe document explicitly in a comment that we default to static
> mode in the event of any weird errors.
Sure, will do that.
Thank You.
>