Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp5220707iob; Mon, 9 May 2022 11:14:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxXBC+o3DFOe9Rwc/A1ESvbkahZ+/cQmwS79ASz26QfNzLdUclobqI3GAcB3l0/aJeBtzZB X-Received: by 2002:a17:903:32c9:b0:15e:c1cc:2409 with SMTP id i9-20020a17090332c900b0015ec1cc2409mr17487303plr.2.1652120054254; Mon, 09 May 2022 11:14:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652120054; cv=none; d=google.com; s=arc-20160816; b=hosQyl1Qz6IR1C0a+JcKrUTOmrt55qLVhLLaca/wlOJUtgCC6H7aYY1uch2a+alDa5 l/D50h5gXzAXkxOfA7RB4NxOCPA+UQuj3H1IfaekcShKWZ5St7jkTCB2cd54G6EidN/L ydjDaYz2HX2U+fTN7KPwiM7q+qdTb+waT/KU6g5UbBSHaBrhsgMFXPfKzZEeWypWrx/F rR8XO2KQYXQb4ZLVZApYlTxofIVthC6Fkh6egSH1XtDy9h81M9kJzivD6gjm2NprLenl JwPTKXxiVoeH7k025drXWPyrSBN6WlhsZXdR9F/fka49bYD9LKbm7jW9AN9WEh2ADWy9 qUTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=L9Ar+ydmc7t38d3TuBxUw1cNUzBjweI6t/LwvKD8DEI=; b=fHRC11/Z7/Y7h7T37zBn/m82G+LMdWdvMOQ/4VUxg94NBSS2xjLonr5uOPHpfmikGY oFKe0lbqUvvDsfoIVnas6HLacdA52zHfPPGNqFF9vw+ufQQZXC0uBKfoPAeZlWH3ICNa EY5olo8uqA4hV26x01Vp95KkHDKxT9Y10QFJ0OakRL7CiaZsOzNZM0djAP2ZFtbdgwTq PZwkpbVLQ2OhDSpBqI53p0UEdQEXxrrie72jfrtgPppOrbS1V8ZVoqBErIAvIc66+yZI RQ+upKTW8sk7VNVW0nMKRqWtCIpuNHGCiRAwS2hM4cDyhUHu3DgRllx8rPf8ILn7I2er dIzA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b="LlSfo//a"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id r12-20020a170902c7cc00b00153b2d16545si309570pla.333.2022.05.09.11.14.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 May 2022 11:14:14 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b="LlSfo//a"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 015BC2B1671; Mon, 9 May 2022 11:10:08 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240049AbiEISN5 (ORCPT + 99 others); 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: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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: 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