search for: fgkaslr

...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 ju...

...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 ju...

On Thu, Feb 27, 2020 at 04:00:45PM -0800, Thomas Garnier wrote: > Minor changes based on feedback and rebase from v10. > > Splitting the previous serie in two. This part contains assembly code > changes required for PIE but without any direct dependencies with the > rest of the patchset. > > Note: Using objtool to detect non-compliant PIE relocations is not yet > possible

On Thu, Feb 27, 2020 at 04:00:45PM -0800, Thomas Garnier wrote: > Minor changes based on feedback and rebase from v10. > > Splitting the previous serie in two. This part contains assembly code > changes required for PIE but without any direct dependencies with the > rest of the patchset. > > Note: Using objtool to detect non-compliant PIE relocations is not yet > possible

...urably 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, t...

...urably 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, t...

...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...

...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 sam...

...thread > > now. Thomas, do you have numbers on that? I have never seen a significant performance impact. Performance and size is better on more recent versions of gcc as it has better generation of PIE code (for example generation of switches). > > > > 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, t...