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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ED509C433F5 for ; Sun, 7 Nov 2021 22:19:51 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1500E6139E for ; Sun, 7 Nov 2021 22:19:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1500E6139E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=axtens.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4HnTFJ5mTZz3bbx for ; Mon, 8 Nov 2021 09:19:48 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=axtens.net header.i=@axtens.net header.a=rsa-sha256 header.s=google header.b=DKLtpSmb; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=axtens.net (client-ip=2607:f8b0:4864:20::42a; helo=mail-pf1-x42a.google.com; envelope-from=dja@axtens.net; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=axtens.net header.i=@axtens.net header.a=rsa-sha256 header.s=google header.b=DKLtpSmb; dkim-atps=neutral Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4HnTDT433Fz2xCB for ; Mon, 8 Nov 2021 09:19:03 +1100 (AEDT) Received: by mail-pf1-x42a.google.com with SMTP id g11so14236612pfv.7 for ; Sun, 07 Nov 2021 14:19:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axtens.net; s=google; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-transfer-encoding; bh=vvhHrDlviXEtiu42f9Ed4TiIZsHPlHHchTgbcPhjOC4=; b=DKLtpSmbwJwijOvRDAEnE4ouv7I+PdkspcRptedwiQW+s7ock1jLZ//bfUU3KqVhBO bBQUAl9KcJ1Q6mAns3nLRjQIQf8hjG69ijlsXDi7sqJ5OokTU1fTXsCKgltrRRuLpfRp 92fkj1s+7TZaU7a4cKiYGeze0dqq2qCOcVosc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=vvhHrDlviXEtiu42f9Ed4TiIZsHPlHHchTgbcPhjOC4=; b=vjBspCioYMxhECpw184qXcDshL/0IBTE7bq3nG/FWz9Z8686705NPwhUctPl6I1/nE HIvzwyPciUDKnkL6aSnPM2onfgNqDcpKSSUKzVmmhAPchDkyZpJFQCWVTgtlV2BnT8+c CQHy/KgwKbxXWS6yHbcEFxviGCUaE3bNaT9iEIC81EFnGsSrj4rzpVF8gjOYhs/+DaDr J+Y7lbusRwalu4vhKcQGFGvY9k6NAWm7cGXztgk329Wk4j3lFaqB4Ip2hlqhj698Z33/ AqwrsUNoZ1VqQ0zycq5ZcsaRl2SIai+Qm9X4SQ0hDCpwvmQO1QYAzmKIXGsUNUpzG+Qd brcA== X-Gm-Message-State: AOAM533y8hrT7hGWWl+9dyb2epPq6VhUuyCIimRGVFoPMLxDMTHIHio/ ng7iuagvcFFtjPLBcHW+0XavBA== X-Google-Smtp-Source: ABdhPJxfFXdXIw4YX3AftpaKpLmcq1g8ANa0foPZPl3tIwJBZSTL0sL86tkEOb1z5QnEzVlr5Hl6Bw== X-Received: by 2002:a05:6a00:8c4:b0:44c:9827:16cc with SMTP id s4-20020a056a0008c400b0044c982716ccmr76290901pfu.7.1636323540309; Sun, 07 Nov 2021 14:19:00 -0800 (PST) Received: from localhost ([2001:4479:e000:e400:9243:f22c:33ee:c8cf]) by smtp.gmail.com with ESMTPSA id d17sm13127106pfo.40.2021.11.07.14.18.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 07 Nov 2021 14:18:59 -0800 (PST) From: Daniel Axtens To: Michal =?utf-8?Q?Such=C3=A1nek?= , Mimi Zohar Subject: Re: [PATCH 0/3] KEXEC_SIG with appended signature In-Reply-To: <20211105131401.GL11195@kunlun.suse.cz> References: <87czneeurr.fsf@dja-thinkpad.axtens.net> <20211105131401.GL11195@kunlun.suse.cz> Date: Mon, 08 Nov 2021 09:18:56 +1100 Message-ID: <87a6ifehin.fsf@dja-thinkpad.axtens.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Thiago Jung Bauermann , Rob Herring , Vasily Gorbik , linux-s390@vger.kernel.org, Heiko Carstens , linux-kernel@vger.kernel.org, David Howells , Lakshmi Ramasubramanian , Luis Chamberlain , keyrings@vger.kernel.org, Paul Mackerras , Frank van der Linden , Jessica Yu , Alexander Gordeev , linuxppc-dev@lists.ozlabs.org, Christian Borntraeger , Hari Bathini Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Michal Such=C3=A1nek writes: > On Fri, Nov 05, 2021 at 09:55:52PM +1100, Daniel Axtens wrote: >> Michal Suchanek writes: >>=20 >> > S390 uses appended signature for kernel but implements the check >> > separately from module loader. >> > >> > Support for secure boot on powerpc with appended signature is planned - >> > grub patches submitted upstream but not yet merged. >>=20 >> Power Non-Virtualised / OpenPower already supports secure boot via kexec >> with signature verification via IMA. I think you have now sent a >> follow-up series that merges some of the IMA implementation, I just >> wanted to make sure it was clear that we actually already have support > > So is IMA_KEXEC and KEXEC_SIG redundant? > > I see some architectures have both. I also see there is a lot of overlap > between the IMA framework and the KEXEC_SIG and MODULE_SIg. Mimi would be much better placed than me to answer this. The limits of my knowledge are basically that signature verification for modules and kexec kernels can be enforced by IMA policies. For example a secure booted powerpc kernel with module support will have the following IMA policy set at the arch level: "appraise func=3DKEXEC_KERNEL_CHECK appraise_flag=3Dcheck_blacklist apprais= e_type=3Dimasig|modsig", (in arch/powerpc/kernel/ima_arch.c) Module signature enforcement can be set with either IMA (policy like "appraise func=3DMODULE_CHECK appraise_flag=3Dcheck_blacklist appraise_type= =3Dimasig|modsig" ) or with CONFIG_MODULE_SIG_FORCE/module.sig_enforce=3D1. Sometimes this leads to arguably unexpected interactions - for example commit fa4f3f56ccd2 ("powerpc/ima: Fix secure boot rules in ima arch policy"), so it might be interesting to see if we can make things easier to understand. I suspect another amusing interaction is that if the IMA verification is used, the signature could be in an xattr rather than an appended signature. Kind regards, Daniel