Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
From:   Jonathan McDowell <noodles@fb.com>
To:     Mimi Zohar <zohar@linux.ibm.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>,
        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] Carry forward IMA measurement log on kexec on x86_64
Thread-Topic: [PATCH] Carry forward IMA measurement log on kexec on x86_64
Thread-Index: AQHYVk//Rm0WwwIkeUGnwDIT6Grq2q0A1peAgAFJh4CAABxEgIAAMeMA
Date:   Tue, 26 Apr 2022 16:48:30 +0000
Message-ID: <YmgiWpHWH6K1feyt@noodles-fedora-PC23Y6EG>
References: <YmKyvlF3my1yWTvK@noodles-fedora-PC23Y6EG>
 <12108732c287a85a417927de37cb027cefae6e06.camel@linux.ibm.com>
 <YmfgyyUs6TgM/Czx@noodles-fedora-PC23Y6EG>
 <41f9d261a7750e576460360c512a8e4c1492efa3.camel@linux.ibm.com>
In-Reply-To: <41f9d261a7750e576460360c512a8e4c1492efa3.camel@linux.ibm.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?zzUTNlxp+CNwypAZIp8DTexl7RWz7r4MG0KjIn0TpoNvq02nn0kiY/sWRu2n?=
 =?us-ascii?Q?Hnzgg70p0AQ6vrR8CMsX9QE6GSOe4WMjOW+w0MQ7Sdk1LKtbwJ+cWMgC4Mhr?=
 =?us-ascii?Q?ELA81OccpUWLgp9/+h7Slk7fNOIdq9IzFBqFUihBRPBB3DTaW2JzrCs0abAP?=
 =?us-ascii?Q?Dvynl9iYdDYZeJOS8Nqe6JnAaxFhVxkCzfuh76RJUjAeTGfC8BN7TrVXGXm4?=
 =?us-ascii?Q?RABRXvJc1YiO3gnzxUQw12ntYRjxpJ+O+inOa1zZDHfrbPoEPIQH76cM7JTG?=
 =?us-ascii?Q?ASRErp3B+0lubzhf0X9JXoW7NznN5gdV8Z74xtCrS81pFXEhT7tj5i/kTmb6?=
 =?us-ascii?Q?PH8MtmVzOG5vo88E2l1bPn8TNmq19YkhA+/We/vMbb1GMzTEYjv4f2K4UdYM?=
 =?us-ascii?Q?3iXTHVtIi4N4hMd54GMubSvCrZF2ofzyl+7Hb0J8VveZ1kCFxfGFysN6t2y4?=
 =?us-ascii?Q?dZjlN/Cp3GoUD5hMcIGLZXnQDevH5GZYDDBRziiCDTonFuum894Aet65xWcg?=
 =?us-ascii?Q?CqG/OkqH+qEjIirVHcfTqRFawTlYGUubPEmq0Sl+oWMAPfFwLFIhxFmnW8B8?=
 =?us-ascii?Q?AxvPQdGjXmT6agPSB1oPQ1g+gzEurZ/vnFH44Qdu/mO2QKB1Y5aAMkuh/uvk?=
 =?us-ascii?Q?pWH0HgI4rLE9gd2hkH3y69d8k9lBopnEeLF/dI71rYzLZ+U8V7yGwDr1fM0F?=
 =?us-ascii?Q?GoYRr+wKPP/JnJZeXehrLlpzgVBkyICHLVF/5qT12AlyhJB1slzICoy0RJmO?=
 =?us-ascii?Q?uQvCYbKNpONQlFNjbCpFmoFWpv4nWNizuF1T4Dss2B/yYBcxrQyuOfKJPpTX?=
 =?us-ascii?Q?rz8NLMVOIq3zbFnmGooMSlhg/69a92WbVbKLvOWrp3VszWy7Lml4q/c3DvpW?=
 =?us-ascii?Q?2zsQxZYAMO4nNa5CNaMRoJb5DxzZdNdJQIksj9tjVlNNXXLdpSllcMG7/jAs?=
 =?us-ascii?Q?8F8BGWn1T6kxnELQzFvFY2s9pI4JEIyJU343vlmucaQAzH4Syu2q9c/muNKM?=
 =?us-ascii?Q?DE3Dd1QhJ4phXcVug5JBXkbV0A5+M8ivSHgj0ok/76qV/m08X2WcFct//usB?=
 =?us-ascii?Q?bGcokSnLq8lA9sVPZaN/qID+U0QbIeveVx8WuYFZ+o+qU52NXjKweNNcDWfQ?=
 =?us-ascii?Q?a0Evy8QYT1feCRaXTR0QJqPh5kSatVnow2bxn7YU0/9uE/+ZtfYb2dKrG96T?=
 =?us-ascii?Q?/HWhckb6gYNqNgUYgecMN7zmUkK+udjXs4ye0gJCrQ7r4mvqeGQrzX+igdzr?=
 =?us-ascii?Q?IypKALBNdRmt4+4GEafSzwYXsmlpB1oia16JVjDEzdq5uoZ8VZBoAlJ4sxYV?=
 =?us-ascii?Q?W3BIAKhPE4UAMBRHa/qbmFIRS1rsAl/bIv1e7JASqPNecVOrqlP124Q3sdNy?=
 =?us-ascii?Q?FvWHFjsnImE4H6X3VAwKb4amkUx37kUw9Pze8t1q3fKw5XaOnlZJpQjW/Ax6?=
 =?us-ascii?Q?Eiu0lHorB+lQrz1U5cYvhT2See32m2Fu2vY7a26Gx+pdjOiVj/iREvLTp1f5?=
 =?us-ascii?Q?tH9EpI2RLEYioc6kGkvkeiuhpQNNT9RjhG9Ia+Q4YViiR5pGzLStVHWfFNkn?=
 =?us-ascii?Q?cECDaIGauDaoRb+Y/KMFdle4XiiK4KTMCwWpVQPMnfXCoMaoUJrIS2He6bdG?=
 =?us-ascii?Q?xTuJw1kATHrFifXsvspMgN9EDKxX2kgE040/vDI2jSNTAsNpsY+sZf/yFR4L?=
 =?us-ascii?Q?usTvydAuHAx/UXI4AyN+lopoE/dZWSIcmIuCgbBiv5kR6BuNBgxvyK14AQ2Y?=
 =?us-ascii?Q?OUWQwBrQgw=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9244233BC5B92C4FB5734B562001CED5@namprd15.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: fb.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR15MB4552.namprd15.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9114db21-32c8-4d29-8a29-08da27a49868
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2022 16:48:31.0985
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: S6wMV02Ai6hLOVUDoFLyOCbqudfnYAH5dYFUHBXWTT2GLtLf1Sdx7yQMH10rOm6r
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR15MB5120
X-Proofpoint-ORIG-GUID: rruNIQ0RDMfw5equIb3UtNTUJ3fmhSL2
X-Proofpoint-GUID: rruNIQ0RDMfw5equIb3UtNTUJ3fmhSL2
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.858,Hydra:6.0.486,FMLib:17.11.64.514
 definitions=2022-04-26_05,2022-04-26_02,2022-02-23_01
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
	DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE autolearn=unavailable
	autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Apr 26, 2022 at 09:49:53AM -0400, Mimi Zohar wrote:
