search for: kaslr

...dler in place the identity mapping can be built on-demand. So remove the code which manually creates the mappings and unexport/remove the functions used for it. Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/boot/compressed/ident_map_64.c | 6 ++---- arch/x86/boot/compressed/kaslr.c | 24 +----------------------- arch/x86/boot/compressed/misc.h | 10 ---------- 3 files changed, 3 insertions(+), 37 deletions(-) diff --git a/arch/x86/boot/compressed/ident_map_64.c b/arch/x86/boot/compressed/ident_map_64.c index ecf9353b064d..c63257bf8373 100644 --- a/arch/x86/b...

...bjtool to detect non-compliant PIE relocations is not yet > possible as this patchset only includes the simplest PIE changes. > Additional changes are needed in kvm, xen and percpu code. > > Changes: > - patch v11 (assembly); > - Fix comments on x86/entry/64. > - Remove KASLR PIE explanation on all commits. > - Add note on objtool not being possible at this stage of the patchset. This moves us closer to PIE in a clean first step. I think these patches look good to go, and unblock the work in kvm, xen, and percpu code. Can one of the x86 maintainers pick this seri...

...bjtool to detect non-compliant PIE relocations is not yet > possible as this patchset only includes the simplest PIE changes. > Additional changes are needed in kvm, xen and percpu code. > > Changes: > - patch v11 (assembly); > - Fix comments on x86/entry/64. > - Remove KASLR PIE explanation on all commits. > - Add note on objtool not being possible at this stage of the patchset. This moves us closer to PIE in a clean first step. I think these patches look good to go, and unblock the work in kvm, xen, and percpu code. Can one of the x86 maintainers pick this seri...

...changes. > > > > > Additional changes are needed in kvm, xen and percpu code. > > > > > > > > > > Changes: > > > > > - patch v11 (assembly); > > > > > - Fix comments on x86/entry/64. > > > > > - Remove KASLR PIE explanation on all commits. > > > > > - Add note on objtool not being possible at this stage of > > > > > the patchset. > > > > > > > > This moves us closer to PIE in a clean first step. I think these > > > > patches > &gt...

...relocations is not yet > > possible as this patchset only includes the simplest PIE changes. > > Additional changes are needed in kvm, xen and percpu code. > > > > Changes: > > - patch v11 (assembly); > > - Fix comments on x86/entry/64. > > - Remove KASLR PIE explanation on all commits. > > - Add note on objtool not being possible at this stage of the patchset. > > This moves us closer to PIE in a clean first step. I think these patches > look good to go, and unblock the work in kvm, xen, and percpu code. Can > one of the x86 m...

...00, 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? >...

...00, 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? >...

...gt; 64-bit mode, MOVs with 64-bit immediates, etc, for example) and I'm > > > willing to bet money that some future unrelated change will break PIE > > > sooner or later. > > The goal is being able to extend the range of addresses where the > kernel can be placed with KASLR. I will look at clarifying that in the > future. > > > > > Possibly objtool can help here; it should be possible to teach it about > > these rules, and then it will yell when violated. That should avoid > > regressions. > > > > I will look into that as well...

From: Joerg Roedel <jroedel at suse.de> When booted through startup_64 the kernel keeps running on the EFI page-table until the KASLR code sets up its own page-table. Without KASLR the pre-decompression boot code never switches off the EFI page-table. Change that by unconditionally switching to a kernel controlled page-table after relocation. This makes sure we can make changes to the mapping when necessary, for example map page...

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

...erg Roedel <jroedel at suse.de> The file contains only code related to identity mapped page-tables. Rename the file and compile it always in. Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/boot/compressed/Makefile | 2 +- arch/x86/boot/compressed/{kaslr_64.c => ident_map_64.c} | 9 +++++++++ arch/x86/boot/compressed/kaslr.c | 9 --------- arch/x86/boot/compressed/misc.h | 8 ++++++++ 4 files changed, 18 insertions(+), 10 deletions(-) rename arch/x86/boot/compressed/{kaslr_64.c => ident_map_64.c...

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

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

On Tue, Jul 30, 2019 at 12:12:44PM -0700, Thomas Garnier wrote: > These patches make some of the changes necessary to build the kernel as > Position Independent Executable (PIE) on x86_64. Another patchset will > add the PIE option and larger architecture changes. Yeah, about this: do we have a longer writeup about the actual benefits of all this and why we should take this all? After

On Wed, Dec 04, 2019 at 04:09:37PM -0800, Thomas Garnier wrote: > Minor changes based on feedback and rebase from v9. > > 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. ISTR suggestion you add an objtool pass that verifies there are no absolute text references

On Wed, Dec 04, 2019 at 04:09:37PM -0800, Thomas Garnier wrote: > Minor changes based on feedback and rebase from v9. > > 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. Ok, modulo the minor commit message and comments fixup, this looks ok and passes testing here.

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

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. Changes: - patch v7 (assembly): - Split patchset and reorder changes. - patch v6: - Rebase on latest changes in jump tables and crypto. - Fix wording on couple commits. - Revisit checkpatch warnings. - Moving to

...direct dependencies with the rest of the patchset. Changes: - patch v10 (assembly): - Swap rax for rdx on entry/64 changes based on feedback. - Addressed feedback from Borislav Petkov on boot, paravirt, alternatives and globally. - Rebased the patchset and ensure it works with large kaslr (not included). - patch v9 (assembly): - Moved to relative reference for sync_core based on feedback. - x86/crypto had multiple algorithms deleted, removed PIE changes to them. - fix typo on comment end line. - patch v8 (assembly): - Fix issues in crypto changes (thanks to Eric Bigger...

...direct dependencies with the rest of the patchset. Changes: - patch v10 (assembly): - Swap rax for rdx on entry/64 changes based on feedback. - Addressed feedback from Borislav Petkov on boot, paravirt, alternatives and globally. - Rebased the patchset and ensure it works with large kaslr (not included). - patch v9 (assembly): - Moved to relative reference for sync_core based on feedback. - x86/crypto had multiple algorithms deleted, removed PIE changes to them. - fix typo on comment end line. - patch v8 (assembly): - Fix issues in crypto changes (thanks to Eric Bigger...