linux-kernel - Re: [PATCH] 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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <06a1242830ddb84c52cd77e548c71d40a0eb5e63.camel@linux.ibm.com>
Date:   Tue, 26 Apr 2022 14:10:58 -0400
From:   Mimi Zohar <zohar@...ux.ibm.com>
To:     Jonathan McDowell <noodles@...com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        Dmitry Kasatkin <dmitry.kasatkin@...il.com>,
        James Morris <jmorris@...ei.org>,
        "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] Carry forward IMA measurement log on kexec on x86_64

On Tue, 2022-04-26 at 16:48 +0000, Jonathan McDowell wrote:
> On Tue, Apr 26, 2022 at 09:49:53AM -0400, Mimi Zohar wrote:
> > On Tue, 2022-04-26 at 12:08 +0000, Jonathan McDowell wrote:
> > > On Mon, Apr 25, 2022 at 12:29:17PM -0400, Mimi Zohar wrote:
> > > > Hi Jonathan,
> > > > 
> > > > On Fri, 2022-04-22 at 13:50 +0000, Jonathan McDowell wrote:
> > > > > On kexec file load Integrity Measurement Architecture (IMA) subsystem
> > > > > may verify the IMA signature of the kernel and initramfs, and measure
> > > > > it. The command line parameters passed to the kernel in the kexec call
> > > > > may also be measured by IMA. A remote attestation service can verify
> > > > > a TPM quote based on the TPM event log, the IMA measurement list, and
> > > > > the TPM PCR data. This can be achieved only if the IMA measurement log
> > > > > is carried over from the current kernel to the next kernel across
> > > > > the kexec call.
> > > > > 
> > > > > powerpc and ARM64 both achieve this using device tree with a
> > > > > "linux,ima-kexec-buffer" node. x86 platforms generally don't make use of
> > > > > device tree, so the IMA infrastructure is extended to allow non device
> > > > > tree platforms to provide a log buffer. x86 then passes the IMA buffer
> > > > > to the new kernel via the setup_data mechanism.
> > > > > 
> > > > > Signed-off-by: Jonathan McDowell <noodles@...com>
> > > > 
> > > > FYI, after applying, building, and booting a kernel with this patch,
> > > > "kexec -s -l /boot/vmlinuz-5.18.0-rc4+ --reuse-cmdline --
> > > > initrd=/boot/initramfs-5.18.0-rc4+.img" properly loads the kernel, but
> > > > "kexec -s -e" fails to reboot, at least on a test laptop even with only
> > > > the "boot_aggregate" measurement record.
> > > > 
> > > > Without enabling CONFIG_IMA_KEXEC, kexec boots properly.
> > > 
> > > Thanks for giving it a try. At a guess your laptop is booting with
> > > EFI, whereas for my testing I was using qemu with legacy BIOS. I've
> > > managed to reproduce the issue with qemu+OVMF and isolated the mistake
> > > in the setup data calculation I made when EFI is involved. If you have
> > > time can you try with the below on top of the original patch?
> > 
> > Thank you!  With the change, as expected there are two "boot_aggregate"
> > records in the measurement list.  With a custom policy, the measurement
> > list verifies.
> 
> Excellent, thanks for verifying. I'll get the fixed v2 out.
> 
> ...
> > FYI, the builtin "ima_policy=tcb" results in measurement violations.  
> > Normally, the measurement list can still be verified using the evmctl
> > "--ignore-violations" option.   For some reason with the "tcb" policy, 
> > the measurement list doesn't verify even with the "--ignore-violations" 
> > option after kexec.  I assume this is a result of additional
> > measurements being added after the kexec load, which aren't being
> > carried across kexec.
> 
> I believe with "tcb" things like the subsequent exec of kexec to
> actually do the reboot will end up measured, and as the kexec buffer is
> static it won't include that.
> 
> Also there's an issue about the fact that we measure the kexec pieces
> even if we don't actually do the kexec; there's no marker that confirms
> the kexec took place. It's separate to this patch (in that it affects
> the device tree kexec infrastructure too) but it's conceivable that an
> attacker could measure in the new kernel details and not actually do the
> kexec, and that's not distinguishable from the kexec happening.
> 
> One approach might be to add a marker in the kexec ima buffer such that
> if it's not present we know the kexec hasn't happened, but I need to
> think through that a bit more.

I'm not quite sure what you mean by "we measure the kexec pieces".  The
kexec file load syscall calls kernel_read_file_from_fd() to read the
kernel image into a buffer.  The measurement record included in the IMA
measurement list a hash of the buffer data, which is exactly the same
as the hash of the kernel image.

The kernel kexec self tests only do the kexec load, not the execute. 
For each kexec execute you'll see an additional "boot_aggregate" record
in the IMA measurement list.  At least for the moment I don't see a
need for additional marker.

thanks,

Mimi