From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C2225C4332F for ; Mon, 9 May 2022 18:10:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240048AbiEISN5 (ORCPT ); Mon, 9 May 2022 14:13:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44914 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240047AbiEISNw (ORCPT ); Mon, 9 May 2022 14:13:52 -0400 Received: from mail.skyhub.de (mail.skyhub.de [IPv6:2a01:4f8:190:11c2::b:1457]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BAD8816EEB8; Mon, 9 May 2022 11:09:57 -0700 (PDT) Received: from zn.tnic (p5de8eeb4.dip0.t-ipconnect.de [93.232.238.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 1737B1EC01E0; Mon, 9 May 2022 20:09:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1652119792; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=L9Ar+ydmc7t38d3TuBxUw1cNUzBjweI6t/LwvKD8DEI=; b=LlSfo//agkPEyJ0VR6GE3fKki2x2cRN11SSjWMpSJewrU9LoSBPDq4g68zlEIa7ZJqVooK 7/okTqr92ZIgaEVYqIDjMkXwMDwpvqyzVMegVpsryiVt197V2FLQbN+f4mX3CoHpVfV+Ix RcmZ1bN5m+R8fx9+MZPIt56mfAvUvOY= Date: Mon, 9 May 2022 20:09:55 +0200 From: Borislav Petkov To: Jonathan McDowell Cc: Thomas Gleixner , James Morris , Ingo Molnar , Dave Hansen , "H. Peter Anvin" , Dmitry Kasatkin , "x86@kernel.org" , Mimi Zohar , "Serge E. Hallyn" , "linux-kernel@vger.kernel.org" , "linux-integrity@vger.kernel.org" , "linux-security-module@vger.kernel.org" Subject: Re: [PATCH v2] Carry forward IMA measurement log on kexec on x86_64 Message-ID: References: <0960C132-581C-4881-8948-C566657C3998@alien8.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 09, 2022 at 05:46:22PM +0000, Jonathan McDowell wrote: > Device tree on x86 doesn't seem to be a thing; Not a thing? What does that even mean? We have arch/x86/kernel/devicetree.c which adds some minimal devicetree support. > none of the distros I regularly use enable CONFIG_OF for x86, I can > only find 2 32-bit x86 platforms that actually select it and none of > the plumbing for kexec on x86 ties in device tree. And? That can get changed and enabled and so on. > I agree for platforms that make active use of device tree that's the > appropriate path, but it doesn't seem to be the case for x86. I'm not sure what you're aim here is? You want to pass that IMA measurement to the kexec kernel with minimal changes, i.e., change only the kernel? Why can't distros be also changed to use devicetree for the IMA measurement, like the other arches do? Why does x86 need to do it differently? We also pass info to the kexec kernel by reading it from sysfs and having kexec tools pass it to the kexec-ed kernel, see Documentation/ABI/testing/sysfs-firmware-efi-runtime-map kexec(8) itself can do: kexec -l kernel-image --append=command-line-options ^^^^^^^^^^^^^^^^^ and add those cmdline options which are dug out from the first kernel. So is there any particular reason/pressing need to pass the measurement with setup_data? -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette