Peter Zijlstra
2020-Mar-04 09:21 UTC
[PATCH v11 00/11] x86: PIE support to extend KASLR randomization
On Tue, Mar 03, 2020 at 01:19:22PM -0800, Kees Cook wrote:> On Tue, Mar 03, 2020 at 01:01:26PM -0800, Kristen Carlson Accardi wrote: > > On Tue, 2020-03-03 at 07:43 -0800, Thomas Garnier wrote: > > > On Tue, Mar 3, 2020 at 1:55 AM Peter Zijlstra <peterz at infradead.org>> > > > But,... do we still need this in the light of that fine-grained > > > > kaslr > > > > stuff? > > > > > > > > What is the actual value of this PIE crud in the face of that? > > > > > > If I remember well, it makes it easier/better but I haven't seen a > > > recent update on that. Is that accurate Kees? > > > > I believe this patchset is valuable if people are trying to brute force > > guess the kernel location, but not so awesome in the event of > > infoleaks. In the case of the current fgkaslr implementation, we only > > randomize within the existing text segment memory area - so with PIE > > the text segment base can move around more, but within that it wouldn't > > strengthen anything. So, if you have an infoleak, you learn the base > > instantly, and are just left with the same extra protection you get > > without PIE. > > Right -- PIE improves both non- and fg- KASLR similarly, in the sense > that the possible entropy for base offset is expanded. It also opens the > door to doing even more crazy things.So I'm really confused. I see it increases the aslr range, but I'm still not sure why we care in the face of fgkaslr. Current kaslr is completely broken because the hardware leaks more bits than we currently have, even without the kernel itself leaking an address. But leaking a single address is not a problem with fgkaslr.> (e.g. why keep the kernel text all > in one contiguous chunk?)Dear gawd, please no. Also, we're limited to 2G text, that's just not a lot of room. I'm really going to object when people propose we introduce direct PLT for x86.> And generally speaking, it seems a nice improvement to me, as it gives > the kernel greater addressing flexibility.But at what cost; it does unspeakable ugly to the asm. And didn't a kernel compiled with the extended PIE range produce a measurably slower kernel due to all the ugly? So maybe I'm slow, but please spell out the benefit, because I'm not seeing it.
Kees Cook
2020-Mar-04 18:21 UTC
[PATCH v11 00/11] x86: PIE support to extend KASLR randomization
On Wed, Mar 04, 2020 at 10:21:36AM +0100, Peter Zijlstra wrote:> But at what cost; it does unspeakable ugly to the asm. And didn't a > kernel compiled with the extended PIE range produce a measurably slower > kernel due to all the ugly?Was that true? I thought the final results were a wash and that earlier benchmarks weren't accurate for some reason? I can't find the thread now. Thomas, do you have numbers on that? BTW, I totally agree that fgkaslr is the way to go in the future. I am mostly arguing for this under the assumption that it doesn't have meaningful performance impact and that it gains the kernel some flexibility in the kinds of things it can do in the future. If the former is not true, then I'd agree, the benefit needs to be more clear. -- Kees Cook
H. Peter Anvin
2020-Mar-04 18:44 UTC
[PATCH v11 00/11] x86: PIE support to extend KASLR randomization
On 2020-03-04 10:21, Kees Cook wrote:> On Wed, Mar 04, 2020 at 10:21:36AM +0100, Peter Zijlstra wrote: >> But at what cost; it does unspeakable ugly to the asm. And didn't a >> kernel compiled with the extended PIE range produce a measurably slower >> kernel due to all the ugly? > > Was that true? I thought the final results were a wash and that earlier > benchmarks weren't accurate for some reason? I can't find the thread > now. Thomas, do you have numbers on that? > > BTW, I totally agree that fgkaslr is the way to go in the future. I > am mostly arguing for this under the assumption that it doesn't > have meaningful performance impact and that it gains the kernel some > flexibility in the kinds of things it can do in the future. If the former > is not true, then I'd agree, the benefit needs to be more clear. >"Making the assembly really ugly" by itself is a reason not to do it, in my Not So Humble Opinion[TM]; but the reason the kernel and small memory models exist in the first place is because there is a nonzero performance impact of the small-PIC memory model. Having modules in separate regions would further add the cost of a GOT references all over the place (PLT is optional, useless and deprecated for eager binding) *plus* might introduce at least one new vector of attack: overwrite a random GOT slot, and just wait until it gets hit by whatever code path it happens to be in; the exact code path doesn't matter.>From an kASLR perspective this is *very* bad, since you only need to guess thegeneral region of a GOT rather than an exact address. The huge memory model, required for arbitrary placement, has a very significant performance impact. The assembly code is *very* different across memory models. -hpa
Maybe Matching Threads
- [PATCH v11 00/11] x86: PIE support to extend KASLR randomization
- [PATCH v11 00/11] x86: PIE support to extend KASLR randomization
- [PATCH v11 00/11] x86: PIE support to extend KASLR randomization
- [PATCH v11 00/11] x86: PIE support to extend KASLR randomization
- [PATCH v11 00/11] x86: PIE support to extend KASLR randomization