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

[Juergen Gross <jgross@suse.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 1657 bytes --]

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


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3149 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]