linux-kernel - Re: [PATCH 00/13] Virtually mapped stacks with guard pages (x86, core)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20160620070724.GB3266@osiris>
Date:	Mon, 20 Jun 2016 09:07:24 +0200
From:	Heiko Carstens <heiko.carstens@...ibm.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Nadav Amit <nadav.amit@...il.com>,
	Kees Cook <keescook@...omium.org>,
	Josh Poimboeuf <jpoimboe@...hat.com>,
	Borislav Petkov <bp@...en8.de>, X86 ML <x86@...nel.org>,
	"kernel-hardening@...ts.openwall.com" 
	<kernel-hardening@...ts.openwall.com>,
	Brian Gerst <brgerst@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 00/13] Virtually mapped stacks with guard pages (x86,
 core)

On Sun, Jun 19, 2016 at 11:01:48PM -0700, Andy Lutomirski wrote:
> > The tmll instruction tests if any of the higher bits within the 16k
> > stackframe address are set. In this specific case that would be bits 7-15
> > (mask 0x3f80). If no bit would be set we know that only up to 128 bytes
> > would be left on the stack, and thus trigger an exception.
> >
> > This check does of course only work if a 16k stack is also 16k aligned,
> > which is always the case.
> >
> 
> Oh, interesting.  How do you handle the case of a single function that
> uses more than 128 bytes of stack?

The compiler uses the next larger value of the stackframe size that is a
power of 2 for checking. So another example with a stackframe size of 472
bytes would be the below one with a mask of 0x3e00:

0000000000392db8 <htree_inlinedir_to_tree>:
  392db8:       eb 6f f0 48 00 24       stmg    %r6,%r15,72(%r15)
  392dbe:       a7 f1 3e 00             tmll    %r15,15872
  392dc2:       b9 04 00 ef             lgr     %r14,%r15
  392dc6:       a7 84 00 01             je      392dc8 <htree_inlinedir_to_tree+0x10>
  392dca:       e3 f0 fe 28 ff 71       lay     %r15,-472(%r15)