RE: [PATCHv6 01/16] x86/cpu: Enumerate the LASS feature bits

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> >> Logically there are two completely different things:
> >>
> >>       1. Touching userspace
> >>       2. Touching the lower half of the address space
> >>
> >> If it's only userspace in the lower half of the address space, then
> >> there's no controversy. But the problem obviously occurs when you want
> >> to touch kernel mappings in the lower half of the address space.
> >
> > Why does the kernel create the mappings to poke kernel text
> > for ALTERNATIVE patching in the lower half of the address space?
> >
> > Instead of special "we really to want to access the lower addresses"
> > code, wouldn't it be easier to map the "poke" virtual addresses in normal
> > kernel upper-half space?
>
> The upper half of the address space is shared kernel space, right? Every
> PGD has identical contents in the upper half. So if we create a mapping
> there,everybody get access to it. Every mm can access it. Every
> *process* can access it. It still has kernel permissions of course, but
> it's still a place that everybody can get at.
>
> The lower half is *ONLY* accessible to the local mm. In this case, only
> the text poking mm. It's a natural, safe, place to create a mapping that
> you want to be private and not be exploited.
>
> So, doing it in the upper half is risky.
>
> If we *wanted*, we could have a non-shared PGD entry in the top half of
> the address space. But we'd need to reserve its address space and all
> that jazz. I'm not sure it's any better than just disabling LASS
> enforcement for a moment.

Maybe it’s a thing to put on the list for "when x86 drops support for 32-bit".

Reserving a PGD entry in the kernel half of the address space for
local CPU use would be practical then. Perhaps there might be other
uses too.

-Tony




[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux