[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YgAvhG4wvnslbTqP@hirez.programming.kicks-ass.net>
Date: Sun, 6 Feb 2022 21:28:52 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Kees Cook <keescook@...omium.org>
Cc: 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,
Will McVicker <willmcvicker@...gle.com>
Subject: Re: [PATCH v4 09/17] perf/core: Use static_call to optimize
perf_guest_info_callbacks
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...
And as stated in that other email, there's tb_stub_func() having the
exact same problem as well.
The x86_64 CFI patches had a work-around for this, that could trivially
be lifted I suppose.
Powered by blists - more mailing lists