linux-kernel - Re: [PATCHSET x86/master] add stack protector support for x86

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: <20090209141525.GA24897@elte.hu>
Date:	Mon, 9 Feb 2009 15:15:25 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Brian Gerst <brgerst@...il.com>
Cc:	Tejun Heo <tj@...nel.org>, hpa@...or.com, jeremy@...p.org,
	tglx@...utronix.de, linux-kernel@...r.kernel.org, x86@...nel.org,
	rusty@...tcorp.com.au
Subject: Re: [PATCHSET x86/master] add stack protector support for x86_32


* Brian Gerst <brgerst@...il.com> wrote:

> On Mon, Feb 9, 2009 at 8:39 AM, Tejun Heo <tj@...nel.org> wrote:
> >
> > Hello,
> >
> > This patchset adds stack protector support for x86_32.  The basics are
> > the same with x86_64 but there are some noticeable differences.
> >
> > * x86_32 uses %fs for percpu base.  %gs is unused by the kernel and
> >  managed lazily.  %gs is used for userland TLS and loading %gs with
> >  different value on kernel entry is known to cost quite a bit on some
> >  chips.
> >
> >  Lazy %gs handling is made optional and disabled if stack protector
> >  is enabled.  To do this, entry for %gs is added to pt_regs.  This
> >  adds one "pushl $0" to SAVE_ALL in entry_32.S when lazy %gs is on.
> >  However, no overhead is added to common exit path and error_code
> >  entry path shed a few instructions.  I don't think there will be
> >  noticeable overhead but then again it does add an instruction to a
> >  very hot path.  Would this be okay?
> >
> > * x86_32 doesn't support direct access to shadow part of %gs and
> >  there's no swapgs, so GDT entry should be built for stack canary.
> >
> >  GDT entry 28 is used for this.  The boot cpu one is setup from
> >  head_32.S.  Others while setting up percpu areas.
> >
> > * math_emu register access was completely broken.  Fixed.
> >
> > * x86_32 exception handlers take register frame verbatim as struct
> >  pt_regs.  With -fstack-protector, gcc copies pt_regs into the
> >  callee's stack frame to put it after the stack canary.  Of course it
> >  doesn't copy back (as the callee owns the argument) and any change
> >  made to pt_regs is lost on return.  This is currently worked around
> >  by adding -fno-stack-protector to any file containing such
> >  functions.  We really need to teach gcc about the calling
> >  convention.
> 
> I had a patch a while back that would convert those function to take a
> pointer to pt_regs instead of assuming that the struct was passed by
> value. [...]

Yes, that's the right solution. Getting a new call convention recognized
is a 3 years timeframe project for a whole team of hackers. Adding a
pointer is a 30 minutes project for one good kernel hacker ;)

> [...]  I'll take a stab at reworking it on top of this series.

Cool!

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/