> > @@ -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
Hi Tushar,
On Wed, 2024-02-14 at 07:38 -0800, Tushar Sugandhi wrote:
> New measurements added to the IMA log while the log is being copied
> during the kexec 'execute' may not get copied over.
As long as there is enough memory for the additional records, isn't the problem
"after" copying the
Hi Tushar,
On Wed, 2024-02-14 at 07:38 -0800, Tushar Sugandhi wrote:
> The extra memory allocated for carrying the IMA measurement list across
> kexec is hard-coded as half a PAGE. Make it configurable.
>
> Define a Kconfig option, IMA_KEXEC_EXTRA_MEMORY_KB, to configure the
> extra memory (in
> @@ -195,7 +181,34 @@ void ima_add_kexec_buffer(struct kimage *image)
> static int ima_update_kexec_buffer(struct notifier_block *self,
> unsigned long action, void *data)
> {
> - return NOTIFY_OK;
> + void *buf = NULL;
> + size_t buf_size;
> +
Additional comments ...
> diff --git a/security/integrity/ima/ima_kexec.c
> b/security/integrity/ima/ima_kexec.c
> index ccb072617c2d..1d4d6c122d82 100644
> --- a/security/integrity/ima/ima_kexec.c
> +++ b/security/integrity/ima/ima_kexec.c
> @@ -12,10 +12,14 @@
> #include
> #include
>
On Wed, 2024-02-14 at 22:55 -0800, Tushar Sugandhi wrote:
>
> On 2/14/24 12:47, Stefan Berger wrote:
> >
> > On 2/14/24 10:38, Tushar Sugandhi wrote:
> ...
>
> ...
> > > +void kimage_file_post_load(struct kimage *image)
> > > +{
> > > +ima_kexec_post_load(image);
> > > +}
> > > +
> >
> >
On Wed, 2024-02-14 at 07:38 -0800, Tushar Sugandhi wrote:
> Currently, the mechanism to map and unmap segments to the kimage
> structure is not available to the subsystems outside of kexec. This
> functionality is needed when IMA is allocating the memory segments
> during kexec 'load' operation.
On Wed, 2024-02-14 at 07:38 -0800, Tushar Sugandhi wrote:
> The current Kernel behavior is IMA measurements snapshot is taken at
> kexec 'load' and not at kexec 'execute'. IMA log is then carried
> over to the new Kernel after kexec 'execute'.
'Kernel' should not be capitalized since it isn't a
On Wed, 2024-02-14 at 07:38 -0800, Tushar Sugandhi wrote:
> Carrying the IMA measurement list across kexec requires allocating a
> buffer and copying the measurement records. Separate allocating the
> buffer and copying the measurement records into separate functions in
> order to allocate the
On Mon, 2024-01-22 at 10:38 -0800, Tushar Sugandhi wrote:
> ima_dump_measurement_list() is called during kexec 'load', which may
> result in loss of IMA measurements during kexec soft reboot. It needs
> to be called during kexec 'execute'.
>
> The below changes need to be part of the same patch
On Mon, 2024-01-22 at 10:38 -0800, Tushar Sugandhi wrote:
The problem statement could be written as:
The amount of memory allocated at kexec load, even with the extra memory
allocated, might not be large enough for the entire measurement list. The
indeterminate interval between kexec 'load' and
> --- a/security/integrity/ima/ima_kexec.c
> +++ b/security/integrity/ima/ima_kexec.c
> @@ -121,6 +121,7 @@ void ima_add_kexec_buffer(struct kimage *image)
> .buf_min = 0, .buf_max = ULONG_MAX,
> .top_down = true };
> unsigned
Hi Tushar,
On Mon, 2024-01-22 at 10:37 -0800, Tushar Sugandhi wrote:
Missing from this and the other patch descriptions is the problem
description. Please refer to the section titled "Describe your changes" in
https://docs.kernel.org/process/submitting-patches.html.
"Describe your problem.
On Thu, 2024-01-11 at 12:52 -0800, Tushar Sugandhi wrote:
[...]
> If we go with the KBs approach -
>
> half-a-page translates to different KBs on different architectures.
> And setting the right default value in KBs which would translate to
> the desired half-a-page, on a given arch, inside the
Hi Tushar,
> > This patch moves the ima_dump_measurement_list() call from kexec load
> > to exec, but doesn't register the reboot notifier in this patch. I
> > don't see how it is possible with just the previous and this patch
> > applied that the measurement list is carried across kexec.
> Ah.
On Fri, 2024-01-05 at 11:50 -0800, Tushar Sugandhi wrote:
>
> On 12/20/23 12:44, Mimi Zohar wrote:
> > On Fri, 2023-12-15 at 17:07 -0800, Tushar Sugandhi wrote:
> >> If the new measurements are added to the IMA log while it is being
> >> being copied to the kexe
On Sun, 2024-01-07 at 21:58 -0500, Paul Moore wrote:
> On Sun, Jan 7, 2024 at 7:59 AM Mimi Zohar wrote:
> > On Sat, 2024-01-06 at 18:27 -0500, Paul Moore wrote:
> > > On Tue, Nov 28, 2023 at 9:07 PM Mimi Zohar wrote:
> > > > On Tue, 2023-11-28 at 20:06 -0500, Paul
On Fri, 2024-01-05 at 12:20 -0800, Tushar Sugandhi wrote:
> >> diff --git a/security/integrity/ima/Kconfig
> >> b/security/integrity/ima/Kconfig
> >> index 60a511c6b583..8792b7aab768 100644
> >> --- a/security/integrity/ima/Kconfig
> >> +++ b/security/integrity/ima/Kconfig
> >> @@ -338,3 +338,12
On Fri, 2024-01-05 at 12:22 -0800, Tushar Sugandhi wrote:
> >> @@ -194,6 +206,15 @@ static int ima_update_kexec_buffer(struct
> >> notifier_block *self,
> >> return ret;
> >> }
> >>
> >> +buf_size = ima_get_binary_runtime_size();
> >> +scnprintf(ima_kexec_event,
On Sat, 2024-01-06 at 18:27 -0500, Paul Moore wrote:
> On Tue, Nov 28, 2023 at 9:07 PM Mimi Zohar wrote:
> > On Tue, 2023-11-28 at 20:06 -0500, Paul Moore wrote:
> > > On Tue, Nov 28, 2023 at 7:09 AM Mimi Zohar wrote:
> > > > On Mon, 2023-11-27 at 17:16 -0500, Paul
On Fri, 2023-12-15 at 17:07 -0800, Tushar Sugandhi wrote:
> If the new measurements are added to the IMA log while it is being
> being copied to the kexec buffer during kexec 'execute', it can miss
> copying those new measurements to the kexec buffer, and the buffer can go
> out of sync with TPM
On Fri, 2023-12-15 at 17:07 -0800, Tushar Sugandhi wrote:
> There could be a potential mismatch between IMA measurements and TPM PCR
> quotes caused by the indeterminate interval between kexec 'load' and
> 'execute'. Memory allocated at kexec 'load' for IMA log buffer may run
> out. It can lead
Hi Tushar,
The Subject line should include the word "extra". The use of the
extra memory isn't limited to the measurements between the kexec load
and exec. Additional records could be added as a result of the kexec
load itself. Let's simplify the title to "ima: make the kexec extra
memory
Hi Tushar,
On Fri, 2023-12-15 at 17:07 -0800, Tushar Sugandhi wrote:
> ima_dump_measurement_list() is called from ima_add_kexec_buffer() during
> kexec 'load', which may result in loss of IMA measurements between kexec
> 'load' and 'execute'. It needs to be called during kexec 'execute'.
>
>
On Fri, 2023-12-15 at 17:07 -0800, Tushar Sugandhi wrote:
> Refactor ima_dump_measurement_list() to move the memory allocation part
> to a separate function ima_alloc_kexec_file_buf() to allocate buffer of
> size 'kexec_segment_size' at kexec 'load'. Make the local variables in
> function
On Tue, 2023-11-28 at 20:06 -0500, Paul Moore wrote:
> On Tue, Nov 28, 2023 at 7:09 AM Mimi Zohar wrote:
> > On Mon, 2023-11-27 at 17:16 -0500, Paul Moore wrote:
> > > On Mon, Nov 27, 2023 at 12:08 PM Mimi Zohar wrote:
> > > > On Wed, 2023-11-22 at
On Mon, 2023-11-27 at 17:16 -0500, Paul Moore wrote:
> On Mon, Nov 27, 2023 at 12:08 PM Mimi Zohar wrote:
> > On Wed, 2023-11-22 at 09:22 -0500, Paul Moore wrote:
>
> ...
>
> > > Okay, we are starting to get closer, but I'm still missing the part
> > > where
On Wed, 2023-11-22 at 09:22 -0500, Paul Moore wrote:
> On Wed, Nov 22, 2023 at 8:18 AM Mimi Zohar wrote:
> > On Tue, 2023-11-21 at 23:27 -0500, Paul Moore wrote:
> > > On Thu, Nov 16, 2023 at 5:28 PM Paul Moore wrote:
> > > > On Tue, Oct 31, 202
On Tue, 2023-11-21 at 23:27 -0500, Paul Moore wrote:
> On Thu, Nov 16, 2023 at 5:28 PM Paul Moore wrote:
> > On Tue, Oct 31, 2023 at 3:15 PM Mimi Zohar wrote:
>
> ...
>
> > > Userspace can already export the IMA measurement list(s) via the
> > > securityfs
On Tue, 2023-11-21 at 17:01 -0800, Tushar Sugandhi wrote:
> Hi Mimi,
> To address your concern about pausing the measurements -
> We are not proposing to pause the measurements for the entire duration
> of UM <--> Kernel interaction while taking a snapshot.
>
> We are simply proposing to pause
On Thu, 2023-10-19 at 11:49 -0700, Tushar Sugandhi wrote:
[...]
> ---
> | C.1 Solution Summary|
> ---
> To
On Fri, 2023-10-27 at 11:18 -0400, Mimi Zohar wrote:
> On Thu, 2023-10-05 at 11:25 -0700, Tushar Sugandhi wrote:
> > The current Kernel behavior is IMA measurements snapshot is taken at
> > kexec 'load' and not at kexec 'execute'. IMA log is then carried
> > over to the n
On Thu, 2023-10-05 at 11:25 -0700, Tushar Sugandhi wrote:
> The current Kernel behavior is IMA measurements snapshot is taken at
> kexec 'load' and not at kexec 'execute'. IMA log is then carried
> over to the new Kernel after kexec 'execute'.
>
> Some systems can be configured to call kexec
Hi Tushar,
On Thu, 2023-10-05 at 11:26 -0700, Tushar Sugandhi wrote:
> The window between kexec 'load' and 'execute' could be arbitrarily long.
> Even with the large chunk of memory allocated at kexec 'load', it may
> run out which would result in missing events in IMA log after the system
> soft
Hi Tushar,
On Thu, 2023-10-05 at 11:25 -0700, Tushar Sugandhi wrote:
> In the current IMA implementation, ima_dump_measurement_list() is called
> during the kexec 'load' operation. This can result in loss of IMA
> measurements taken between the 'load' and 'execute' phases when the
> system goes
On Thu, 2023-10-26 at 16:16 -0400, Mimi Zohar wrote:
> Hi Tushar,
>
> According to Documentation/process/submitting-patches.rst, the subject
> line should be between 70-75 characters.
>
> Perhaps something like "ima: define and call ima_alloc_kexec_buffer()".
>
Hi Tushar,
According to Documentation/process/submitting-patches.rst, the subject
line should be between 70-75 characters.
Perhaps something like "ima: define and call ima_alloc_kexec_buffer()".
On Thu, 2023-10-05 at 11:25 -0700, Tushar Sugandhi wrote:
> IMA allocates memory and dumps the
On Wed, 2023-08-30 at 19:22 -0400, Paul Moore wrote:
> On Wed, Aug 30, 2023 at 7:07 PM Mimi Zohar wrote:
> > On Wed, 2023-08-30 at 18:23 -0400, Paul Moore wrote:
> > > On Wed, Aug 30, 2023 at 6:21 PM Paul Moore wrote:
> > > > On Wed, Aug 30, 2023 at 5:50 PM Mimi
On Wed, 2023-08-30 at 18:23 -0400, Paul Moore wrote:
> On Wed, Aug 30, 2023 at 6:21 PM Paul Moore wrote:
> > On Wed, Aug 30, 2023 at 5:50 PM Mimi Zohar wrote:
> > > On Wed, 2023-08-30 at 16:47 -0400, Paul Moore wrote:
> > > > On Wed, Aug 30, 2023 at 4:25 PM Mim
On Wed, 2023-08-30 at 16:47 -0400, Paul Moore wrote:
> On Wed, Aug 30, 2023 at 4:25 PM Mimi Zohar wrote:
> > Your initial question was "what happens if the file/filesystem becomes
> > inaccessible at some point and an attestation client attempts to read
> > the enti
On Tue, 2023-08-29 at 19:15 -0400, Paul Moore wrote:
> On Tue, Aug 29, 2023 at 5:54 PM Mimi Zohar wrote:
> > On Tue, 2023-08-29 at 17:30 -0400, Paul Moore wrote:
> > > On Tue, Aug 29, 2023 at 5:05 PM Mimi Zohar wrote:
> > > > On Tue, 2023-08-29 at 15:34 -0400, Paul
On Tue, 2023-08-29 at 17:30 -0400, Paul Moore wrote:
> On Tue, Aug 29, 2023 at 5:05 PM Mimi Zohar wrote:
> > On Tue, 2023-08-29 at 15:34 -0400, Paul Moore wrote:
> > > On Mon, Aug 21, 2023 at 7:08 PM Mimi Zohar wrote:
> > > > On Mon, 2023-08-21 at 15:05 -0
On Tue, 2023-08-29 at 15:34 -0400, Paul Moore wrote:
> On Mon, Aug 21, 2023 at 7:08 PM Mimi Zohar wrote:
> > On Mon, 2023-08-21 at 15:05 -0700, Sush Shringarputale wrote:
> > > On 8/14/2023 3:02 PM, Mimi Zohar wrote:
> > > > On Mon, 2023-08-14 at 14:42 -0
On Mon, 2023-08-21 at 15:05 -0700, Sush Shringarputale wrote:
>
> On 8/14/2023 3:02 PM, Mimi Zohar wrote:
> > On Mon, 2023-08-14 at 14:42 -0700, Sush Shringarputale wrote:
> >>> This design seems overly complex and requires synchronization between
> >>>
On Mon, 2023-08-14 at 14:42 -0700, Sush Shringarputale wrote:
> > This design seems overly complex and requires synchronization between
> > the "snapshot" record and exporting the records from the measurement
> > list. None of this would be necessary if the measurements were copied
> > from
Hi Sush, Tushar,
On Tue, 2023-08-01 at 12:12 -0700, Sush Shringarputale wrote:
>
> | A. Problem Statement |
>
> Depending on the IMA policy, the IMA log can consume a lot of
On Mon, 2023-08-07 at 10:52 +0800, Wenyu Liu wrote:
> kexec_mutex is replaced by an atomic variable
> in 05c6257433b (panic, kexec: make __crash_kexec() NMI safe).
>
> But there are still two comments that referenced kexec_mutex,
> replace them by kexec_lock.
>
> Signed-off-by: Wenyu Liu
>
On Thu, 2023-08-03 at 16:01 -0700, Tushar Sugandhi wrote:
> >> +scnprintf(buf, IMA_TPM_UPDATE_CTR_BUF_SIZE, "update_counter=%u;",
> >> + update_counter);
> >> +
> >> +buf_len = strlen(buf);
> >> +
> >> +result = ima_measure_critical_data("tpm_pcr_update_counter",
On Thu, 2023-08-03 at 16:34 -0700, Tushar Sugandhi wrote:
> >> +++ b/security/integrity/ima/ima_init.c
> >> @@ -154,5 +154,8 @@ int __init ima_init(void)
> >> UTS_RELEASE, strlen(UTS_RELEASE), false,
> >> NULL, 0);
> >>
> >> + /*
On Thu, 2023-08-03 at 18:09 -0400, Stefan Berger wrote:
> > I can remove the kexec example if it is causing confusion.> Please let me
> > know.
>
> I am not convinced we need this series ... :-( Your kexec series prevents
> further logging and especially PCR extensions after the frozen
On Tue, 2023-08-01 at 11:19 -0700, Tushar Sugandhi wrote:
> IMA log entries can be lost due to a variety of causes, such as code bugs
> or error conditions, leading to a mismatch between TPM PCRs and
> the IMA log. Measuring TPM PCR update counter during ima_init would
> provide a baseline
On Tue, 2023-08-01 at 11:19 -0700, Tushar Sugandhi wrote:
> Currently TPM update counter is not available external to the system,
> for instance, a remote attestation service. It is a problem because
> the service cannot easily determine if the IMA log entries are missing.
> The IMA functionality
On Wed, 2023-08-02 at 06:58 +0300, Jarkko Sakkinen wrote:
>
> From long description I see zero motivation to ack this change, except
> some heresay about IMA requiring it. Why does IMA need update_cnt and
> why this is not documented to the long description?
The motivation is to detect whether
[CC'ing Paul Moore]
On Fri, 2023-07-14 at 09:46 +0800, Coiby Xu wrote:
> On Wed, Jul 12, 2023 at 02:31:43PM -0400, Mimi Zohar wrote:
> >[Cc'ing the LSM mailing list.]
> >
> >On Tue, 2023-07-11 at 11:16 +0800, Coiby Xu wrote:
> >> When IMA has verified the signature
[Cc'ing the LSM mailing list.]
On Tue, 2023-07-11 at 11:16 +0800, Coiby Xu wrote:
> When IMA has verified the signature of the kernel image, kexec'ing this
> kernel should be allowed.
>
> Fixes: af16df54b89d ("ima: force signature verification when CONFIG_KEXEC_SIG
> is configured")
>
On Tue, 2023-07-11 at 12:08 -0700, Tushar Sugandhi wrote:
> Adding Eric to cc.
>
> On 7/7/23 12:49, Mimi Zohar wrote:
> > On Fri, 2023-07-07 at 11:01 -0400, Mimi Zohar wrote:
> >> Hi Tushar,
> >>
> >> On Mon, 2023-07-03 at 14:57 -0700, Tushar Sugandhi wro
On Tue, 2023-07-11 at 10:59 -0700, Tushar Sugandhi wrote:
> Adding Eric to cc.
>
> On 7/7/23 06:00, Mimi Zohar wrote:
> > Hi Tushar,
> >
> > On Mon, 2023-07-03 at 14:57 -0700, Tushar Sugandhi wrote:
> >> IMA does not provide a mechanism to allocate memory f
On Fri, 2023-07-07 at 11:01 -0400, Mimi Zohar wrote:
> Hi Tushar,
>
> On Mon, 2023-07-03 at 14:57 -0700, Tushar Sugandhi wrote:
>
> > +/*
> > + * Called during kexec execute so that IMA can update the measurement list.
> > + */
> > +static int ima_update_kexe
On Mon, 2023-07-03 at 14:56 -0700, Tushar Sugandhi wrote:
> The current Kernel behavior is IMA measurements snapshot is taken at
> kexec 'load' and not at kexec 'execute'. IMA log is then carried
> over to the new Kernel after kexec 'execute'.
>
> Some devices can be configured to call kexec
Hi Tushar,
On Mon, 2023-07-03 at 14:57 -0700, Tushar Sugandhi wrote:
> +/*
> + * Called during kexec execute so that IMA can update the measurement list.
> + */
> +static int ima_update_kexec_buffer(struct notifier_block *self,
> +unsigned long action, void *data)
Hi Tushar,
On Mon, 2023-07-03 at 14:57 -0700, Tushar Sugandhi wrote:
> The ima_dump_measurement_list function was designed to iterate over the
> IMA measurement list and store each entry into a buffer. The buffer,
> along with its size, would be returned to the caller. However, the
> function
Hi Tushar,
On Mon, 2023-07-03 at 14:57 -0700, Tushar Sugandhi wrote:
> There is no existing IMA functionality to just populate the buffer at
> kexec execute with IMA measurements.
The same function that copies the measurement list at kexec 'load',
could be re-used at kexec 'exec'. Why is a new
Hi Tushar,
The function to "ima: allocate buffer at kexec load to hold ima
measurements" already exists. Please update the Subject line to
indicate increasing the IMA kexec buffer size.
On Mon, 2023-07-03 at 14:57 -0700, Tushar Sugandhi wrote:
> The IMA subsystem needs a dedicated mechanism to
Hi Tushar,
On Mon, 2023-07-03 at 14:57 -0700, Tushar Sugandhi wrote:
> IMA does not provide a mechanism to allocate memory for IMA log storage
> during kexec operation.
The IMA measurement list is currently being carried across kexec, so
obviously a buffer is being allocated for it. IMA not
On Tue, 2023-06-06 at 11:37 -0400, Stefan Berger wrote:
>
> On 5/31/23 18:43, Mimi Zohar wrote:
> > On Wed, 2023-05-31 at 15:02 -0700, Tushar Sugandhi wrote:
> >> Hi Mimi,
> >>
> >> On 5/31/23 04:39, Mimi Zohar wrote:
> >>> Hi Tushar,
> >&g
On Wed, 2023-05-31 at 15:02 -0700, Tushar Sugandhi wrote:
> Hi Mimi,
>
> On 5/31/23 04:39, Mimi Zohar wrote:
> > Hi Tushar,
> >
> > On Thu, 2023-05-25 at 10:21 -0700, Tushar Sugandhi wrote:
> >
> >> The issue of IMA measurements getting lost between kex
Hi Tushar,
On Thu, 2023-05-25 at 10:21 -0700, Tushar Sugandhi wrote:
> The issue of IMA measurements getting lost between kexec 'load' and 'execute'
> still exists.
> I verified it on the mainline kernel 6.4.rc3. See *Appendix A* for details.
>
> I went through Thiago's patches he wrote
Hi Coiby,
On Fri, 2022-12-30 at 14:58 +0800, Coiby Xu wrote:
> A kernel builder may not enable KEXEC_SIG and some architectures like
> ppc64 simply don't have KEXEC_SIG. In these cases, unless both
> IMA_ARCH_POLICY and secure boot also enabled, lockdown doesn't prevent
> unsigned kernel image
e_load failed (missing IMA sig) [PASS]
> ok 2 selftests: kexec: test_kexec_file_load.sh
>
> Cc: kexec@lists.infradead.org
> Cc: linux-integr...@vger.kernel.org
> Suggested-by: Mimi Zohar
> Signed-off-by: Coiby Xu
> ---
> .../selftests/kexec/kexec_
On Tue, 2022-11-22 at 10:36 +0800, Coiby Xu wrote:
> Hi Mimi,
>
> On Mon, Nov 21, 2022 at 01:23:57PM -0500, Mimi Zohar wrote:
> >Hi Coiby,
> >
> >On Mon, 2022-11-21 at 15:29 +0800, Coiby Xu wrote:
> >> A kernel builder may not enable KEXEC_SIG and some archit
Matthew Garrett
> Cc: Jiri Bohac
> Cc: David Howells
> Cc: kexec@lists.infradead.org
> Cc: linux-integr...@vger.kernel.org
> Signed-off-by: Coiby Xu
Other than correcting the function name to mandate_signature_verificati
on(),
Reviewed-by: Mimi Zohar
_
On Fri, 2022-09-23 at 19:10 +0200, Michal Suchanek wrote:
> Hello,
>
> this is backport of commit 0d519cadf751
> ("arm64: kexec_file: use more system keyrings to verify kernel image
> signature")
> to table 5.15 tree including the preparatory patches.
>
> Some patches needed minor adjustment
s configured.
>
> Fixes: 99d5cadfde2b ("kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and
> KEXEC_SIG_FORCE")
> Reported-by: Mimi Zohar
> Suggested-by: Mimi Zohar
> Signed-off-by: Coiby Xu
> ---
> v2
> - don't include linux/kexec.h since it's already
s configured.
>
> Fixes: 99d5cadfde2b ("kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and
> KEXEC_SIG_FORCE")
> Reported-by: Mimi Zohar
> Suggested-by: Mimi Zohar
> Signed-off-by: Coiby Xu
Thanks, Coiby. This patch is now queued in next-
On Thu, 2022-07-07 at 13:20 -0400, Stefan Berger wrote:
> Refactor IMA buffer related functions to make them reusable for carrying
> TPM logs across kexec.
>
> Signed-off-by: Stefan Berger
> Cc: Rob Herring
> Cc: Frank Rowand
> Cc: Mimi Zohar
Re
; -*/
This comment is dropped. Perhaps not in such detail, but shouldn't a
comment or function description exist in the new function.
Otherwise,
Reviewed-by: Mimi Zohar
thanks,
Mimi
___
kexec mailing list
kexec@lists.infradead.org
http://
On Fri, 2022-07-08 at 10:10 +, Jonathan McDowell wrote:
> This patchset is not yet complete, but it's already moving around a
> bunch of stuff so I am sending it out to get either some agreement that
> it's a vaguely sane approach, or some pointers about how I should be
> doing this instead.
>
On Thu, 2022-07-07 at 22:10 +0800, Coiby Xu wrote:
> Hi Mimi,
>
> On Wed, Jul 06, 2022 at 10:33:50AM -0400, Mimi Zohar wrote:
> >On Wed, 2022-07-06 at 12:48 +0100, Will Deacon wrote:
> [..]
> >> It looks like this series is ready to go, but it's not clear who should
>
On Wed, 2022-07-06 at 12:48 +0100, Will Deacon wrote:
> On Wed, Jul 06, 2022 at 07:35:36AM -0400, Mimi Zohar wrote:
> > On Mon, 2022-07-04 at 09:51 +0800, Coiby Xu wrote:
> > > Currently when loading a kernel image via the kexec_file_load() system
> > > call, x86 can mak
On Mon, 2022-07-04 at 09:51 +0800, Coiby Xu wrote:
> Currently when loading a kernel image via the kexec_file_load() system
> call, x86 can make use of three keyrings i.e. the .builtin_trusted_keys,
> .secondary_trusted_keys and .platform keyrings to verify a signature.
> However, arm64 and s390
Frank Rowand
> Cc: Mimi Zohar
Refactoring the ima_get_kexec_buffer sounds good, but there's a merge
conflict with Jonathan McDowell's commit "b69a2afd5afc x86/kexec: Carry
forward IMA measurement log on kexec".
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/dr
eparator).
>
> Signed-off-by: Jonathan McDowell
> Link: https://lore.kernel.org/r/YmKyvlF3my1yWTvK@noodles-fedora-PC23Y6EG
Reviewed-by: Mimi Zohar # IMA function
definitions
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On Thu, 2022-06-16 at 09:21 +0800, Coiby Xu wrote:
> Hi Mimi,
>
> On Thu, Jun 09, 2022 at 11:35:13AM -0400, Mimi Zohar wrote:
> >Hi Coiby,
> >
> >On Fri, 2022-05-27 at 21:43 +0800, Coiby Xu wrote:
> >> It seems I need to only change cover letter and commit m
On Fri, 2022-06-17 at 11:57 +0800, Coiby Xu wrote:
> >Thanks for explaining IMA to me! There is still the question of what's
> >the root of trust for .builtin_trusted_keys when there is no real
> >signature verification. For example, when CONFIG_KEXEC_SIG is enabled,
> >the default IMA policy is
ima_free_kexec_buffer(void)
>
> return memblock_phys_free(addr, size);
> }
> +#endif
Inside ima_{get,free}_kexec_buffer(), there's no need now to test
whether CONFIG_HAVE_IMA_KEXEC is enabled.
if (!IS_ENABLED(CONFIG_HAVE_IMA_KEXEC))
return -ENOTSUPP;
Otherwise,
On Thu, 2022-05-12 at 15:01 +0800, Coiby Xu wrote:
> Currently, a problem faced by arm64 is if a kernel image is signed by a
> MOK key, loading it via the kexec_file_load() system call would be
> rejected with the error "Lockdown: kexec: kexec of unsigned images is
> restricted; see man
Hi Coiby,
On Thu, 2022-05-12 at 15:01 +0800, Coiby Xu wrote:
> commit 278311e417be ("kexec, KEYS: Make use of platform keyring for
> signature verify") adds platform keyring support on x86 kexec but not
> arm64.
>
> The code in bzImage64_verify_sig makes use of system keyrings including
>
On Thu, 2022-05-12 at 15:01 +0800, Coiby Xu wrote:
> kimage_validate_signature(struct kimage *image)
> {
> int ret;
>
> - ret = arch_kexec_kernel_verify_sig(image, image->kernel_buf,
> - image->kernel_buf_len);
> + ret =
Hi Coiby,
On Fri, 2022-05-27 at 21:43 +0800, Coiby Xu wrote:
> It seems I need to only change cover letter and commit message i.e.
> there is no concern about the code. So it's better to provide a
> new cover letter here to collect new feedback from you thus we
> can avoid unnecessary rounds of
On Fri, 2022-05-27 at 21:43 +0800, Coiby Xu wrote:
> Hi Mini,
Hi Coiby,
> new cover letter here to collect new feedback from you thus we
> can avoid unnecessary rounds of patch set.
Agreed. Much better. Just a couple of nits.
> Currently when loading a kernel image via the
On Wed, 2022-05-25 at 17:59 +0800, Coiby Xu wrote:
> Hi Mimi,
>
> On Fri, May 20, 2022 at 01:04:47PM -0400, Mimi Zohar wrote:
> >Hi Coiby,
> >
> >On Thu, 2022-05-12 at 15:01 +0800, Coiby Xu wrote:
> >
> >The cover letter should start out with an overall p
Hi Coiby,
On Thu, 2022-05-12 at 15:01 +0800, Coiby Xu wrote:
The cover letter should start out with an overall problem description
and then continue with the specifics. In this case each of the arch's
use different keyrings to validate the kexec kernel image signature. I
would continue with
[Cc'ing Jarkko, linux-integrity]
On Thu, 2022-05-19 at 08:39 +0800, Baoquan He wrote:
> On 05/18/22 at 01:29pm, Heiko Carstens wrote:
> > On Thu, May 12, 2022 at 03:01:23PM +0800, Coiby Xu wrote:
> > > From: Michal Suchanek
> > >
> > > commit e23a8020ce4e ("s390/kexec_file: Signature
On Mon, 2022-02-14 at 16:55 +0100, Michal Suchánek wrote:
> Hello,
>
> On Mon, Feb 14, 2022 at 10:14:16AM -0500, Mimi Zohar wrote:
> > Hi Michal,
> >
> > On Sun, 2022-02-13 at 21:59 -0500, Mimi Zohar wrote:
> >
> > >
> > > On Tue, 2022-01-11
Hi Michal,
On Sun, 2022-02-13 at 21:59 -0500, Mimi Zohar wrote:
>
> On Tue, 2022-01-11 at 12:37 +0100, Michal Suchanek wrote:
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index dea74d7717c0..1cde9b6c5987 100644
> > --- a/arch/powerpc/Kconfig
> &
Hi Michal,
On Tue, 2022-01-11 at 12:37 +0100, Michal Suchanek wrote:
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index dea74d7717c0..1cde9b6c5987 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -560,6 +560,22 @@ config KEXEC_FILE
> config
[Cc'ing Nageswara R Sastry]
Hi Michal,
On Tue, 2022-01-11 at 12:37 +0100, Michal Suchanek wrote:
> Hello,
>
> This is a refresh of the KEXEC_SIG series.
>
> This adds KEXEC_SIG support on powerpc and deduplicates the code dealing
> with appended signatures in the kernel.
Hi Michal,
On Tue, 2022-01-11 at 12:37 +0100, Michal Suchanek wrote:
> Hello,
>
> This is a refresh of the KEXEC_SIG series.
> This adds KEXEC_SIG support on powerpc and deduplicates the code dealing
> with appended signatures in the kernel.
>
> powerpc supports IMA_KEXEC but that's an
Hi Michal,
On Wed, 2022-02-09 at 13:01 +0100, Michal Suchánek wrote:
> > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > > index dea74d7717c0..1cde9b6c5987 100644
> > > --- a/arch/powerpc/Kconfig
> > > +++ b/arch/powerpc/Kconfig
> > > @@ -560,6 +560,22 @@ config KEXEC_FILE
> > >
[Cc'ing Sasha]
On Thu, 2020-07-09 at 01:18 -0500, Tyler Hicks wrote:
> I envision patches 1-7 going to stable. The series is ordered in a way
> that has all the fixes up front, followed by cleanups, followed by the
> feature patch. The breakdown of patches looks like so:
>
> Memory leak fixes:
1 - 100 of 436 matches
Mail list logo
