From: Alexander Lobakin <alexandr.lobakin@intel.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Alexander Lobakin <alexandr.lobakin@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"Peter Zijlstra (Intel)" <peterz@infradead.org>,
Tony Luck <tony.luck@intel.com>,
Kees Cook <keescook@chromium.org>,
Masahiro Yamada <masahiroy@kernel.org>,
x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] x86/boot: robustify calling startup_{32,64}() from the decompressor code
Date: Tue, 1 Nov 2022 16:44:41 +0100 [thread overview]
Message-ID: <20221101154441.976294-1-alexandr.lobakin@intel.com> (raw)
In-Reply-To: <454A126A-1E27-4A5C-9073-4E72D3D23B5A@zytor.com>
From: "H. Peter Anvin" <hpa@zytor.com>
Date: Mon, 31 Oct 2022 13:31:05 -0700
> On October 31, 2022 8:10:46 AM PDT, Alexander Lobakin <alexandr.lobakin@intel.com> wrote:
> >After commit ce697ccee1a8 ("kbuild: remove head-y syntax"), I
> >started digging whether x86 is ready from removing this old cruft.
> >Removing its objects from the list makes the kernel unbootable.
> >This applies only to bzImage, vmlinux still works correctly.
> >The reason is that with no strict object order determined by the
> >linker arguments, not the linker script, startup_64 can be placed
> >not right at the beginning of the kernel.
> >Here's vmlinux.map's beginning before removing:
[...]
> >- return output;
> >+ return output + off;
> > }
> >
> > void fortify_panic(const char *name)
>
> Put the entry points in dedicated sections and declare them explicitly in the linker script (the standard name for this section would be .init, but we presumably want .init.32 and .init.64 to keep 32- and 64-bit code in separate sections.)
Uhm, I'm not sure I follow. We're trying to eliminate as much
hardcode as possible, and now you propose to introduce new :P
Some architectures don't have a separate .head.text at all: startup
functions are placed in .init.text, preboot code finds the entry
point and it just works. It's not possible currently on x86_64, but
we'll be there one day.
Thanks,
Olek
next prev parent reply other threads:[~2022-11-01 15:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-31 15:10 [PATCH 0/2] x86/boot: fix relying on link order Alexander Lobakin
2022-10-31 15:10 ` [PATCH 1/2] x86/boot: robustify calling startup_{32,64}() from the decompressor code Alexander Lobakin
2022-10-31 20:31 ` H. Peter Anvin
2022-11-01 15:44 ` Alexander Lobakin [this message]
2022-11-01 6:47 ` Jiri Slaby
2022-11-01 6:50 ` Jiri Slaby
2022-11-01 15:38 ` Alexander Lobakin
2022-10-31 15:10 ` [PATCH 2/2] scripts/head-object-list: remove x86 from the list Alexander Lobakin
2022-11-01 6:39 ` Jiri Slaby
2022-10-31 15:20 ` [PATCH 0/2] x86/boot: fix relying on link order Borislav Petkov
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=20221101154441.976294-1-alexandr.lobakin@intel.com \
--to=alexandr.lobakin@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--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 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.