| Message ID | 20230408152722.3975985-1-ardb@kernel.org |
|---|---|
| Headers | show |
| Series | crypto: x86 - avoid absolute references | expand |
On Sat, 8 Apr 2023 at 17:27, Ard Biesheuvel <ardb@kernel.org> wrote: > > This is preparatory work for allowing the kernel to be built as a PIE > executable, which relies mostly on RIP-relative symbol references from > code, which don't need to be updated when a binary is loaded at an > address different from its link time address. > > Most changes are quite straight-forward, i.e., just adding a (%rip) > suffix is enough in many cases. However, some are slightly trickier, and > need some minor reshuffling of the asm code to get rid of the absolute > references in the code. > > Tested with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y on a x86 CPU that > implements AVX, AVX2 and AVX512. > > Cc: Herbert Xu <herbert@gondor.apana.org.au> > Cc: Eric Biggers <ebiggers@kernel.org> > Cc: Kees Cook <keescook@chromium.org> > > Ard Biesheuvel (10): > crypto: x86/camellia - Use RIP-relative addressing > crypto: x86/cast5 - Use RIP-relative addressing > crypto: x86/cast6 - Use RIP-relative addressing > crypto: x86/des3 - Use RIP-relative addressing Note: the patches above are Co-developed-by: Thomas Garnier <thgarnie@chromium.org> Signed-off-by: Thomas Garnier <thgarnie@chromium.org> but this got lost inadvertently - apologies. Herbert: will patchwork pick those up if I put them in a reply to each of those individual patches? Thanks, > crypto: x86/aegis128 - Use RIP-relative addressing > crypto: x86/aesni - Use RIP-relative addressing > crypto: x86/aria - Use RIP-relative addressing > crypto: x86/crc32c - Use RIP-relative addressing > crypto: x86/ghash - Use RIP-relative addressing > crypto: x86/sha256 - Use RIP-relative addressing > > arch/x86/crypto/aegis128-aesni-asm.S | 6 +- > arch/x86/crypto/aesni-intel_asm.S | 2 +- > arch/x86/crypto/aesni-intel_avx-x86_64.S | 6 +- > arch/x86/crypto/aria-aesni-avx-asm_64.S | 28 +++--- > arch/x86/crypto/aria-aesni-avx2-asm_64.S | 28 +++--- > arch/x86/crypto/aria-gfni-avx512-asm_64.S | 24 ++--- > arch/x86/crypto/camellia-aesni-avx-asm_64.S | 30 +++--- > arch/x86/crypto/camellia-aesni-avx2-asm_64.S | 30 +++--- > arch/x86/crypto/camellia-x86_64-asm_64.S | 8 +- > arch/x86/crypto/cast5-avx-x86_64-asm_64.S | 50 +++++----- > arch/x86/crypto/cast6-avx-x86_64-asm_64.S | 44 +++++---- > arch/x86/crypto/crc32c-pcl-intel-asm_64.S | 3 +- > arch/x86/crypto/des3_ede-asm_64.S | 96 +++++++++++++------- > arch/x86/crypto/ghash-clmulni-intel_asm.S | 4 +- > arch/x86/crypto/sha256-avx2-asm.S | 18 ++-- > 15 files changed, 213 insertions(+), 164 deletions(-) > > -- > 2.39.2 >
On Sat, 8 Apr 2023 at 17:32, Ard Biesheuvel <ardb@kernel.org> wrote: > > On Sat, 8 Apr 2023 at 17:27, Ard Biesheuvel <ardb@kernel.org> wrote: > > > > This is preparatory work for allowing the kernel to be built as a PIE > > executable, which relies mostly on RIP-relative symbol references from > > code, which don't need to be updated when a binary is loaded at an > > address different from its link time address. > > > > Most changes are quite straight-forward, i.e., just adding a (%rip) > > suffix is enough in many cases. However, some are slightly trickier, and > > need some minor reshuffling of the asm code to get rid of the absolute > > references in the code. > > > > Tested with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y on a x86 CPU that > > implements AVX, AVX2 and AVX512. > > > > Cc: Herbert Xu <herbert@gondor.apana.org.au> > > Cc: Eric Biggers <ebiggers@kernel.org> > > Cc: Kees Cook <keescook@chromium.org> > > > > Ard Biesheuvel (10): > > > crypto: x86/camellia - Use RIP-relative addressing > > crypto: x86/cast5 - Use RIP-relative addressing > > crypto: x86/cast6 - Use RIP-relative addressing > > crypto: x86/des3 - Use RIP-relative addressing > > Note: the patches above are > > Co-developed-by: Thomas Garnier <thgarnie@chromium.org> > Signed-off-by: Thomas Garnier <thgarnie@chromium.org> > > but this got lost inadvertently - apologies. > > Herbert: will patchwork pick those up if I put them in a reply to each > of those individual patches? > Never mind, I'll be sending out a v2 in any case.