linux-kernel - Re: [PATCH 7/9] x86/unwind/orc: Fall back to using frame pointers for generated code

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: <20190614155620.f2kdlh4ttrxyyzuc@treble>
Date:   Fri, 14 Jun 2019 10:56:20 -0500
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Network Development <netdev@...r.kernel.org>,
        bpf <bpf@...r.kernel.org>, Peter Zijlstra <peterz@...radead.org>,
        Song Liu <songliubraving@...com>,
        Kairui Song <kasong@...hat.com>
Subject: Re: [PATCH 7/9] x86/unwind/orc: Fall back to using frame pointers
 for generated code

On Fri, Jun 14, 2019 at 08:31:53AM -0700, Alexei Starovoitov wrote:
> On Fri, Jun 14, 2019 at 6:34 AM Josh Poimboeuf <jpoimboe@...hat.com> wrote:
> >
> > On Thu, Jun 13, 2019 at 11:00:09PM -0700, Alexei Starovoitov wrote:
> > > > +   if (src_reg == BPF_REG_FP) {
> > > > +           /*
> > > > +            * If the value was copied from RBP (real frame pointer),
> > > > +            * adjust it to the BPF program's frame pointer value.
> > > > +            *
> > > > +            * add dst, -40
> > > > +            */
> > > > +           EMIT4(add_1mod(0x48, dst_reg), 0x83, add_1reg(0xC0, dst_reg),
> > > > +                 0xD8);
> > > > +   }
> > > > +
> > >
> > > That won't work. Any register can point to a stack.
> >
> > Right, but if the stack pointer comes from BPF_REG_FP then won't the
> > above correct it?  Then if the pointer gets passed around to other
> > registers it will have the correct value.  Or did I miss your point?
> 
> At the beginning of the program frame pointer is bpf_reg_fp,
> but later it can be in any register. It can be spilled into stack.
> Some math done on it and that adjusted pointer passed into
> another jited function.
> It's perfectly fine for one bpf program to modify stack of
> another bpf program. The verifier checks the safety bounds, etc.

I still don't get what you're saying.  The above patch attempted to
cover all those scenarios by always subtracting an offset from all movs
and stack accesses relating to BPF_REG_FP.  It might be missing a case
or two but it seems like it should work.  From the program's point of
view, BPF_REG_FP should always show the right value no matter where it
gets moved to.

But anyway, David L's nested frame idea might be a much simpler change.
I'll look at that.

-- 
Josh