| Message ID | 20200228000105.165012-1-thgarnie@chromium.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | x86: PIE support to extend KASLR randomization | expand |
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 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 series up? Thanks! -Kees > - 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 Biggers). > - Remove unnecessary jump table change. > - Change author and signoff to chromium email address. > - 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 @chromium.org. > - patch v5: > - Adapt new crypto modules for PIE. > - Improve per-cpu commit message. > - Fix xen 32-bit build error with .quad. > - Remove extra code for ftrace. > - patch v4: > - Simplify early boot by removing global variables. > - Modify the mcount location script for __mcount_loc intead of the address > read in the ftrace implementation. > - Edit commit description to explain better where the kernel can be located. > - Streamlined the testing done on each patch proposal. Always testing > hibernation, suspend, ftrace and kprobe to ensure no regressions. > - patch v3: > - Update on message to describe longer term PIE goal. > - Minor change on ftrace if condition. > - Changed code using xchgq. > - patch v2: > - Adapt patch to work post KPTI and compiler changes > - Redo all performance testing with latest configs and compilers > - Simplify mov macro on PIE (MOVABS now) > - Reduce GOT footprint > - patch v1: > - Simplify ftrace implementation. > - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. > - rfc v3: > - Use --emit-relocs instead of -pie to reduce dynamic relocation space on > mapped memory. It also simplifies the relocation process. > - Move the start the module section next to the kernel. Remove the need for > -mcmodel=large on modules. Extends module space from 1 to 2G maximum. > - Support for XEN PVH as 32-bit relocations can be ignored with > --emit-relocs. > - Support for GOT relocations previously done automatically with -pie. > - Remove need for dynamic PLT in modules. > - Support dymamic GOT for modules. > - rfc v2: > - Add support for global stack cookie while compiler default to fs without > mcmodel=kernel > - Change patch 7 to correctly jump out of the identity mapping on kexec load > preserve. > > 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. PIE allows the kernel to be > placed below the 0xffffffff80000000 increasing the range of KASLR. > > The patches: > - 1, 3-11: Change in assembly code to be PIE compliant. > - 2: Add a new _ASM_MOVABS macro to fetch a symbol address generically. > > diffstat: > crypto/aegis128-aesni-asm.S | 6 +- > crypto/aesni-intel_asm.S | 8 +-- > crypto/aesni-intel_avx-x86_64.S | 3 - > crypto/camellia-aesni-avx-asm_64.S | 42 +++++++-------- > crypto/camellia-aesni-avx2-asm_64.S | 44 ++++++++-------- > crypto/camellia-x86_64-asm_64.S | 8 +-- > crypto/cast5-avx-x86_64-asm_64.S | 50 ++++++++++-------- > crypto/cast6-avx-x86_64-asm_64.S | 44 +++++++++------- > crypto/des3_ede-asm_64.S | 96 ++++++++++++++++++++++++------------ > crypto/ghash-clmulni-intel_asm.S | 4 - > crypto/glue_helper-asm-avx.S | 4 - > crypto/glue_helper-asm-avx2.S | 6 +- > crypto/sha256-avx2-asm.S | 18 ++++-- > entry/entry_64.S | 16 ++++-- > include/asm/alternative.h | 6 +- > include/asm/asm.h | 1 > include/asm/bug.h | 2 > include/asm/paravirt_types.h | 32 ++++++++++-- > include/asm/pm-trace.h | 2 > include/asm/processor.h | 6 +- > kernel/acpi/wakeup_64.S | 31 ++++++----- > kernel/head_64.S | 15 +++-- > kernel/relocate_kernel_64.S | 2 > power/hibernate_asm_64.S | 4 - > 24 files changed, 268 insertions(+), 182 deletions(-) > > Patchset is based on next-20200227. > >
On Mon, Mar 02, 2020 at 09:02:15PM -0800, Kees Cook wrote: > 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 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 series up? 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?
On Tue, Mar 3, 2020 at 1:55 AM Peter Zijlstra <peterz@infradead.org> wrote: > > On Mon, Mar 02, 2020 at 09:02:15PM -0800, Kees Cook wrote: > > 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 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 series up? > > 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?
On Tue, 2020-03-03 at 07:43 -0800, Thomas Garnier wrote: > On Tue, Mar 3, 2020 at 1:55 AM Peter Zijlstra <peterz@infradead.org> > wrote: > > On Mon, Mar 02, 2020 at 09:02:15PM -0800, Kees Cook wrote: > > > 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 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 series up? > > > > 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.
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@infradead.org> > > wrote: > > > On Mon, Mar 02, 2020 at 09:02:15PM -0800, Kees Cook wrote: > > > > 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 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 series up? > > > > > > 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. (e.g. why keep the kernel text all in one contiguous chunk?) And generally speaking, it seems a nice improvement to me, as it gives the kernel greater addressing flexibility.
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@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.
Mailing List <linux-crypto@vger.kernel.org>,LKML <linux-kernel@vger.kernel.org>,virtualization@lists.linux-foundation.org,Linux PM list <linux-pm@vger.kernel.org> From: hpa@zytor.com Message-ID: <F35C8DBD-9AC3-46F2-9043-6CB9A4FDDDC9@zytor.com> On March 3, 2020 1:19:22 PM PST, Kees Cook <keescook@chromium.org> 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@infradead.org> >> > wrote: >> > > On Mon, Mar 02, 2020 at 09:02:15PM -0800, Kees Cook wrote: >> > > > 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 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 series up? >> > > >> > > 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. (e.g. why keep the kernel text >all >in one contiguous chunk?) > >And generally speaking, it seems a nice improvement to me, as it gives >the kernel greater addressing flexibility. The difference in entropy between fgkaslr and extending the kernel to the PIC memory model (which is the real thing this is doing) is immense: The current kASLR has maybe 9 bits of entropy. PIC-model could extend that by at most 16 bits at considerable cost in performance and complexity. Fgkaslr would provide many kilobits worth of entropy; the limiting factor would be the random number source used! With a valid RNG, no two boots across all the computers in the world across all time would have an infinitesimal probability of ever being the same; never mind the infoleak issue. In addition to the combinatorics, fgkaslr pushes randomization right as well as left, so even for the address of any one individual function you get a gain of 15-17 bits. "More is better" is a truism, but so is Amdahl's Law.
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.
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 the general 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
On Wed, Mar 4, 2020 at 10:45 AM H. Peter Anvin <hpa@zytor.com> wrote: > > 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? 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, 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 the > general region of a GOT rather than an exact address. I agree that it would add GOT references and I can explore that more in terms of performance impact and size. This patchset makes the GOT readonly too so I don't think the attack vector applies. > > The huge memory model, required for arbitrary placement, has a very > significant performance impact. I assume you mean mcmodel=large, it doesn't use it. It uses -fPIE and removes -mcmodel=kernel. It favors relative references whenever possible. > > The assembly code is *very* different across memory models. > > -hpa
On 2020-03-04 11:19, Thomas Garnier wrote: >> >> The huge memory model, required for arbitrary placement, has a very >> significant performance impact. > > I assume you mean mcmodel=large, it doesn't use it. It uses -fPIE and > removes -mcmodel=kernel. It favors relative references whenever > possible. > I know... this was in reference to a comment of Kees'. -hpa
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 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. - 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 Biggers). - Remove unnecessary jump table change. - Change author and signoff to chromium email address. - 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 @chromium.org. - patch v5: - Adapt new crypto modules for PIE. - Improve per-cpu commit message. - Fix xen 32-bit build error with .quad. - Remove extra code for ftrace. - patch v4: - Simplify early boot by removing global variables. - Modify the mcount location script for __mcount_loc intead of the address read in the ftrace implementation. - Edit commit description to explain better where the kernel can be located. - Streamlined the testing done on each patch proposal. Always testing hibernation, suspend, ftrace and kprobe to ensure no regressions. - patch v3: - Update on message to describe longer term PIE goal. - Minor change on ftrace if condition. - Changed code using xchgq. - patch v2: - Adapt patch to work post KPTI and compiler changes - Redo all performance testing with latest configs and compilers - Simplify mov macro on PIE (MOVABS now) - Reduce GOT footprint - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce dynamic relocation space on mapped memory. It also simplifies the relocation process. - Move the start the module section next to the kernel. Remove the need for -mcmodel=large on modules. Extends module space from 1 to 2G maximum. - Support for XEN PVH as 32-bit relocations can be ignored with --emit-relocs. - Support for GOT relocations previously done automatically with -pie. - Remove need for dynamic PLT in modules. - Support dymamic GOT for modules. - rfc v2: - Add support for global stack cookie while compiler default to fs without mcmodel=kernel - Change patch 7 to correctly jump out of the identity mapping on kexec load preserve. 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. PIE allows the kernel to be placed below the 0xffffffff80000000 increasing the range of KASLR. The patches: - 1, 3-11: Change in assembly code to be PIE compliant. - 2: Add a new _ASM_MOVABS macro to fetch a symbol address generically. diffstat: crypto/aegis128-aesni-asm.S | 6 +- crypto/aesni-intel_asm.S | 8 +-- crypto/aesni-intel_avx-x86_64.S | 3 - crypto/camellia-aesni-avx-asm_64.S | 42 +++++++-------- crypto/camellia-aesni-avx2-asm_64.S | 44 ++++++++-------- crypto/camellia-x86_64-asm_64.S | 8 +-- crypto/cast5-avx-x86_64-asm_64.S | 50 ++++++++++-------- crypto/cast6-avx-x86_64-asm_64.S | 44 +++++++++------- crypto/des3_ede-asm_64.S | 96 ++++++++++++++++++++++++------------ crypto/ghash-clmulni-intel_asm.S | 4 - crypto/glue_helper-asm-avx.S | 4 - crypto/glue_helper-asm-avx2.S | 6 +- crypto/sha256-avx2-asm.S | 18 ++++-- entry/entry_64.S | 16 ++++-- include/asm/alternative.h | 6 +- include/asm/asm.h | 1 include/asm/bug.h | 2 include/asm/paravirt_types.h | 32 ++++++++++-- include/asm/pm-trace.h | 2 include/asm/processor.h | 6 +- kernel/acpi/wakeup_64.S | 31 ++++++----- kernel/head_64.S | 15 +++-- kernel/relocate_kernel_64.S | 2 power/hibernate_asm_64.S | 4 - 24 files changed, 268 insertions(+), 182 deletions(-) Patchset is based on next-20200227.