Messages in this thread | ![/](/images/icornerl.gif) | | From | Marco Elver <> | Date | Mon, 7 Aug 2023 15:07:20 +0200 | Subject | Re: [PATCH v2 1/3] compiler_types: Introduce the Clang __preserve_most function attribute |
| |
On Mon, 7 Aug 2023 at 14:37, Florian Weimer <fweimer@redhat.com> wrote: > > * Marco Elver: > > > Good idea. I had already created > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110899, and we need > > better spec to proceed for GCC anyway. > > Thanks for the reference. > > >> Doesn't this change impact the kernel module ABI? > >> > >> I would really expect a check here > >> > >> > +#if __has_attribute(__preserve_most__) > >> > +# define __preserve_most notrace __attribute__((__preserve_most__)) > >> > +#else > >> > +# define __preserve_most > >> > +#endif > >> > >> that this is not a compilation for a module. Otherwise modules built > >> with a compiler with __preserve_most__ attribute support are > >> incompatible with kernels built with a compiler without that attribute. > > > > That's true, but is it a real problem? Isn't it known that trying to > > make kernel modules built for a kernel with a different config (incl. > > compiler) is not guaranteed to work? See IBT, CFI schemes, kernel > > sanitizers, etc? > > > > If we were to start trying to introduce some kind of minimal kernel to > > module ABI so that modules and kernels built with different toolchains > > keep working together, we'd need a mechanism to guarantee this minimal > > ABI or prohibit incompatible modules and kernels somehow. Is there a > > precedence for this somewhere? > > I think the GCC vs Clang thing is expected to work today, isn't it?
I, personally, wouldn't bet on it. It very much depends on the kernel config used.
> Using the Clang-based BPF tools with a GCC-compiled kernel requires a > matching ABI.
BPF is a different story altogether, and falls more into the category of user space to kernel ABI, which the kernel has strong guarantees on.
> The other things you listed result in fairly obvious breakage, sometimes > even module loading failures. Unconditional crashes are possible as > well. With __preserve_most__, the issues are much more subtle and may > only appear for some kernel/module compielr combinations and > optimization settings. The impact of incorrectly clobbered registers > tends to be like that.
One way around this would be to make the availability of the attribute a Kconfig variable. Then externally compiled kernel modules should do the right thing, since they ought to use the right .config when being built.
I can make that change for v3.
| ![\](/images/icornerr.gif) |