linux-kernel - Re: [RFC PATCH 3/4] x86/traps: Attempt to fixup exceptions in vDSO before signaling

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] [day] [month] [year] [list]

Message-ID: <CALCETrXo=KNDWgJqjxBUCpTnPMg9dkPam0FSMC1vwgxhta40SA@mail.gmail.com>
Date:   Thu, 6 Dec 2018 10:49:10 -0800
From:   Andy Lutomirski <luto@...nel.org>
To:     Dave Hansen <dave.hansen@...el.com>
Cc:     "Christopherson, Sean J" <sean.j.christopherson@...el.com>,
        Andrew Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        X86 ML <x86@...nel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        Josh Triplett <josh@...htriplett.org>
Subject: Re: [RFC PATCH 3/4] x86/traps: Attempt to fixup exceptions in vDSO
 before signaling

On Thu, Dec 6, 2018 at 10:22 AM Dave Hansen <dave.hansen@...el.com> wrote:
>
> On 12/5/18 3:20 PM, Sean Christopherson wrote:
> > @@ -223,6 +224,10 @@ do_trap_no_signal(struct task_struct *tsk, int trapnr, const char *str,
> >       tsk->thread.error_code = error_code;
> >       tsk->thread.trap_nr = trapnr;
> >
> > +     if (user_mode(regs) &&
> > +         fixup_vdso_exception(regs, trapnr, error_code, 0))
> > +             return 0;
> > +
> >       return -1;
> >  }
> >
> > @@ -563,6 +568,9 @@ do_general_protection(struct pt_regs *regs, long error_code)
> >       tsk->thread.error_code = error_code;
> >       tsk->thread.trap_nr = X86_TRAP_GP;
> >
> > +     if (fixup_vdso_exception(regs, X86_TRAP_GP, error_code, 0))
> > +             return;
> > +
> >       show_signal(tsk, SIGSEGV, "", desc, regs, error_code);
> >
> >       force_sig(SIGSEGV, tsk);
> > @@ -854,6 +862,9 @@ static void math_error(struct pt_regs *regs, int error_code, int trapnr)
> >       if (!si_code)
> >               return;
> >
> > +     if (fixup_vdso_exception(regs, trapnr, error_code, 0))
> > +             return;
> > +
> >       force_sig_fault(SIGFPE, si_code,
> >                       (void __user *)uprobe_get_trap_addr(regs), task);
> >  }
> > --
>
> Needs commenting, please.
>
> But, also, this seems really ad-hoc.  Probably, that's a result of our
> signal generation being really ad-hoc itself.  But, if this claims
> "Attempt to fixup exceptions in vDSO before signaling", how do we assure
> ourselves that we hit all the ad-hoc signal generation cases?  How do we
> know we didn't miss one or ten?
>
> I want to hear more of the story of how you picked these sites and also
> decided that this is a comprehensive-enough set of sites to patch.

With my maintainer hat on, it would be awesome if we could inspire
Sean to do a nice cleanup and unify the code such that there is a
single "send a signal to user code to report an exception that wasn't
fixed up" path.  But that's also quite a big request for an otherwise
not-terribly-huge patch...

But, in the absence of a cleanup like that, we should at least
enumerate all the signals that are indented to get fixed up somewhere
in the comments or the changelog.  I'm a big suspicious that the
correct answer is "all of them", with the possible exception of MCE.