Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

x86_64: move vdso to mmap region from stack region #280

Open
thestinger opened this issue Apr 22, 2023 · 2 comments
Open

x86_64: move vdso to mmap region from stack region #280

thestinger opened this issue Apr 22, 2023 · 2 comments
Assignees
@kees
Labels
[ARCH] x86_64 Needed on the 64-bit x86 architecture (ARCH=x86) [Feature] ASLR involves address space layout randomization [PATCH] Submitted A patch has been submitted upstream

Comments

@thestinger
Copy link

thestinger commented Apr 22, 2023 •
edited
Loading

x86_64 unnecessarily places the vdso at a random low entropy offset from the stack instead of simply putting it in the mmap region where position independent executables and dynamic libraries loaded by the linker are placed. There should not be executable code at a low entropy offset from the stack, since the stack and executable code having separate randomization is part of what makes ASLR stronger. It makes sense to have a separate base or multiple separate bases for the malloc heap from executable code but this does not help and it's not up to the kernel to provide it. Ready to go patch from linux-hardened with no known compatibility issues:

https://github.com/anthraxx/linux-hardened/commit/54a53f4234e10f942de809f9c76701d2f6186085.patch
@kees kees self-assigned this Feb 10, 2024
@kees
Copy link

kees commented Feb 10, 2024

Yeah, this is what arm64 already does. Less code, better ASLR. That's a rare change. :)

@kees kees added [ARCH] x86_64 Needed on the 64-bit x86 architecture (ARCH=x86) [PATCH] Exists A patch exists to address the issue [Feature] ASLR involves address space layout randomization [PATCH] Submitted A patch has been submitted upstream and removed [PATCH] Exists A patch exists to address the issue labels Feb 10, 2024
@kees
Copy link

kees commented Feb 10, 2024 •
edited
Loading

Sent: https://lore.kernel.org/linux-hardening/20240210091827.work.233-kees@kernel.org

ColinIanKing pushed a commit to ColinIanKing/linux-next that referenced this issue Feb 22, 2024
@thestinger @kees
x86/vdso: Move vDSO to mmap region
e3508ea 
The vDSO (and its initial randomization) was introduced in commit
2aae950 ("x86_64: Add vDSO for x86-64 with gettimeofday/clock_gettime/getcpu"),
but had very low entropy. The entropy was improved in commit
394f56f ("x86_64, vdso: Fix the vdso address randomization algorithm"),
but there is still improvement to be made.

On principle there should not be executable code at a low entropy offset
from the stack, since the stack and executable code having separate
randomization is part of what makes ASLR stronger.

Remove the only executable code near the stack region and give the vDSO
the same randomized base as other mmap mappings including the linker
and other shared objects. This results in higher entropy being provided
and there's little to no advantage in separating this from the existing
executable code there. This is already how other architectures like
arm64 handle the vDSO.

As an side, while it's sensible for userspace to reserve the initial
mmap base as a region for executable code with a random gap for other
mmap allocations, along with providing randomization within that region,
there isn't much the kernel can do to help due to how dynamic linkers
load the shared objects.

This was extracted from the PaX RANDMMAP feature.

Closes: KSPP/linux#280
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: x86@kernel.org
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Nikolay Borisov <nik.borisov@suse.com>
Cc: "Chang S. Bae" <chang.seok.bae@intel.com>
Cc: Igor Zhbanov <i.zhbanov@omprussia.ru>
Cc: Rick Edgecombe <rick.p.edgecombe@intel.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: linux-mm@kvack.org
Signed-off-by: Daniel Micay <danielmicay@gmail.com>
[kees: updated commit log with historical details and other tweaks]
Signed-off-by: Kees Cook <keescook@chromium.org>
staging-kernelci-org pushed a commit to kernelci/linux that referenced this issue Feb 23, 2024
@thestinger @kees
x86/vdso: Move vDSO to mmap region
7f27ac1 
The vDSO (and its initial randomization) was introduced in commit
2aae950 ("x86_64: Add vDSO for x86-64 with gettimeofday/clock_gettime/getcpu"),
but had very low entropy. The entropy was improved in commit
394f56f ("x86_64, vdso: Fix the vdso address randomization algorithm"),
but there is still improvement to be made.

On principle there should not be executable code at a low entropy offset
from the stack, since the stack and executable code having separate
randomization is part of what makes ASLR stronger.

Remove the only executable code near the stack region and give the vDSO
the same randomized base as other mmap mappings including the linker
and other shared objects. This results in higher entropy being provided
and there's little to no advantage in separating this from the existing
executable code there. This is already how other architectures like
arm64 handle the vDSO.