> On Tue, 2022-04-26 at 12:08 +0000, Jonathan McDowell wrote:
> > On Mon, Apr 25, 2022 at 12:29:17PM -0400, Mimi Zohar wrote:
> > > Hi Jonathan,
> > > 
> > > On Fri, 2022-04-22 at 13:50 +0000, Jonathan McDowell wrote:
> > > > On kexec file load Integrity Measurement Architecture (IMA) subsystem
> > > > may verify the IMA signature of the kernel and initramfs, and measure
> > > > it. The command line parameters passed to the kernel in the kexec call
> > > > may also be measured by IMA. A remote attestation service can verify
> > > > a TPM quote based on the TPM event log, the IMA measurement list, and
> > > > the TPM PCR data. This can be achieved only if the IMA measurement log
> > > > is carried over from the current kernel to the next kernel across
> > > > the kexec call.
> > > > 
> > > > powerpc and ARM64 both achieve this using device tree with a
> > > > "linux,ima-kexec-buffer" node. x86 platforms generally don't make use of
> > > > device tree, so the IMA infrastructure is extended to allow non device
> > > > tree platforms to provide a log buffer. x86 then passes the IMA buffer
> > > > to the new kernel via the setup_data mechanism.
> > > > 
> > > > Signed-off-by: Jonathan McDowell <noodles@fb.com>
> > > 
> > > FYI, after applying, building, and booting a kernel with this patch,
> > > "kexec -s -l /boot/vmlinuz-5.18.0-rc4+ --reuse-cmdline --
> > > initrd=/boot/initramfs-5.18.0-rc4+.img" properly loads the kernel, but
> > > "kexec -s -e" fails to reboot, at least on a test laptop even with only
> > > the "boot_aggregate" measurement record.
> > > 
> > > Without enabling CONFIG_IMA_KEXEC, kexec boots properly.
> > 
> > Thanks for giving it a try. At a guess your laptop is booting with
> > EFI, whereas for my testing I was using qemu with legacy BIOS. I've
> > managed to reproduce the issue with qemu+OVMF and isolated the mistake
> > in the setup data calculation I made when EFI is involved. If you have
> > time can you try with the below on top of the original patch?
> 
> Thank you!  With the change, as expected there are two "boot_aggregate"
> records in the measurement list.  With a custom policy, the measurement
> list verifies.

Excellent, thanks for verifying. I'll get the fixed v2 out.

...
> FYI, the builtin "ima_policy=tcb" results in measurement violations.  
> Normally, the measurement list can still be verified using the evmctl
> "--ignore-violations" option.   For some reason with the "tcb" policy, 
> the measurement list doesn't verify even with the "--ignore-violations" 
> option after kexec.  I assume this is a result of additional
> measurements being added after the kexec load, which aren't being
> carried across kexec.

I believe with "tcb" things like the subsequent exec of kexec to
actually do the reboot will end up measured, and as the kexec buffer is
static it won't include that.

Also there's an issue about the fact that we measure the kexec pieces
even if we don't actually do the kexec; there's no marker that confirms
the kexec took place. It's separate to this patch (in that it affects
the device tree kexec infrastructure too) but it's conceivable that an
attacker could measure in the new kernel details and not actually do the
kexec, and that's not distinguishable from the kexec happening.

One approach might be to add a marker in the kexec ima buffer such that
if it's not present we know the kexec hasn't happened, but I need to
think through that a bit more.

J.