linux-kernel - Re: [PATCH v2] Carry forward IMA measurement log on kexec on x86

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: <YnlgTCyB2ciaD1so@noodles-fedora.dhcp.thefacebook.com>
Date:   Mon, 9 May 2022 18:41:17 +0000
From:   Jonathan McDowell <noodles@...com>
To:     Borislav Petkov <bp@...en8.de>
CC:     Thomas Gleixner <tglx@...utronix.de>,
        James Morris <jmorris@...ei.org>,
        Ingo Molnar <mingo@...hat.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Dmitry Kasatkin <dmitry.kasatkin@...il.com>,
        "x86@...nel.org" <x86@...nel.org>,
        Mimi Zohar <zohar@...ux.ibm.com>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
        "linux-security-module@...r.kernel.org" 
        <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH v2] Carry forward IMA measurement log on kexec on x86_64

On Mon, May 09, 2022 at 08:09:55PM +0200, Borislav Petkov wrote:
> On Mon, May 09, 2022 at 05:46:22PM +0000, Jonathan McDowell wrote:
> > Device tree on x86 doesn't seem to be a thing;
> 
> Not a thing? What does that even mean?

Let me rephrase more verbosely. Device tree on x86 seems to be a rarely
enabled config option that is only required on a couple of platforms and
lacks the same level of integration with the x86 boot process (compared
to PowerPC and ARM64) such that a) there's a lot more code that would
need to be written to even get to the point that it could be used in the
same manner for passing the IMA buffer as on other platforms and b) I'm
not sure whether or not it might introduce other issues due to this lack
of use/testing.

> We have arch/x86/kernel/devicetree.c which adds some minimal devicetree
> support.
> 
> > none of the distros I regularly use enable CONFIG_OF for x86, I can
> > only find 2 32-bit x86 platforms that actually select it and none of
> > the plumbing for kexec on x86 ties in device tree.
> 
> And? That can get changed and enabled and so on.
> 
> > I agree for platforms that make active use of device tree that's the
> > appropriate path, but it doesn't seem to be the case for x86.
> 
> I'm not sure what you're aim here is?
> 
> You want to pass that IMA measurement to the kexec kernel with minimal
> changes, i.e., change only the kernel?

I'd like to be able to take an internal kernel buffer and pass it to the
newly kexeced kernel, yes. I'd like that to be possible with the
kexec_file_load() path, which allows for things like kernel signing,
which I believe precludes providing the data from user space.

> Why can't distros be also changed to use devicetree for the IMA
> measurement, like the other arches do? Why does x86 need to do it
> differently?

> We also pass info to the kexec kernel by reading it from sysfs
> and having kexec tools pass it to the kexec-ed kernel, see
> Documentation/ABI/testing/sysfs-firmware-efi-runtime-map

AFAICT kexec passes EFI details using SETUP_EFI, which is what I
modelled the SETUP_IMA support on
(1fec0533693cd74f2d1a46edd29449cfee429df0). In the old syscall variant
the kexec tools do read /sys/firmware/efi/runtime-map and create a
setup_data entry of type SETUP_EFI, in the new file based kexec that is
done inside the kernel in a similar fashion to what I've done with
SETUP_IMA.

> So is there any particular reason/pressing need to pass the measurement
> with setup_data?

I'm not tied to setup_data but given the concerns I raise above with
device tree on x86 and the need to handle this in the kernel it seemed
like a reasonable first approach. You seem to be saying it's not and
either adding the device tree infrastructure or doing a command line
hack would be preferable?

J.