From: Ard Biesheuvel <ardb@kernel.org>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Borislav Petkov <bp@alien8.de>,
Arthur Eubanks <aeubanks@google.com>,
Nathan Chancellor <nathan@kernel.org>,
tglx@linutronix.de, mingo@redhat.com,
dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
morbo@google.com, justinstitt@google.com, song@kernel.org,
ribalda@chromium.org, linux-kernel@vger.kernel.org,
llvm@lists.linux.dev, patches@lists.linux.dev,
ns <0n-s@users.noreply.github.com>,
Fangrui Song <maskray@google.com>
Subject: Re: [PATCH 0/2] x86/purgatory: Avoid kexec runtime warning with LLVM 18
Date: Thu, 18 Apr 2024 19:52:03 +0200 [thread overview]
Message-ID: <CAMj1kXE_1STgZot48Fb_AKb1omMqDFg=65LcFjNAW+6vrLfpBQ@mail.gmail.com> (raw)
In-Reply-To: <CAMj1kXH+rNU4pa0ywcgkohXBu4G+iCXML_s9WVJW03ZRwtwW-w@mail.gmail.com>
On Thu, 18 Apr 2024 at 17:59, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Thu, 18 Apr 2024 at 17:44, Nick Desaulniers <ndesaulniers@google.com> wrote:
> >
> > On Thu, Apr 18, 2024 at 4:15 AM Borislav Petkov <bp@alien8.de> wrote:
> > > How much of this silliness should we expect now for other parts of the kernel?
> >
> > Looks like ARCH=powerpc sets -mcmodel=large for modules and ARCH=um
> > does for the whole kernel. So that LLVM change may have implications
> > for those 2 other architectures. Not sure we've had any bug reports
> > or breakage in CI yet, like we have for x86+kexec.
> >
> > > Can we turn this off?
> >
> > Maybe we need to revisit
> > commit e16c2983fba0 ("x86/purgatory: Change compiler flags from
> > -mcmodel=kernel to -mcmodel=large to fix kexec relocation errors")
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e16c2983fba0fa6763e43ad10916be35e3d8dc05
> >
> > at least the -mcmodel=kernel addition (since that patch added a few
> > additional compiler flags that still LGTM).
> >
> ...
>
> > + Fangrui, Ard, who might know of alternative solutions to
> > -mcmodel=large for e16c2983fba0.
> >
>
> I think it would be better to use -mcmodel=small -fpic. As Nick
> explains, the large code model is really more suitable for executables
> that span a large memory range. The issue with the purgatory seems to
> be that it can be placed anywhere in memory, not that it is very big.
>
> -mcmodel=small -fpic is what user space typically uses, so it is much
> less likely to create problems.
>
> Note that I have been looking into whether we can build the entire
> kernel with -fpic (for various reasons). There are some issues to
> resolve there, mostly related to per-CPU variables and the per-CPU
> stack protector, but beyond that, things work happily and the number
> of boot time relocations drops dramatically, due to the use of
> RIP-relative references. So for the purgatory, I wouldn't expect too
> many surprises.
>
Replacing -mcmodel=large in PURGATORY_CFLAGS with
--mcmodel=small -fpic -fvisibility=hidden
seems to do the trick for me.
prev parent reply other threads:[~2024-04-18 17:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-17 21:53 [PATCH 0/2] x86/purgatory: Avoid kexec runtime warning with LLVM 18 Nathan Chancellor
2024-04-17 21:53 ` [PATCH 1/2] x86/purgatory: Add a linker script Nathan Chancellor
2024-04-17 21:53 ` [PATCH 2/2] x86/purgatory: Enable orphan section warnings Nathan Chancellor
2024-04-18 11:14 ` [PATCH 0/2] x86/purgatory: Avoid kexec runtime warning with LLVM 18 Borislav Petkov
2024-04-18 15:15 ` Nathan Chancellor
2024-04-18 15:44 ` Nick Desaulniers
2024-04-18 15:59 ` Ard Biesheuvel
2024-04-18 17:52 ` Ard Biesheuvel [this message]
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='CAMj1kXE_1STgZot48Fb_AKb1omMqDFg=65LcFjNAW+6vrLfpBQ@mail.gmail.com' \
--to=ardb@kernel.org \
--cc=0n-s@users.noreply.github.com \
--cc=aeubanks@google.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=justinstitt@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=maskray@google.com \
--cc=mingo@redhat.com \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=patches@lists.linux.dev \
--cc=ribalda@chromium.org \
--cc=song@kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).