All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Petr Tesařík" <petr@tesarici.cz>
To: Mimi Zohar <zohar@linux.ibm.com>
Cc: Tushar Sugandhi <tusharsu@linux.microsoft.com>,
	roberto.sassu@huaweicloud.com, roberto.sassu@huawei.com,
	eric.snowberg@oracle.com, stefanb@linux.ibm.com,
	ebiederm@xmission.com, noodles@fb.com, bauermann@kolabnow.com,
	linux-integrity@vger.kernel.org, kexec@lists.infradead.org,
	code@tyhicks.com, nramas@linux.microsoft.com,
	paul@paul-moore.com
Subject: Re: [PATCH v5 6/8] ima: suspend measurements during buffer copy at kexec execute
Date: Thu, 29 Feb 2024 14:21:16 +0100	[thread overview]
Message-ID: <20240229142116.5f16061b@meshulam.tesarici.cz> (raw)
In-Reply-To: <20b13e7bab048b3afb94a8878299aa7d61016364.camel@linux.ibm.com>

On Thu, 22 Feb 2024 11:38:23 -0500
Mimi Zohar <zohar@linux.ibm.com> wrote:

> > > @@ -176,6 +195,19 @@ int ima_add_template_entry(struct ima_template_entry
> > > *entry, int violation,
> > >  		}
> > >  	}
> > >  
> > > +	/*
> > > +	 * suspend_ima_measurements will be set if the system is
> > > +	 * undergoing kexec soft boot to a new kernel.
> > > +	 * suspending measurements in this short window ensures the
> > > +	 * consistency of the IMA measurement list during copying
> > > +	 * of the kexec buffer.
> > > +	 */  
> > 
> > Either remove the 2nd sentence "suspending measurements in this short window
> > ..." or explain what is meant by "short window".
> > 
> >   
> > > +	if (atomic_read(&suspend_ima_measurements)) {
> > > +		audit_cause = "measurements_suspended";
> > > +		audit_info = 0;
> > > +		goto out;  
> 
> After the suggested changes, understanding how many measurements are not being
> added to the measurement list and not being extended into the TPM would be
> really interesting.

First, I'm sorry for chiming in when v5 is already around, but I have
just found this patch series now.

It indeed sounds conceptually wrong to suspend and resume measurements.
At some point during the handover, other CPUs are taken offline (look
for migrate_to_reboot_cpu() in kernel/kexec_core.c) and even the reboot
CPU will be sufficiently shut down as not to be able to add any more
measurements.

IMO it would make more sense to copy the measurement list at this late
stage, even if it means adding a new notifier list (or a new action).

It may be a bit challenging if you want to make 100% sure that a new
measurement cannot be made from hard interrupt context, but is that even
a supported scenario?

Just my two (euro)cents,
Petr T

WARNING: multiple messages have this Message-ID (diff)
From: "Petr Tesařík" <petr@tesarici.cz>
To: Mimi Zohar <zohar@linux.ibm.com>
Cc: Tushar Sugandhi <tusharsu@linux.microsoft.com>,
	roberto.sassu@huaweicloud.com, roberto.sassu@huawei.com,
	eric.snowberg@oracle.com, stefanb@linux.ibm.com,
	ebiederm@xmission.com, noodles@fb.com, bauermann@kolabnow.com,
	linux-integrity@vger.kernel.org, kexec@lists.infradead.org,
	code@tyhicks.com, nramas@linux.microsoft.com,
	paul@paul-moore.com
Subject: Re: [PATCH v5 6/8] ima: suspend measurements during buffer copy at kexec execute
Date: Thu, 29 Feb 2024 14:21:16 +0100	[thread overview]
Message-ID: <20240229142116.5f16061b@meshulam.tesarici.cz> (raw)
In-Reply-To: <20b13e7bab048b3afb94a8878299aa7d61016364.camel@linux.ibm.com>

On Thu, 22 Feb 2024 11:38:23 -0500
Mimi Zohar <zohar@linux.ibm.com> wrote:

> > > @@ -176,6 +195,19 @@ int ima_add_template_entry(struct ima_template_entry
> > > *entry, int violation,
> > >  		}
> > >  	}
> > >  
> > > +	/*
> > > +	 * suspend_ima_measurements will be set if the system is
> > > +	 * undergoing kexec soft boot to a new kernel.
> > > +	 * suspending measurements in this short window ensures the
> > > +	 * consistency of the IMA measurement list during copying
> > > +	 * of the kexec buffer.
> > > +	 */  
> > 
> > Either remove the 2nd sentence "suspending measurements in this short window
> > ..." or explain what is meant by "short window".
> > 
> >   
> > > +	if (atomic_read(&suspend_ima_measurements)) {
> > > +		audit_cause = "measurements_suspended";
> > > +		audit_info = 0;
> > > +		goto out;  
> 
> After the suggested changes, understanding how many measurements are not being
> added to the measurement list and not being extended into the TPM would be
> really interesting.

First, I'm sorry for chiming in when v5 is already around, but I have
just found this patch series now.

It indeed sounds conceptually wrong to suspend and resume measurements.
At some point during the handover, other CPUs are taken offline (look
for migrate_to_reboot_cpu() in kernel/kexec_core.c) and even the reboot
CPU will be sufficiently shut down as not to be able to add any more
measurements.

IMO it would make more sense to copy the measurement list at this late
stage, even if it means adding a new notifier list (or a new action).

It may be a bit challenging if you want to make 100% sure that a new
measurement cannot be made from hard interrupt context, but is that even
a supported scenario?

Just my two (euro)cents,
Petr T

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2024-02-29 13:21 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-14 15:38 [PATCH v5 0/8] ima: kexec: measure events between kexec load and execute Tushar Sugandhi
2024-02-14 15:38 ` Tushar Sugandhi
2024-02-14 15:38 ` [PATCH v5 1/8] ima: define and call ima_alloc_kexec_file_buf Tushar Sugandhi
2024-02-14 15:38   ` Tushar Sugandhi
2024-02-19 22:16   ` Stefan Berger
2024-02-19 22:16     ` Stefan Berger
2024-02-21  0:12   ` Mimi Zohar
2024-02-21  0:12     ` Mimi Zohar
2024-02-14 15:38 ` [PATCH v5 2/8] kexec: define functions to map and unmap segments Tushar Sugandhi
2024-02-14 15:38   ` Tushar Sugandhi
2024-02-14 19:43   ` Stefan Berger
2024-02-14 19:43     ` Stefan Berger
2024-02-15  6:13     ` Tushar Sugandhi
2024-02-15  6:13       ` Tushar Sugandhi
2024-02-21 20:22   ` Mimi Zohar
2024-02-21 20:22     ` Mimi Zohar
2024-02-14 15:38 ` [PATCH v5 3/8] ima: kexec: skip IMA segment validation after kexec soft reboot Tushar Sugandhi
2024-02-14 15:38   ` Tushar Sugandhi
2024-02-14 15:38 ` [PATCH v5 4/8] ima: kexec: define functions to copy IMA log at soft boot Tushar Sugandhi
2024-02-14 15:38   ` Tushar Sugandhi
2024-02-14 20:47   ` Stefan Berger
2024-02-14 20:47     ` Stefan Berger
2024-02-15  6:55     ` Tushar Sugandhi
2024-02-15  6:55       ` Tushar Sugandhi
2024-02-21 21:52       ` Mimi Zohar
2024-02-21 21:52         ` Mimi Zohar
2024-02-21 22:39   ` Mimi Zohar
2024-02-21 22:39     ` Mimi Zohar
2024-03-01 11:12   ` Petr Tesařík
2024-03-01 11:12     ` Petr Tesařík
2024-02-14 15:38 ` [PATCH v5 5/8] ima: kexec: move IMA log copy from kexec load to execute Tushar Sugandhi
2024-02-14 15:38   ` Tushar Sugandhi
2024-02-14 20:58   ` Stefan Berger
2024-02-14 20:58     ` Stefan Berger
2024-02-22  1:47   ` Mimi Zohar
2024-02-22  1:47     ` Mimi Zohar
2024-05-09  6:32   ` Petr Tesařík
2024-05-09  6:32     ` Petr Tesařík
2024-02-14 15:38 ` [PATCH v5 6/8] ima: suspend measurements during buffer copy at kexec execute Tushar Sugandhi
2024-02-14 15:38   ` Tushar Sugandhi
2024-02-22 14:14   ` Mimi Zohar
2024-02-22 14:14     ` Mimi Zohar
2024-02-22 16:38     ` Mimi Zohar
2024-02-22 16:38       ` Mimi Zohar
2024-02-29 13:21       ` Petr Tesařík [this message]
2024-02-29 13:21         ` Petr Tesařík
2024-02-14 15:38 ` [PATCH v5 7/8] ima: make the kexec extra memory configurable Tushar Sugandhi
2024-02-14 15:38   ` Tushar Sugandhi
2024-02-22 14:13   ` Mimi Zohar
2024-02-22 14:13     ` Mimi Zohar
2024-02-14 15:38 ` [PATCH v5 8/8] ima: measure kexec load and exec events as critical data Tushar Sugandhi
2024-02-14 15:38   ` Tushar Sugandhi
2024-02-14 21:00   ` Stefan Berger
2024-02-14 21:00     ` Stefan Berger
2024-02-15  6:57     ` Tushar Sugandhi
2024-02-15  6:57       ` Tushar Sugandhi
2024-02-14 21:03   ` Stefan Berger
2024-02-14 21:03     ` Stefan Berger
2024-02-15  6:58     ` Tushar Sugandhi
2024-02-15  6:58       ` Tushar Sugandhi
2024-02-21  0:15 ` [PATCH v5 0/8] ima: kexec: measure events between kexec load and execute Mimi Zohar
2024-02-21  0:15   ` Mimi Zohar

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=20240229142116.5f16061b@meshulam.tesarici.cz \
    --to=petr@tesarici.cz \
    --cc=bauermann@kolabnow.com \
    --cc=code@tyhicks.com \
    --cc=ebiederm@xmission.com \
    --cc=eric.snowberg@oracle.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=noodles@fb.com \
    --cc=nramas@linux.microsoft.com \
    --cc=paul@paul-moore.com \
    --cc=roberto.sassu@huawei.com \
    --cc=roberto.sassu@huaweicloud.com \
    --cc=stefanb@linux.ibm.com \
    --cc=tusharsu@linux.microsoft.com \
    --cc=zohar@linux.ibm.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.