linux-kernel - Re: [PATCH 2/2] x86: fix setup of brk area

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: <41a4a440-36fc-513a-232f-18b781b41926@suse.com>
Date:   Thu, 23 Jun 2022 11:03:10 +0200
From:   Juergen Gross <jgross@...e.com>
To:     Jan Beulich <jbeulich@...e.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>, xen-devel@...ts.xenproject.org,
        x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] x86: fix setup of brk area

On 23.06.22 10:50, Jan Beulich wrote:
> On 23.06.2022 10:14, Juergen Gross wrote:
>> On 23.06.22 10:09, Jan Beulich wrote:
>>> On 22.06.2022 18:10, Juergen Gross wrote:
>>>> Commit e32683c6f7d2 ("x86/mm: Fix RESERVE_BRK() for older binutils")
>>>> put the brk area into the .bss segment, causing it not to be cleared
>>>> initially.
>>>
>>> This reads contradictively: If the area was put in .bss, it would be
>>> cleared. Thing is it is put in .bss..brk in the object files, while
>>> the linker script puts it in .brk (i.e. outside of .bss).
>>
>> Hmm, yes, this should be reworded.
>>
>>>
>>>> As the brk area is used to allocate early page tables, these
>>>> might contain garbage in not explicitly written entries.
>>>
>>> I'm surprised this lack of zero-initialization didn't cause any issue
>>> outside of PV Xen. Unless of course there never was the intention for
>>> users of the facility to assume blank pages coming from there, in
>>> which case Xen's use for early page tables would have been wrong (in
>>> not explicitly zeroing the space first).
>>
>> Fun fact: Its not Xen's use for early page tables, but the kernel's
>> init code. It is used for bare metal, too.
>>
>> The use case for initial page tables is the problematic one. Only the
>> needed page table entries are written by the kernel, so the other ones
>> keep their initial garbage values. As normally no uninitialized entries
>> are ever referenced, this will have no real impact.
> 
> Are you sure there couldn't surface user-mode accessible page table
> entries pointing at random pages?

No, I'm not sure this can't happen.


Juergen


Download attachment "OpenPGP_0xB0DE9DD628BF132F.asc" of type "application/pgp-keys" (3099 bytes)

Download attachment "OpenPGP_signature" of type "application/pgp-signature" (496 bytes)