linux-kernel - Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230712120002.GIZK6Vwga6DlJqdjEh@fat_crate.local>
Date:   Wed, 12 Jul 2023 14:00:02 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Emanuele Giuseppe Esposito <eesposit@...hat.com>
Cc:     "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
        Thomas Gleixner <tglx@...utronix.de>, bluca@...ian.org,
        lennart@...ttering.net, Ingo Molnar <mingo@...hat.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Alexander Potapenko <glider@...gle.com>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Daniel P . Berrangé <berrange@...hat.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

On Wed, Jul 12, 2023 at 08:19:32AM +0200, Emanuele Giuseppe Esposito wrote:
> And any comment on the SBAT string itself? I would like to get an
> agreement on
> "linux,1,The Linux Developers,linux,$(KERNELVERSION),https://linux.org"
> before we use it as semplate also for downstream.

Yeah, looks useless to me. With your patch I get:

$ cat linux.sbat
sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
linux,1,The Linux Developers,linux,6.5.0-rc1,https://linux.org

But my branch is:

$ git describe
v6.5-rc1-6-g3f01e9fed845

So your thing needs to enable CONFIG_LOCALVERSION_AUTO or so which
allows for uniquely identifying the build. At least I think it did at
some point. So that you can do stuff like:

$ file vmlinux
vmlinux: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=19f22ac85675ea30042fb703373d97c460bb5a61, with debug_info, not stripped

and you have a build ID sha there.

But not even that works because if I change the source, I still get the
same sha. So it needs to be an mechanism which identifies the kernel
image uniquely.

And then why does it have to be a separate section? All those
requirements need to be written down.

And regardless what you do, this looks like a contract between the
kernel and userspace tools so it absolutely needs to be documented
somewhere prominently - not in a commit message with links to flaky URLs
which would probably change in the future - and explained what the tools
parse and where one can find that parsing code.

Because if we go and change that, we need to be able to verify whether
we're not breaking any userspace tools.

Actually, I wouldn't mind even having a small script which does the
parsing and which we can use to check that we're not breaking things.

Also, while building this says:

objcopy --set-section-alignment '.sbat=512' --add-section .sbat=linux.sbat arch/x86/boot/bzImage;
objcopy: arch/x86/boot/st2fStm6:.sbat: section below image base

So you need to make it quiet.

And so on and so on...

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette