linux-kernel - Re: [PATCH 1/1] x86/boot: clear some fields explicitly

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: <ffd7a9b6-8017-2d2c-c4f7-65563094ccd0@nvidia.com>
Date:   Thu, 25 Jul 2019 15:42:12 -0700
From:   John Hubbard <jhubbard@...dia.com>
To:     "H. Peter Anvin" <hpa@...or.com>,
        Thomas Gleixner <tglx@...utronix.de>
CC:     <john.hubbard@...il.com>, Ingo Molnar <mingo@...hat.com>,
        Borislav Petkov <bp@...en8.de>, <x86@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] x86/boot: clear some fields explicitly

On 7/25/19 3:28 PM, H. Peter Anvin wrote:
> On 7/25/19 3:03 PM, Thomas Gleixner wrote:
>> On Thu, 25 Jul 2019, hpa@...or.com wrote:
>>> On July 25, 2019 2:48:30 PM PDT, Thomas Gleixner <tglx@...utronix.de> wrote:
>>>>
>>>> But seriously I think it's not completely insane what they are doing
>>>> and the table based approach is definitely more readable and maintainable
>>>> than the existing stuff.
>>>
>>> Doing this table based does seem like a good idea.
>>
>> The question is whether we use a 'toclear' table or a 'preserve' table. I'd
>> argue that the 'preserve' approach is saner.
>>
> 
> I agree.
> 

OK, I can polish up something and post it, if you can help me with one more
quick question: how did you want "to preserve" to work?

a) copy out fields to preserve, memset the area to zero, copy back preserved
fields? This seems like it would have the same gcc warnings as we have now,
due to the requirement to memset a range of a struct... 

b) Iterate through all fields, memsetting to zero items that are *not*
marked "to preserve"?

c) Something else? Sorry for the naivete here.  I really did read 
Documentation/x86/boot.rst, honest. :)

thanks,
-- 
John Hubbard
NVIDIA