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: <3831bbff-631a-2e62-9e82-e2b6181421c8@zytor.com>
Date:   Thu, 25 Jul 2019 13:38:46 -0700
From:   "H. Peter Anvin" <hpa@...or.com>
To:     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>,
        John Hubbard <jhubbard@...dia.com>
Subject: Re: [PATCH 1/1] x86/boot: clear some fields explicitly

On 7/25/19 12:22 AM, Thomas Gleixner wrote:
>>
>> The problem with this is that it will break silently when changes are
>> made to this structure.
> 
> That's not really the worst problem. Changes to that struct which touch any
> of the to be cleared ranges will break anyway if not handled correctly in
> the sanitizer function.
> 

Not really... that's kind of the point (the cleared ranges are cleared
explicitly because the boot loader failed to do so, so zeroing them is what
the boot loader should have done.)

The most correct way to address this would be to have an explicit list of
members to be *preserved* even if the sentinel triggers.

The easy way would be to put in a suitable cast to clear the warning -- I
would not be surprised if an explicit cast to something like (void *) would
quiet the warning, or else (yuck) put in an explicit (well-commented) #pragma
to shut it up.

	-hpa