linux-kernel - Re: [PATCH v4 09/17] perf/core: Use static_call to optimize perf_guest_info

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]

Date:   Fri, 18 Feb 2022 14:35:47 -0800
From:   Will McVicker <willmcvicker@...gle.com>
To:     Kees Cook <keescook@...omium.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Sami Tolvanen <samitolvanen@...gle.com>,
        Sean Christopherson <seanjc@...gle.com>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        kvmarm <kvmarm@...ts.cs.columbia.edu>, kvm@...r.kernel.org
Subject: Re: [PATCH v4 09/17] perf/core: Use static_call to optimize perf_guest_info_callbacks

On Sun, Feb 6, 2022 at 6:56 PM Kees Cook <keescook@...omium.org> wrote:
>
> On Sun, Feb 06, 2022 at 09:28:52PM +0100, Peter Zijlstra wrote:
> > On Sun, Feb 06, 2022 at 10:45:15AM -0800, Kees Cook wrote:
> >
> > > I'm digging through the macros to sort this out, but IIUC, an example of
> > > the problem is:
> > >
> >
> > > so the caller is expecting "unsigned int (*)(void)" but the prototype
> > > of __static_call_return0 is "long (*)(void)":
> > >
> > > long __static_call_return0(void);
> > >
> > > Could we simply declare a type-matched ret0 trampoline too?
> >
> > That'll work for this case, but the next case the function will have
> > arguments we'll need even more nonsense...
>
> Shouldn't the typeof() work there too, though? I.e. as long as the
> return value can hold a "0", it'd work.
>
> > And as stated in that other email, there's tb_stub_func() having the
> > exact same problem as well.
>
> Yeah, I'd need to go look at that again.
>
> > The x86_64 CFI patches had a work-around for this, that could trivially
> > be lifted I suppose.
>
> Yeah, I think it'd be similar. I haven't had a chance to go look at that
> again...
>
> --
> Kees Cook


Hi All,

I noticed that this thread kind of died out. Does anyone have any
action items that need to be followed up to help resolve this issue?
The offending patch is breaking the ARM64 Android Common Kernels
(Pixel 6 in particular) and I imagine it might also have an impact on
other ARM64 platforms upstream that just haven't hit this perf_trace
case yet.

If anyone needs help verifying any fixes, I'm happy to test it out.

Thanks,
Will