lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20221101154441.976294-1-alexandr.lobakin@intel.com>
Date:   Tue,  1 Nov 2022 16:44:41 +0100
From:   Alexander Lobakin <alexandr.lobakin@...el.com>
To:     "H. Peter Anvin" <hpa@...or.com>
Cc:     Alexander Lobakin <alexandr.lobakin@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Tony Luck <tony.luck@...el.com>,
        Kees Cook <keescook@...omium.org>,
        Masahiro Yamada <masahiroy@...nel.org>, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] x86/boot: robustify calling startup_{32,64}() from the decompressor code

From: "H. Peter Anvin" <hpa@...or.com>
Date: Mon, 31 Oct 2022 13:31:05 -0700

> On October 31, 2022 8:10:46 AM PDT, Alexander Lobakin <alexandr.lobakin@...el.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