Messages in this thread | | | Date | Mon, 15 Nov 2021 21:44:35 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH 3/3] x86_64: Use relative per-cpu offsets |
| |
On Sun, Nov 14, 2021 at 01:29:46PM -0500, Brian Gerst wrote: > On Sun, Nov 14, 2021 at 6:03 AM Peter Zijlstra <peterz@infradead.org> wrote: > > > > On Sat, Nov 13, 2021 at 11:54:19PM -0500, Brian Gerst wrote: > > > On Sat, Nov 13, 2021 at 8:18 PM Andy Lutomirski <luto@kernel.org> wrote: > > > > > > > > > > > > > > > > On Sat, Nov 13, 2021, at 4:40 AM, Brian Gerst wrote: > > > > > The per-cpu section is currently linked at virtual address 0, because > > > > > older compilers hardcoded the stack protector canary value at a fixed > > > > > offset from the start of the GS segment. Use a standard relative offset > > > > > as the GS base when the stack protector is disabled, or a newer compiler > > > > > is used that supports a configurable location for the stack canary. > > > > > > > > Can you explain the benefit? Also, I think we should consider dropping support for the fixed model like we did on x86_32. > > > > > > This patch probably makes more sense if we drop the fixed model, as > > > that gets rid of alot of code that works around having to link the > > > percpu section differently. > > > > Can someone spell out these benefits please? To me having per-cpu start > > at 0 makes perfect sense, how does not having that make things better? > > The best reason is that the percpu section is currently not subject to > KASLR. It actually needs extra support to counter the effects of > relocation. There have also been a number of linker bugs over the > years that have had to be worked around.
I'm confused.. having the variables 0-offset is related to KASLR how? The dynamic placement of per-cpu thunks and their base address in %GS gives plenty opportunity to move them around at boot time, no?
> If we were to decide to drop the fixed stack protector the diffstat > would look something like:
Dropping the fixed stack protecter seems fine to me; I just don't see why we should move away from 0-offset.
| |