Messages in this thread | | | Date | Thu, 23 Jun 2022 11:03:10 +0200 | Subject | Re: [PATCH 2/2] x86: fix setup of brk area | From | Juergen Gross <> |
| |
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
[unhandled content-type:application/pgp-keys][unhandled content-type:application/pgp-signature] | |