similar to: [PATCH v1 00/27] x86: PIE support and option to extend KASLR randomization

Displaying 20 results from an estimated 4000 matches similar to: "[PATCH v1 00/27] x86: PIE support and option to extend KASLR randomization"

2018 Mar 13
32
[PATCH v2 00/27] x86: PIE support and option to extend KASLR randomization
Changes: - 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
2018 Mar 13
32
[PATCH v2 00/27] x86: PIE support and option to extend KASLR randomization
Changes: - 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
2017 Oct 04
28
x86: PIE support and option to extend KASLR randomization
These patches make the changes necessary to build the kernel as Position Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below the top 2G of the virtual address space. It allows to optionally extend the KASLR randomization range from 1G to 3G. Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler changes, PIE support and KASLR in general. Thanks to
2017 Oct 04
28
x86: PIE support and option to extend KASLR randomization
These patches make the changes necessary to build the kernel as Position Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below the top 2G of the virtual address space. It allows to optionally extend the KASLR randomization range from 1G to 3G. Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler changes, PIE support and KASLR in general. Thanks to
2018 May 23
33
[PATCH v3 00/27] x86: PIE support and option to extend KASLR randomization
Changes: - 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
2017 Oct 11
1
[PATCH v1 01/27] x86/crypto: Adapt assembly for PIE support
Change the assembly code to use only relative references of symbols for the kernel to be PIE compatible. Position Independent Executable (PIE) support will allow to extended the KASLR randomization range below the -2G memory limit. Signed-off-by: Thomas Garnier <thgarnie at google.com> --- arch/x86/crypto/aes-x86_64-asm_64.S | 45 ++++++++----- arch/x86/crypto/aesni-intel_asm.S
2017 Oct 20
1
[PATCH v1 01/27] x86/crypto: Adapt assembly for PIE support
On 20 October 2017 at 09:24, Ingo Molnar <mingo at kernel.org> wrote: > > * Thomas Garnier <thgarnie at google.com> wrote: > >> Change the assembly code to use only relative references of symbols for the >> kernel to be PIE compatible. >> >> Position Independent Executable (PIE) support will allow to extended the >> KASLR randomization range below
2017 Oct 20
1
[PATCH v1 01/27] x86/crypto: Adapt assembly for PIE support
On 20 October 2017 at 09:24, Ingo Molnar <mingo at kernel.org> wrote: > > * Thomas Garnier <thgarnie at google.com> wrote: > >> Change the assembly code to use only relative references of symbols for the >> kernel to be PIE compatible. >> >> Position Independent Executable (PIE) support will allow to extended the >> KASLR randomization range below
2017 Oct 03
2
invalid code generated on Windows x86_64 using skylake-specific features
I figured it out. I was using this implementation of __chkstk from compiler-rt: DEFINE_COMPILERRT_FUNCTION(___chkstk) push %rcx cmp $0x1000,%rax lea 16(%rsp),%rcx // rsp before calling this routine -> rcx jb 1f 2: sub $0x1000,%rcx test %rcx,(%rcx) sub $0x1000,%rax cmp $0x1000,%rax ja 2b 1:
2019 Jul 08
3
[PATCH v8 00/11] x86: PIE support to extend KASLR randomization
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 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
2019 Jul 08
3
[PATCH v8 00/11] x86: PIE support to extend KASLR randomization
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 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
2017 Oct 01
1
invalid code generated on Windows x86_64 using skylake-specific features
I suspect that there are 2 issues here: * I have incorrect alignment somewhere * MSVC / .pdb / CodeView debugging is not working correctly. I think the latter would help solve the former. I will send out a new email later talking about the issues I'm having debugging llvm-generated binaries with MSVC. On Sat, Sep 30, 2017 at 3:33 PM, Andrew Kelley <superjoe30 at gmail.com> wrote:
2017 Oct 12
3
[PATCH v1 00/27] x86: PIE support and option to extend KASLR randomization
On Wed, Oct 11, 2017 at 2:34 PM, Tom Lendacky <thomas.lendacky at amd.com> wrote: > On 10/11/2017 3:30 PM, Thomas Garnier wrote: >> Changes: >> - 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
2017 Oct 12
3
[PATCH v1 00/27] x86: PIE support and option to extend KASLR randomization
On Wed, Oct 11, 2017 at 2:34 PM, Tom Lendacky <thomas.lendacky at amd.com> wrote: > On 10/11/2017 3:30 PM, Thomas Garnier wrote: >> Changes: >> - 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
2017 Feb 17
2
Vector trunc code generation difference between llvm-3.9 and 4.0
Correction in the C snippet: typedef signed short v8i16_t __attribute__((ext_vector_type(8))); v8i16_t foo (v8i16_t a, int n) { return a >> n; } Best regards Saurabh On 17 February 2017 at 16:21, Saurabh Verma <saurabh.verma at movidius.com> wrote: > Hello, > > We are investigating a difference in code generation for vector splat > instructions between llvm-3.9
2017 Feb 18
2
Vector trunc code generation difference between llvm-3.9 and 4.0
Thanks Sanjay. Interestingly for me, disable-llvm-optmzns did not make a difference in the way the shift was handled. Does the initial IR generated for you show this difference when the option is passed? Best regards Saurabh On 17 February 2017 at 19:03, Sanjay Patel <spatel at rotateright.com> wrote: > I think this is caused by a front-end change (cc'ing clang-dev) because >
2017 Oct 20
0
[PATCH v1 01/27] x86/crypto: Adapt assembly for PIE support
* Thomas Garnier <thgarnie at google.com> wrote: > Change the assembly code to use only relative references of symbols for the > kernel to be PIE compatible. > > Position Independent Executable (PIE) support will allow to extended the > KASLR randomization range below the -2G memory limit. > diff --git a/arch/x86/crypto/aes-x86_64-asm_64.S
2017 Mar 08
2
Vector trunc code generation difference between llvm-3.9 and 4.0
The regression for the reported case should be avoided after: https://reviews.llvm.org/rL297232 https://reviews.llvm.org/rL297242 https://reviews.llvm.org/rL297280 It would still be good to understand if the clang change was intentional or if that was a side effect that can be limited. On Sat, Feb 18, 2017 at 9:11 AM, Sanjay Patel <spatel at rotateright.com> wrote: > Yes, there is an
2017 Oct 11
1
[PATCH v1 06/27] x86/entry/64: Adapt assembly for PIE support
Change the assembly code to use only relative references of symbols for the kernel to be PIE compatible. Position Independent Executable (PIE) support will allow to extended the KASLR randomization range below the -2G memory limit. Signed-off-by: Thomas Garnier <thgarnie at google.com> --- arch/x86/entry/entry_64.S | 22 +++++++++++++++------- 1 file changed, 15 insertions(+), 7
2017 Oct 20
3
[PATCH v1 06/27] x86/entry/64: Adapt assembly for PIE support
On Fri, Oct 20, 2017 at 1:26 AM, Ingo Molnar <mingo at kernel.org> wrote: > > * Thomas Garnier <thgarnie at google.com> wrote: > >> Change the assembly code to use only relative references of symbols for the >> kernel to be PIE compatible. >> >> Position Independent Executable (PIE) support will allow to extended the >> KASLR randomization range