As an side, while it's sensible for userspace to reserve the initial
mmap base as a region for executable code with a random gap for other
mmap allocations, along with providing randomization within that region,
there isn't much the kernel can do to help due to how dynamic linkers
load the shared objects.

This was extracted from the PaX RANDMMAP feature.

Closes: KSPP#280
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: x86@kernel.org
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Nikolay Borisov <nik.borisov@suse.com>
Cc: "Chang S. Bae" <chang.seok.bae@intel.com>
Cc: Igor Zhbanov <i.zhbanov@omprussia.ru>
Cc: Rick Edgecombe <rick.p.edgecombe@intel.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: linux-mm@kvack.org
Signed-off-by: Daniel Micay <danielmicay@gmail.com>
[kees: updated commit log with historical details and other tweaks]
Link: https://lore.kernel.org/all/20240210091827.work.233-kees@kernel.org/
Signed-off-by: Kees Cook <keescook@chromium.org>
roxell pushed a commit to roxell/linux that referenced this issue Feb 26, 2024
@thestinger @kees
x86/vdso: Move vDSO to mmap region
2867ef3 
The vDSO (and its initial randomization) was introduced in commit
2aae950 ("x86_64: Add vDSO for x86-64 with gettimeofday/clock_gettime/getcpu"),
but had very low entropy. The entropy was improved in commit
394f56f ("x86_64, vdso: Fix the vdso address randomization algorithm"),
but there is still improvement to be made.

On principle there should not be executable code at a low entropy offset
from the stack, since the stack and executable code having separate
randomization is part of what makes ASLR stronger.

Remove the only executable code near the stack region and give the vDSO
the same randomized base as other mmap mappings including the linker
and other shared objects. This results in higher entropy being provided
and there's little to no advantage in separating this from the existing
executable code there. This is already how other architectures like
arm64 handle the vDSO.

As an side, while it's sensible for userspace to reserve the initial
mmap base as a region for executable code with a random gap for other
mmap allocations, along with providing randomization within that region,
there isn't much the kernel can do to help due to how dynamic linkers
load the shared objects.

This was extracted from the PaX RANDMMAP feature.

Closes: KSPP#280
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: x86@kernel.org
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Nikolay Borisov <nik.borisov@suse.com>
Cc: "Chang S. Bae" <chang.seok.bae@intel.com>
Cc: Igor Zhbanov <i.zhbanov@omprussia.ru>
Cc: Rick Edgecombe <rick.p.edgecombe@intel.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: linux-mm@kvack.org
Signed-off-by: Daniel Micay <danielmicay@gmail.com>
[kees: updated commit log with historical details and other tweaks]
Link: https://lore.kernel.org/all/20240210091827.work.233-kees@kernel.org/
Signed-off-by: Kees Cook <keescook@chromium.org>
jonhunter pushed a commit to jonhunter/linux that referenced this issue Feb 28, 2024
@thestinger @KAGA-KOKO
x86/vdso: Move vDSO to mmap region
3c6539b 
The vDSO (and its initial randomization) was introduced in commit 2aae950
("x86_64: Add vDSO for x86-64 with gettimeofday/clock_gettime/getcpu"), but
had very low entropy. The entropy was improved in commit 394f56f
("x86_64, vdso: Fix the vdso address randomization algorithm"), but there
is still improvement to be made.

In principle there should not be executable code at a low entropy offset
from the stack, since the stack and executable code having separate
randomization is part of what makes ASLR stronger.

Remove the only executable code near the stack region and give the vDSO
the same randomized base as other mmap mappings including the linker
and other shared objects. This results in higher entropy being provided
and there's little to no advantage in separating this from the existing
executable code there. This is already how other architectures like
arm64 handle the vDSO.

As an side, while it's sensible for userspace to reserve the initial mmap
base as a region for executable code with a random gap for other mmap
allocations, along with providing randomization within that region, there
isn't much the kernel can do to help due to how dynamic linkers load the
shared objects.

This was extracted from the PaX RANDMMAP feature.

[kees: updated commit log with historical details and other tweaks]

Signed-off-by: Daniel Micay <danielmicay@gmail.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Closes: KSPP#280
Link: https://lore.kernel.org/r/20240210091827.work.233-kees@kernel.org
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@kees kees

Labels
[ARCH] x86_64 Needed on the 64-bit x86 architecture (ARCH=x86) [Feature] ASLR involves address space layout randomization [PATCH] Submitted A patch has been submitted upstream
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@kees @thestinger