Message ID | 20221115030210.3159213-1-sdf@google.com (mailing list archive) |
---|---|
Headers | show |
Series | xdp: hints via kfuncs | expand |
Stanislav Fomichev <sdf@google.com> writes: > - drop __randomize_layout > > Not sure it's possible to sanely expose it via UAPI. Because every > .o potentially gets its own randomized layout, test_progs > refuses to link. So this won't work if the struct is in a kernel-supplied UAPI header (which would include the __randomize_layout tag). But if it's *not* in a UAPI header it should still be included in a stable form (i.e., without the randomize tag) in vmlinux.h, right? Which would be the point: consumers would be forced to read it from there and do CO-RE on it... -Toke
On Tue, Nov 15, 2022 at 7:54 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote: > > Stanislav Fomichev <sdf@google.com> writes: > > > - drop __randomize_layout > > > > Not sure it's possible to sanely expose it via UAPI. Because every > > .o potentially gets its own randomized layout, test_progs > > refuses to link. > > So this won't work if the struct is in a kernel-supplied UAPI header > (which would include the __randomize_layout tag). But if it's *not* in a > UAPI header it should still be included in a stable form (i.e., without > the randomize tag) in vmlinux.h, right? Which would be the point: > consumers would be forced to read it from there and do CO-RE on it... So you're suggesting something like the following in the uapi header? #ifndef __KERNEL__ #define __randomize_layout #endif ? Let me try to add some padding arguments to xdp_skb_metadata plus the above to see how it goes.
Stanislav Fomichev <sdf@google.com> writes: > On Tue, Nov 15, 2022 at 7:54 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote: >> >> Stanislav Fomichev <sdf@google.com> writes: >> >> > - drop __randomize_layout >> > >> > Not sure it's possible to sanely expose it via UAPI. Because every >> > .o potentially gets its own randomized layout, test_progs >> > refuses to link. >> >> So this won't work if the struct is in a kernel-supplied UAPI header >> (which would include the __randomize_layout tag). But if it's *not* in a >> UAPI header it should still be included in a stable form (i.e., without >> the randomize tag) in vmlinux.h, right? Which would be the point: >> consumers would be forced to read it from there and do CO-RE on it... > > So you're suggesting something like the following in the uapi header? > > #ifndef __KERNEL__ > #define __randomize_layout > #endif > > ? I actually just meant "don't put struct xdp_metadata in an UAPI header file at all". However, I can see how that complicates having the skb_metadata pointer in struct xdp_md, so if the above works, that's fine with me as well :) > Let me try to add some padding arguments to xdp_skb_metadata plus the > above to see how it goes. Cool! -Toke
On Tue, Nov 15, 2022 at 10:38 AM Stanislav Fomichev <sdf@google.com> wrote: > > On Tue, Nov 15, 2022 at 7:54 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote: > > > > Stanislav Fomichev <sdf@google.com> writes: > > > > > - drop __randomize_layout > > > > > > Not sure it's possible to sanely expose it via UAPI. Because every > > > .o potentially gets its own randomized layout, test_progs > > > refuses to link. > > > > So this won't work if the struct is in a kernel-supplied UAPI header > > (which would include the __randomize_layout tag). But if it's *not* in a > > UAPI header it should still be included in a stable form (i.e., without > > the randomize tag) in vmlinux.h, right? Which would be the point: > > consumers would be forced to read it from there and do CO-RE on it... > > So you're suggesting something like the following in the uapi header? > > #ifndef __KERNEL__ > #define __randomize_layout > #endif > 1. __randomize_layout in uapi header makes no sense. 2. It's supported by gcc plugin and afaik that plugin is broken vs debug info, so dwarf is broken, hence BTF is broken too, and CO-RE doesn't work on kernels compiled with that gcc plugin.
Alexei Starovoitov <alexei.starovoitov@gmail.com> writes: > On Tue, Nov 15, 2022 at 10:38 AM Stanislav Fomichev <sdf@google.com> wrote: >> >> On Tue, Nov 15, 2022 at 7:54 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote: >> > >> > Stanislav Fomichev <sdf@google.com> writes: >> > >> > > - drop __randomize_layout >> > > >> > > Not sure it's possible to sanely expose it via UAPI. Because every >> > > .o potentially gets its own randomized layout, test_progs >> > > refuses to link. >> > >> > So this won't work if the struct is in a kernel-supplied UAPI header >> > (which would include the __randomize_layout tag). But if it's *not* in a >> > UAPI header it should still be included in a stable form (i.e., without >> > the randomize tag) in vmlinux.h, right? Which would be the point: >> > consumers would be forced to read it from there and do CO-RE on it... >> >> So you're suggesting something like the following in the uapi header? >> >> #ifndef __KERNEL__ >> #define __randomize_layout >> #endif >> > > 1. > __randomize_layout in uapi header makes no sense. I agree, which is why I wanted it to be only in vmlinux.h... > 2. > It's supported by gcc plugin and afaik that plugin is broken > vs debug info, so dwarf is broken, hence BTF is broken too, > and CO-RE doesn't work on kernels compiled with that gcc plugin. ...however this one seems a deal breaker. Ah well, too bad, seemed like a neat trick to enforce CO-RE :( -Toke