[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1557144779.14288.92.camel@linux.ibm.com>
Date: Mon, 06 May 2019 08:12:59 -0400
From: Mimi Zohar <zohar@...ux.ibm.com>
To: Prakhar Srivastava <prsriva02@...il.com>,
linux-integrity@...r.kernel.org,
linux-secuirty-module@...r.kernel.org, linux-kernel@...r.kernel.org
Cc: ebiederm@...ssion.com, vgoyal@...hat.com, nayna@...ux.ibm.com,
nramas@...rosoft.com, prsriva@...rosoft.com
Subject: Re: [PATCH 0/5 v4] Kexec cmdline bufffer measure
On Fri, 2019-05-03 at 15:25 -0700, Prakhar Srivastava wrote:
> From: Prakhar Srivastava <prsriva02@...il.com>
>
> For Kexec scenario(kexec_file_load) cmdline args are passed to the
> next kerenel. These cmldine args used to load the next kernel can
> have undesired/unwanted configs. To guard against any unwanted cmdline
> args being passed to the next kernel. The current kernel should measure
> the cmdline args to the next kernel, the same takes place in the EFI
> bootloader. Thus on kexec the boot_aggregate does not change.
The boot command line is calculated and added to the current running
kernel's measurement list. On a soft reboot like kexec, the PCRs are
not reset to zero. Refer to commit 94c3aac567a9 ("ima: on soft
reboot, restore the measurement list") patch description.
> Currently the cmdline args are not measured, this changeset adds a new
> ima and LSM hook for buffer measure and calls into the same to measure
> the cmdline args passed to the next kernel.The cdmline args meassured
> can then be used as an attestation criteria.
Please update this paragraph to reflect the current patch set.
>
> The ima logs need to injected into the next kernel, which will be followed
> up by other patchsets.
The log isn't "injected" into the next kernel, but needs to be carried
over, as described in the above referenced commit.
Mimi
Powered by blists - more mailing lists