All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Marco Elver <elver@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	 Kees Cook <keescook@chromium.org>,
	 Guenter Roeck <linux@roeck-us.net>,
	 Peter Zijlstra <peterz@infradead.org>,
	 Mark Rutland <mark.rutland@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	 Marc Zyngier <maz@kernel.org>,
	Oliver Upton <oliver.upton@linux.dev>,
	 James Morse <james.morse@arm.com>,
	 Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>,
	 Catalin Marinas <catalin.marinas@arm.com>,
	 Will Deacon <will@kernel.org>,
	 Nathan Chancellor <nathan@kernel.org>,
	 Nick Desaulniers <ndesaulniers@google.com>,
	 Tom Rix <trix@redhat.com>,  Miguel Ojeda <ojeda@kernel.org>,
	 linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	 linux-kernel@vger.kernel.org, llvm@lists.linux.dev,
	 Dmitry Vyukov <dvyukov@google.com>,
	 Alexander Potapenko <glider@google.com>,
	 kasan-dev@googlegroups.com, linux-toolchains@vger.kernel.org
Subject: Re: [PATCH v2 1/3] compiler_types: Introduce the Clang __preserve_most function attribute
Date: Mon, 07 Aug 2023 14:36:53 +0200	[thread overview]
Message-ID: <87pm3zf2qi.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <CANpmjNN4h2+i3LUG__GHha849PZ3jK=mBoFQWpSz4jffXB4wrw@mail.gmail.com> (Marco Elver's message of "Mon, 7 Aug 2023 14:24:26 +0200")

* 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?
Using the Clang-based BPF tools with a GCC-compiled kernel requires a
matching ABI.

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.

Thanks,
Florian


WARNING: multiple messages have this Message-ID (diff)
From: Florian Weimer <fweimer@redhat.com>
To: Marco Elver <elver@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	 Kees Cook <keescook@chromium.org>,
	 Guenter Roeck <linux@roeck-us.net>,
	 Peter Zijlstra <peterz@infradead.org>,
	 Mark Rutland <mark.rutland@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	 Marc Zyngier <maz@kernel.org>,
	Oliver Upton <oliver.upton@linux.dev>,
	 James Morse <james.morse@arm.com>,
	 Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>,
	 Catalin Marinas <catalin.marinas@arm.com>,
	 Will Deacon <will@kernel.org>,
	 Nathan Chancellor <nathan@kernel.org>,
	 Nick Desaulniers <ndesaulniers@google.com>,
	 Tom Rix <trix@redhat.com>,  Miguel Ojeda <ojeda@kernel.org>,
	 linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	 linux-kernel@vger.kernel.org, llvm@lists.linux.dev,
	 Dmitry Vyukov <dvyukov@google.com>,
	 Alexander Potapenko <glider@google.com>,
	 kasan-dev@googlegroups.com, linux-toolchains@vger.kernel.org
Subject: Re: [PATCH v2 1/3] compiler_types: Introduce the Clang __preserve_most function attribute
Date: Mon, 07 Aug 2023 14:36:53 +0200	[thread overview]
Message-ID: <87pm3zf2qi.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <CANpmjNN4h2+i3LUG__GHha849PZ3jK=mBoFQWpSz4jffXB4wrw@mail.gmail.com> (Marco Elver's message of "Mon, 7 Aug 2023 14:24:26 +0200")

* 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?
Using the Clang-based BPF tools with a GCC-compiled kernel requires a
matching ABI.

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.

Thanks,
Florian


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-08-07 12:37 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-04  9:02 [PATCH v2 1/3] compiler_types: Introduce the Clang __preserve_most function attribute Marco Elver
2023-08-04  9:02 ` Marco Elver
2023-08-04  9:02 ` [PATCH v2 2/3] list_debug: Introduce inline wrappers for debug checks Marco Elver
2023-08-04  9:02   ` Marco Elver
2023-08-04 16:03   ` Steven Rostedt
2023-08-04 16:03     ` Steven Rostedt
2023-08-04 17:49     ` Marco Elver
2023-08-04 17:49       ` Marco Elver
2023-08-04 17:57       ` Steven Rostedt
2023-08-04 17:57         ` Steven Rostedt
2023-08-04 17:59         ` Steven Rostedt
2023-08-04 17:59           ` Steven Rostedt
2023-08-04 18:08           ` Marco Elver
2023-08-04 18:08             ` Marco Elver
2023-08-04 18:19           ` Peter Zijlstra
2023-08-04 18:19             ` Peter Zijlstra
2023-08-05  6:30     ` Miguel Ojeda
2023-08-05  6:30       ` Miguel Ojeda
2023-08-04  9:02 ` [PATCH v2 3/3] list_debug: Introduce CONFIG_DEBUG_LIST_MINIMAL Marco Elver
2023-08-04  9:02   ` Marco Elver
2023-08-04 15:58 ` [PATCH v2 1/3] compiler_types: Introduce the Clang __preserve_most function attribute Steven Rostedt
2023-08-04 15:58   ` Steven Rostedt
2023-08-04 18:14 ` Peter Zijlstra
2023-08-04 18:14   ` Peter Zijlstra
2023-08-05  6:35 ` Miguel Ojeda
2023-08-05  6:35   ` Miguel Ojeda
2023-08-07 11:41 ` Florian Weimer
2023-08-07 11:41   ` Florian Weimer
2023-08-07 12:24   ` Marco Elver
2023-08-07 12:24     ` Marco Elver
2023-08-07 12:36     ` Florian Weimer [this message]
2023-08-07 12:36       ` Florian Weimer
2023-08-07 13:07       ` Marco Elver
2023-08-07 13:07         ` Marco Elver
2023-08-07 15:06       ` Peter Zijlstra
2023-08-07 15:06         ` Peter Zijlstra
2023-08-07 12:38     ` Jakub Jelinek
2023-08-07 12:38       ` Jakub Jelinek
2023-08-07 12:43       ` Florian Weimer
2023-08-07 12:43         ` Florian Weimer
2023-08-07 13:06         ` Jakub Jelinek
2023-08-07 13:06           ` Jakub Jelinek
2023-08-07 12:31   ` Peter Zijlstra
2023-08-07 12:31     ` Peter Zijlstra
2023-08-08  2:16     ` Steven Rostedt
2023-08-08  2:16       ` Steven Rostedt
2023-08-07 15:27   ` Nick Desaulniers
2023-08-07 15:27     ` Nick Desaulniers
2023-08-08 10:57   ` Peter Zijlstra
2023-08-08 10:57     ` Peter Zijlstra
2023-08-08 11:41     ` Florian Weimer
2023-08-08 11:41       ` Florian Weimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87pm3zf2qi.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=catalin.marinas@arm.com \
    --cc=dvyukov@google.com \
    --cc=elver@google.com \
    --cc=glider@google.com \
    --cc=james.morse@arm.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=keescook@chromium.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-toolchains@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=llvm@lists.linux.dev \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=ojeda@kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=suzuki.poulose@arm.com \
    --cc=trix@redhat.com \
    --cc=will@kernel.org \
    --cc=yuzenghui@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.