All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan McDowell <noodles@fb.com>
To: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Mimi Zohar <zohar@linux.ibm.com>,
	Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
	James Morris <jmorris@namei.org>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-integrity@vger.kernel.org"
	<linux-integrity@vger.kernel.org>,
	"linux-security-module@vger.kernel.org" 
	<linux-security-module@vger.kernel.org>
Subject: Re: [PATCH v4] x86/kexec: Carry forward IMA measurement log on kexec
Date: Wed, 18 May 2022 10:42:03 +0000	[thread overview]
Message-ID: <YoTM3jU6PcfEsNkL@noodles-fedora.dhcp.thefacebook.com> (raw)
In-Reply-To: <08651a15-14d8-236e-7e13-a22d50f17f4e@linux.microsoft.com>

On Tue, May 17, 2022 at 10:19:45AM -0700, Lakshmi Ramasubramanian wrote:
> 
> > > > diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
> > > > index 170d0fd68b1f..54bd4ce5f908 100644
> > > > --- a/arch/x86/kernel/kexec-bzimage64.c
> > > > +++ b/arch/x86/kernel/kexec-bzimage64.c
> > > > @@ -186,6 +186,33 @@ setup_efi_state(struct boot_params *params, unsigned long params_load_addr,
> > > >    }
> > > >    #endif /* CONFIG_EFI */
> > > > +static void
> > > > +setup_ima_state(const struct kimage *image, struct boot_params *params,
> > > > +		unsigned long params_load_addr,
> > > > +		unsigned int ima_setup_data_offset)
> > > > +{
> > > > +#ifdef CONFIG_IMA_KEXEC
> > > > +	struct setup_data *sd = (void *)params + ima_setup_data_offset;
> > > > +	unsigned long setup_data_phys;
> > > > +	struct ima_setup_data *ima;
> > > > +
> > > > +	if (!image->ima_buffer_size)
> > > > +		return;
> > > > +
> > > > +	sd->type = SETUP_IMA;
> > > > +	sd->len = sizeof(*ima);
> > > > +
> > > > +	ima = (void *)sd + sizeof(struct setup_data);
> > > > +	ima->addr = image->ima_buffer_addr;
> > > > +	ima->size = image->ima_buffer_size;
> > > > +
> > > > +	/* Add setup data */
> > > > +	setup_data_phys = params_load_addr + ima_setup_data_offset;
> > > > +	sd->next = params->hdr.setup_data;
> > > > +	params->hdr.setup_data = setup_data_phys;
> > > > +#endif /* CONFIG_IMA_KEXEC */
> > > > +}
> > > > +
> > > >    static int
> > > >    setup_boot_parameters(struct kimage *image, struct boot_params *params,
> > > >    		      unsigned long params_load_addr,
> > > > @@ -247,6 +274,13 @@ setup_boot_parameters(struct kimage *image, struct boot_params *params,
> > > >    	setup_efi_state(params, params_load_addr, efi_map_offset, efi_map_sz,
> > > >    			efi_setup_data_offset);
> > > >    #endif
> > > > +
> > > > +	/* Setup IMA log buffer state */
> > > > +	setup_ima_state(image, params, params_load_addr,
> > > > +			efi_setup_data_offset +
> > > > +			sizeof(struct setup_data) +
> > > > +			sizeof(struct efi_setup_data));
> > > Here you could check image->ima_buffer_size and call setup_ima_state() only
> > > if it is non-zero.
> > 
> > setup_ima_state() has this check already.
> 
> Yes - I noticed that.
> I was just suggesting a minor optimization - avoid making this function call
> if IMA buffer is not present.
> 
> > 
> > > > +
> > > >    	/* Setup EDD info */
> > > >    	memcpy(params->eddbuf, boot_params.eddbuf,
> > > >    				EDDMAXNR * sizeof(struct edd_info));
> > > > @@ -403,6 +437,10 @@ static void *bzImage64_load(struct kimage *image, char *kernel,
> > > >    				sizeof(struct setup_data) +
> > > >    				sizeof(struct efi_setup_data);
> > > > +	if (IS_ENABLED(CONFIG_IMA_KEXEC))
> > > > +		kbuf.bufsz += sizeof(struct setup_data) +
> > > > +			      sizeof(struct ima_setup_data);
> > > > +
> > > >    	params = kzalloc(kbuf.bufsz, GFP_KERNEL);
> > > >    	if (!params)
> > > >    		return ERR_PTR(-ENOMEM);
> > > > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> > > > index 249981bf3d8a..ab5e7a351845 100644
> > > > --- a/arch/x86/kernel/setup.c
> > > > +++ b/arch/x86/kernel/setup.c
> > > > @@ -11,6 +11,7 @@
> > > >    #include <linux/dma-map-ops.h>
> > > >    #include <linux/dmi.h>
> > > >    #include <linux/efi.h>
> > > > +#include <linux/ima.h>
> > > >    #include <linux/init_ohci1394_dma.h>
> > > >    #include <linux/initrd.h>
> > > >    #include <linux/iscsi_ibft.h>
> > > > @@ -145,6 +146,11 @@ __visible unsigned long mmu_cr4_features __ro_after_init;
> > > >    __visible unsigned long mmu_cr4_features __ro_after_init = X86_CR4_PAE;
> > > >    #endif
> > > > +#ifdef CONFIG_IMA
> > > > +static phys_addr_t ima_kexec_buffer_phys;
> > > > +static size_t ima_kexec_buffer_size;
> > > > +#endif
> > > > +
> > > >    /* Boot loader ID and version as integers, for the benefit of proc_dointvec */
> > > >    int bootloader_type, bootloader_version;
> > > > @@ -335,6 +341,59 @@ static void __init reserve_initrd(void)
> > > >    }
> > > >    #endif /* CONFIG_BLK_DEV_INITRD */
> > > > +static void __init add_early_ima_buffer(u64 phys_addr)
> > > > +{
> > > > +#ifdef CONFIG_IMA
> > > > +	struct ima_setup_data *data;
> > > > +
> > > > +	data = early_memremap(phys_addr + sizeof(struct setup_data),
> > > > +			      sizeof(*data));
> > > > +	if (!data) {
> > > > +		pr_warn("setup: failed to memremap ima_setup_data entry\n");
> > > > +		return;
> > > > +	}
> > > Here if memory allocation fails, would kexec system call fail or would it
> > > only not add IMA buffer, but continue with the system call?
> > 
> > This is run in the context of the *new* kernel. Boot will continue, but
> > the IMA buffer will not be successfully passed across. Effectively that
> > puts us in the same situation as now; things like TPM PCRs will have
> > been updated, but we won't have the log showing us how we got to the
> > current state.
> I think it is better to treat this error as a critical failure.

That's going to crash the entire system, because it's after we've
started execution of the new kernel. Given that the failure mode will
result in the lack of the logs, but not incorrect TPM PCRs, that seems a
bit extreme.

J.

  reply	other threads:[~2022-05-18 10:42 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-22 13:50 [PATCH] Carry forward IMA measurement log on kexec on x86_64 Jonathan McDowell
2022-04-25 16:29 ` Mimi Zohar
2022-04-26 12:08   ` Jonathan McDowell
2022-04-26 13:49     ` Mimi Zohar
2022-04-26 16:48       ` Jonathan McDowell
2022-04-26 18:10         ` Mimi Zohar
2022-04-28 10:40           ` Jonathan McDowell
2022-04-28 12:25             ` Mimi Zohar
2022-04-26 16:52 ` [PATCH v2] " Jonathan McDowell
2022-04-29 21:30   ` Mimi Zohar
2022-05-03 12:02     ` Jonathan McDowell
2022-05-04 13:49       ` Mimi Zohar
2022-05-09 10:40   ` Jonathan McDowell
2022-05-09 11:25     ` Boris Petkov
2022-05-09 17:46       ` Jonathan McDowell
2022-05-09 18:09         ` Borislav Petkov
2022-05-09 18:41           ` Jonathan McDowell
2022-05-09 19:40             ` Borislav Petkov
2022-05-10  8:02               ` Jonathan McDowell
2022-05-10 10:46   ` Borislav Petkov
2022-05-11  9:59   ` [PATCH v3] x86/kexec: Carry forward IMA measurement log on kexec Jonathan McDowell
2022-05-11 17:53     ` Mimi Zohar
2022-05-11 17:56       ` Borislav Petkov
2022-05-11 19:12         ` Mimi Zohar
2022-05-12  1:34       ` Mimi Zohar
2022-05-12 16:25     ` [PATCH v4] " Jonathan McDowell
2022-05-13 17:19       ` Lakshmi Ramasubramanian
2022-05-16 15:15         ` Jonathan McDowell
2022-05-17 17:19           ` Lakshmi Ramasubramanian
2022-05-18 10:42             ` Jonathan McDowell [this message]
2022-05-18 14:43       ` Mimi Zohar
2022-05-30  8:40         ` Jonathan McDowell
2022-06-03 15:55           ` Dave Hansen
2022-06-03 15:55             ` Dave Hansen
2022-06-06  3:54             ` Baoquan He
2022-06-06  3:54               ` Baoquan He
2022-06-06  4:06       ` Baoquan He
2022-06-10  9:52         ` Jonathan McDowell
2022-06-10  9:52           ` Jonathan McDowell
2022-06-13 10:30       ` [PATCH v5] " Jonathan McDowell
2022-06-13 10:30         ` Jonathan McDowell
2022-06-13 21:01         ` Mimi Zohar
2022-06-13 21:01           ` Mimi Zohar
2022-06-16  2:59           ` Baoquan He
2022-06-16  2:59             ` Baoquan He
2022-06-16 15:30         ` [PATCH v6] " Jonathan McDowell
2022-06-16 15:30           ` Jonathan McDowell
2022-06-30  8:36           ` [PATCH v7] " Jonathan McDowell
2022-06-30  8:36             ` Jonathan McDowell
2022-06-30 11:54             ` Mimi Zohar
2022-06-30 11:54               ` Mimi Zohar
2022-07-04  2:36             ` Baoquan He
2022-07-04  2:36               ` Baoquan He
2022-06-27 11:56 ` [tip: x86/kdump] " tip-bot2 for Jonathan McDowell
2022-07-01 14:37 ` tip-bot2 for Jonathan McDowell
2022-07-07 16:52 ` [tip: x86/boot] " tip-bot2 for Jonathan McDowell
2022-07-07 17:37   ` Jonathan McDowell
2022-07-07 17:50     ` Dave Hansen

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=YoTM3jU6PcfEsNkL@noodles-fedora.dhcp.thefacebook.com \
    --to=noodles@fb.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=hpa@zytor.com \
    --cc=jmorris@namei.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=nramas@linux.microsoft.com \
    --cc=serge@hallyn.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=zohar@linux.ibm.com \
    --subject='Re: [PATCH v4] x86/kexec: Carry forward IMA measurement log on kexec' \
    /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

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.