On Sun, Feb 6, 2022 at 6:56 PM Kees Cook <keescook@xxxxxxxxxxxx> 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 _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
