| 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
| ||
|
Message-ID: <CALCETrWBcgMihP--g6_G3cStpQ5up8T2QhJn=upvARfr8DgxcQ@mail.gmail.com>
Date: Thu, 12 Mar 2015 13:38:11 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Borislav Petkov <bp@...en8.de>
Cc: Andi Kleen <andi@...stfloor.org>, "H. Peter Anvin" <hpa@...or.com>,
X86 ML <x86@...nel.org>, Al Viro <viro@...iv.linux.org.uk>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH v2 1/2] x86_64,signal: Fix SS handling for signals
delivered to 64-bit programs
On Mar 11, 2015 4:32 AM, "Borislav Petkov" <bp@...en8.de> wrote:
>
> On Tue, Mar 10, 2015 at 07:03:24AM -0700, Andy Lutomirski wrote:
> > The comment in the signal code says that apps can save/restore other
> > segments on their own. It's true that apps can *save* SS on their
> > own, but there's no way for apps to restore it: SYSCALL effectively
> > resets SS to __USER_DS, so any value that user code tries to load
> > into SS gets lost on entry to sigreturn.
> >
> > This recycles two padding bytes in the segment selector area for SS.
> >
> > While we're at it, we need a second change to make this useful. If
> > the signal we're delivering is caused by a bad SS value, saving that
> > value isn't enough. We need to remove that bad value from the regs
> > before we try to deliver the signal. Oddly, x32 already got this
> > right.
>
> Are we at least reporting the bad SS value when delivering the signal so
> that userpsace knows why it got the signal?
Yes, more or less. We'll send sigsegv with an appropriate trapnr.
Without this fix, though, we fail to deliver that signal and kill the
process.
>
> > I suspect that 64-bit programs that try to run 16-bit code and uses
> > signals will have a lot of trouble without this.
>
> Do we even have software doing that? Maybe we should search for similar
> bug reports...
>
> > Signed-off-by: Andy Lutomirski <luto@...capital.net>
> > ---
> > arch/x86/include/asm/sigcontext.h | 2 +-
> > arch/x86/include/uapi/asm/sigcontext.h | 2 +-
> > arch/x86/kernel/signal.c | 20 +++++++++++---------
> > 3 files changed, 13 insertions(+), 11 deletions(-)
> >
> > diff --git a/arch/x86/include/asm/sigcontext.h b/arch/x86/include/asm/sigcontext.h
> > index 9dfce4e0417d..f910cdcb71fd 100644
> > --- a/arch/x86/include/asm/sigcontext.h
> > +++ b/arch/x86/include/asm/sigcontext.h
> > @@ -59,7 +59,7 @@ struct sigcontext {
> > unsigned short cs;
> > unsigned short gs;
> > unsigned short fs;
> > - unsigned short __pad0;
>
> This __pad0 thing has been there since the beginning, according to my
> git history dive.
>
> > + unsigned short ss;
> > unsigned long err;
> > unsigned long trapno;
> > unsigned long oldmask;
> > diff --git a/arch/x86/include/uapi/asm/sigcontext.h b/arch/x86/include/uapi/asm/sigcontext.h
> > index d8b9f9081e86..076b11fd6fa1 100644
> > --- a/arch/x86/include/uapi/asm/sigcontext.h
> > +++ b/arch/x86/include/uapi/asm/sigcontext.h
> > @@ -179,7 +179,7 @@ struct sigcontext {
> > __u16 cs;
> > __u16 gs;
> > __u16 fs;
> > - __u16 __pad0;
> > + __u16 ss;
> > __u64 err;
> > __u64 trapno;
> > __u64 oldmask;
> > diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
> > index ed37a768d0fc..40f34574fb36 100644
> > --- a/arch/x86/kernel/signal.c
> > +++ b/arch/x86/kernel/signal.c
> > @@ -94,15 +94,8 @@ int restore_sigcontext(struct pt_regs *regs, struct sigcontext __user *sc,
> > COPY(r15);
> > #endif /* CONFIG_X86_64 */
> >
> > -#ifdef CONFIG_X86_32
> > COPY_SEG_CPL3(cs);
> > COPY_SEG_CPL3(ss);
> > -#else /* !CONFIG_X86_32 */
> > - /* Kernel saves and restores only the CS segment register on signals,
> > - * which is the bare minimum needed to allow mixed 32/64-bit code.
> > - * App's signal handler can save/restore other segments if needed. */
> > - COPY_SEG_CPL3(cs);
> > -#endif /* CONFIG_X86_32 */
> >
> > get_user_ex(tmpflags, &sc->flags);
> > regs->flags = (regs->flags & ~FIX_EFLAGS) | (tmpflags & FIX_EFLAGS);
> > @@ -164,6 +157,7 @@ int setup_sigcontext(struct sigcontext __user *sc, void __user *fpstate,
> > put_user_ex(regs->cs, &sc->cs);
> > put_user_ex(0, &sc->gs);
> > put_user_ex(0, &sc->fs);
> > + put_user_ex(regs->ss, &sc->ss);
> > #endif /* CONFIG_X86_32 */
> >
> > put_user_ex(fpstate, &sc->fpstate);
> > @@ -457,9 +451,17 @@ static int __setup_rt_frame(int sig, struct ksignal *ksig,
> >
> > regs->sp = (unsigned long)frame;
> >
> > - /* Set up the CS register to run signal handlers in 64-bit mode,
> > - even if the handler happens to be interrupting 32-bit code. */
> > + /* Set up the CS and SS registers to run signal handlers in
> > + 64-bit mode, even if the handler happens to be interrupting
> > + 32-bit or 16-bit code.
> > +
> > + SS is subtle. In 64-bit mode, we don't need any particular
> > + SS descriptor, but we do need SS to be valid. It's possible
> > + that the old SS is entirely bogus -- this can happen if the
> > + signal we're trying to deliver is #GP or #SS caused by a bad
> > + SS value. */
>
> Kernel comment style please:
>
> /*
> * Andy likes to go and play 16-bit games on 64-bit linux. We all are
> * having lotsa fun.
> */
>
> :-D
I did it this way for consistency with every other comment in that
function. I'll change it.
>
> --
> Regards/Gruss,
> Boris.
>
> ECO tip #101: Trim your mails when you reply.
> --
--
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/
Powered by blists - more mailing lists