Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH 0/5 v4] Kexec cmdline bufffer measure
From:   Mimi Zohar <zohar@linux.ibm.com>
To:     Prakhar Srivastava <prsriva02@gmail.com>,
        linux-integrity@vger.kernel.org,
        linux-secuirty-module@vger.kernel.org, linux-kernel@vger.kernel.org
Cc:     ebiederm@xmission.com, vgoyal@redhat.com, nayna@linux.ibm.com,
        nramas@microsoft.com, prsriva@microsoft.com
Date:   Mon, 06 May 2019 08:12:59 -0400
In-Reply-To: <20190503222523.6294-1-prsriva02@gmail.com>
References: <20190503222523.6294-1-prsriva02@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <1557144779.14288.92.camel@linux.ibm.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, 2019-05-03 at 15:25 -0700, Prakhar Srivastava wrote:
> From: Prakhar Srivastava <prsriva02@gmail.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