From: Kees Cook <keescook@chromium.org>
To: sxwjean@me.com
Cc: x86@kernel.org, Xiongwei Song <sxwjean@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Gabriel Krisman Bertazi <krisman@collabora.com>,
Andy Lutomirski <luto@kernel.org>,
"Chang S. Bae" <chang.seok.bae@intel.com>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] x86/elf: Fix incorrect STACK_RND_MASK for x86_64
Date: Thu, 14 Oct 2021 09:10:03 -0700 [thread overview]
Message-ID: <202110140909.8CFD5377@keescook> (raw)
In-Reply-To: <20211014132736.266553-1-sxwjean@me.com>
On Thu, Oct 14, 2021 at 09:27:36PM +0800, sxwjean@me.com wrote:
> From: Xiongwei Song <sxwjean@gmail.com>
>
> According to the comment for stack randomization of x86, the range of
> randomization is 1GB, which occupies 30 valid bits in binary. And in
> x86_64, PAGE_SHIFT occupies 12 bits, then the STACK_RND_MASK should
> occupy 18 bits for 1GB.
>
> The current range of randomization is :
> 0x3fffff << PAGE_SHIFT
> , which occupies 34 bits.
>
> This patch changed 0x3fffff to 0x3ffff, which makes the range of stack
> randomization is real 1GB.
Why do we want to _reduce_ entropy here? Perhaps adjust the comment
instead?
-Kees
>
> Before this patch(bit0 ~ bit33 randomized):
> root@qemux86-64:~# for i in {1..20};do cat /proc/self/maps | grep stack;done
> 7ffddf971000-7ffddf992000 rw-p 00000000 00:00 0 [stack]
> 7ffc4e0d4000-7ffc4e0f5000 rw-p 00000000 00:00 0 [stack]
> 7fff5898e000-7fff589af000 rw-p 00000000 00:00 0 [stack]
> 7ffcf910b000-7ffcf912c000 rw-p 00000000 00:00 0 [stack]
> 7ffce829d000-7ffce82be000 rw-p 00000000 00:00 0 [stack]
> 7ffec72d9000-7ffec72fa000 rw-p 00000000 00:00 0 [stack]
> 7ffd6e256000-7ffd6e277000 rw-p 00000000 00:00 0 [stack]
> 7ffe14120000-7ffe14141000 rw-p 00000000 00:00 0 [stack]
> 7ffe21549000-7ffe2156a000 rw-p 00000000 00:00 0 [stack]
> 7ffdc9d33000-7ffdc9d54000 rw-p 00000000 00:00 0 [stack]
> 7ffe1ced4000-7ffe1cef5000 rw-p 00000000 00:00 0 [stack]
> 7ffcb0440000-7ffcb0461000 rw-p 00000000 00:00 0 [stack]
> 7ffc84515000-7ffc84536000 rw-p 00000000 00:00 0 [stack]
> 7ffe557dd000-7ffe557fe000 rw-p 00000000 00:00 0 [stack]
> 7ffdcb7e4000-7ffdcb805000 rw-p 00000000 00:00 0 [stack]
> 7ffc6f989000-7ffc6f9aa000 rw-p 00000000 00:00 0 [stack]
> 7ffd9322a000-7ffd9324b000 rw-p 00000000 00:00 0 [stack]
> 7ffea8e34000-7ffea8e55000 rw-p 00000000 00:00 0 [stack]
> 7ffc594ff000-7ffc59520000 rw-p 00000000 00:00 0 [stack]
> 7ffe8db65000-7ffe8db86000 rw-p 00000000 00:00 0 [stack]
>
> After this patch(bit0 ~ bit29 randomized):
> root@qemux86-64:~# for i in {1..20};do cat /proc/self/maps | grep stack;done
> 7fffd0ed2000-7fffd0ef3000 rw-p 00000000 00:00 0 [stack]
> 7fffdf555000-7fffdf576000 rw-p 00000000 00:00 0 [stack]
> 7ffffec0e000-7ffffec2f000 rw-p 00000000 00:00 0 [stack]
> 7fffcfa0f000-7fffcfa30000 rw-p 00000000 00:00 0 [stack]
> 7fffff75d000-7fffff77e000 rw-p 00000000 00:00 0 [stack]
> 7fffd1d11000-7fffd1d32000 rw-p 00000000 00:00 0 [stack]
> 7fffc7850000-7fffc7871000 rw-p 00000000 00:00 0 [stack]
> 7fffc956e000-7fffc958f000 rw-p 00000000 00:00 0 [stack]
> 7fffdf7be000-7fffdf7df000 rw-p 00000000 00:00 0 [stack]
> 7fffeffdf000-7ffff0000000 rw-p 00000000 00:00 0 [stack]
> 7fffd7d7f000-7fffd7da0000 rw-p 00000000 00:00 0 [stack]
> 7fffe3d23000-7fffe3d44000 rw-p 00000000 00:00 0 [stack]
> 7fffde4b7000-7fffde4d8000 rw-p 00000000 00:00 0 [stack]
> 7fffd477a000-7fffd479b000 rw-p 00000000 00:00 0 [stack]
> 7fffc0e95000-7fffc0eb6000 rw-p 00000000 00:00 0 [stack]
> 7fffdbdda000-7fffdbdfb000 rw-p 00000000 00:00 0 [stack]
> 7fffec737000-7fffec758000 rw-p 00000000 00:00 0 [stack]
> 7fffed163000-7fffed184000 rw-p 00000000 00:00 0 [stack]
> 7ffff9a9c000-7ffff9abd000 rw-p 00000000 00:00 0 [stack]
> 7fffff945000-7fffff966000 rw-p 00000000 00:00 0 [stack]
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Gabriel Krisman Bertazi <krisman@collabora.com>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: "Chang S. Bae" <chang.seok.bae@intel.com>
> Cc: Al Viro <viro@zeniv.linux.org.uk>
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Xiongwei Song <sxwjean@gmail.com>
> ---
> arch/x86/include/asm/elf.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/elf.h b/arch/x86/include/asm/elf.h
> index 29fea180a665..0b7a5510ebd5 100644
> --- a/arch/x86/include/asm/elf.h
> +++ b/arch/x86/include/asm/elf.h
> @@ -343,7 +343,7 @@ extern unsigned long get_sigframe_size(void);
> #else /* CONFIG_X86_32 */
>
> /* 1GB for 64bit, 8MB for 32bit */
> -#define __STACK_RND_MASK(is32bit) ((is32bit) ? 0x7ff : 0x3fffff)
> +#define __STACK_RND_MASK(is32bit) ((is32bit) ? 0x7ff : 0x3ffff)
> #define STACK_RND_MASK __STACK_RND_MASK(mmap_is_ia32())
>
> #define ARCH_DLINFO \
> --
> 2.30.2
>
--
Kees Cook
next prev parent reply other threads:[~2021-10-14 16:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-14 13:27 [PATCH RFC] x86/elf: Fix incorrect STACK_RND_MASK for x86_64 sxwjean
2021-10-14 16:10 ` Kees Cook [this message]
2021-10-15 2:21 ` Xiongwei Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202110140909.8CFD5377@keescook \
--to=keescook@chromium.org \
--cc=bp@alien8.de \
--cc=chang.seok.bae@intel.com \
--cc=hpa@zytor.com \
--cc=krisman@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=sxwjean@gmail.com \
--cc=sxwjean@me.com \
--cc=tglx@linutronix.de \
--cc=viro@zeniv.linux.org.uk \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox