On Fri, Feb 18, 2022, Will McVicker wrote: > 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... Peter and/or Kees, can you provide a pointer to the patches that could potentially be used as a basis for fixing ARM CFI? Or even better, send a patch to actually fix this? :-) _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
