Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp939906imu; Wed, 9 Jan 2019 08:51:20 -0800 (PST) X-Google-Smtp-Source: ALg8bN4UVkkkoiFTI5hTSULcMih/7v7pBM+XZYIzAE99vinpM3hsLO0PCPPxAMWxU7g2Vu+P/Jlm X-Received: by 2002:a62:b24a:: with SMTP id x71mr6842574pfe.148.1547052680893; Wed, 09 Jan 2019 08:51:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547052680; cv=none; d=google.com; s=arc-20160816; b=H1V+lxdLJ2w1w3daYFt226axcaqX70C903LIbTI+qVcySpYnYDgST7zyJ9L07hmBpB 04eTPoKVVvO7DH89O5PTxG3vpcLOPOeKLMvdcKW5SeoWajuW5Bzc3/ZAUb2YomjMfSyX 3fCS50bmHUD8QxZtZtmjeibY6TJgZ0MCyRKnLff4CtvF80qzYqSySbMvWN1bZGHQmaZ+ ozLh4f8GElFV6z+0Nib1doyNnITtqbJiu/hwN2zLFgO8YOudb2/TQevEM5laTPNCDnwH 57YncVxz6LYsLjXbbH0N9NsjLIJRsIIJBt9Htpr4hXPt7j1EqBUq7rLc8/+XxhWchUNy ef/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=/TyKnjuPUsqqp0vDvi0fWJq3lA2z48crJ+V0ZGzZe9c=; b=c4IJ+vagyH4HLfcC7L2dZ9erDhd9MIoRBNm1C6cDQTT8+Yn/k/gyRFh1AK3tiC9mzi bE0VEs/l34Y9J+MEwh7/gaXurLHDRiBB0/KqmXNLwYCas8TziLgY2VYSdiGERrwft9/k +mq3G8Cyih+cH5+dq/38cOgCeapFH74gCrrqAfPRZLUNP1RYaqvRDLPn6e8IiwDQEImH lbEjAuyRceTn2TG06MIsQ05/ZVnrH/459oRbhnpFiuXTXZSbLTzW7qWkx93cgZfCtLcg 1UZwOIB+QqyCFNYjEP3t85T4cKEYT3ilFRo/4d7EImDKLy3jF2+trO8D1mTkJbrcWO9K YE5A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p189si33846826pfb.0.2019.01.09.08.51.05; Wed, 09 Jan 2019 08:51:20 -0800 (PST) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726465AbfAIQtB (ORCPT + 99 others); Wed, 9 Jan 2019 11:49:01 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44098 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725785AbfAIQtB (ORCPT ); Wed, 9 Jan 2019 11:49:01 -0500 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EC6AD99C18; Wed, 9 Jan 2019 16:49:00 +0000 (UTC) Received: from kasong-desktop-nay-redhat-com.nay.redhat.com (unknown [10.66.128.41]) by smtp.corp.redhat.com (Postfix) with ESMTP id EF58D57AB; Wed, 9 Jan 2019 16:48:55 +0000 (UTC) From: Kairui Song To: linux-kernel@vger.kernel.org Cc: dhowells@redhat.com, dwmw2@infradead.org, jwboyer@fedoraproject.org, keyrings@vger.kernel.org, jmorris@namei.org, serge@hallyn.com, zohar@linux.ibm.com, bauerman@linux.ibm.com, ebiggers@google.com, nayna@linux.ibm.com, dyoung@redhat.com, linux-integrity@vger.kernel.org, kexec@lists.infradead.org, Kairui Song Subject: [RFC PATCH 0/2] let kexec_file_load use platform keyring to verify the kernel image Date: Thu, 10 Jan 2019 00:48:22 +0800 Message-Id: <20190109164824.19708-1-kasong@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Wed, 09 Jan 2019 16:49:01 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, This is a different approach for the previous patch: [RFC PATCH 0/1] KEYS, integrity: Link .platform keyring to .secondary_trusted_keys make kexec_file_load be able to verify the kernel image against keys provided by platform or firmware. This patch adds a .platform_trusted_keys in system_keyring as the reference to .platform keyring in integrity subsystem, when platform keyring is being initialized it will be updated. Another thing on my mind is that now kexec_file_load will still relay on CONFIG_INTEGRITY_PLATFORM_KEYRING and all its dependencies to be enabled to be able to verify the image against firmware keys. I'm thinking about to have something like CONFIG_PLATFORM_KEYRING and make the .platform keyring could be enabled for a more wider usage. Not sure if it's a good idea though. Tested in a VM with locally signed kernel with pesign and imported the cert to EFI's MokList variable. Kairui Song (2): integrity, KEYS: add a reference to platform keyring kexec, KEYS: Make use of platform keyring for signature verify arch/x86/kernel/kexec-bzimage64.c | 13 ++++++++++--- certs/system_keyring.c | 10 +++++++++- include/keys/system_keyring.h | 5 +++++ include/linux/verification.h | 1 + security/integrity/digsig.c | 4 ++++ 5 files changed, 29 insertions(+), 4 deletions(-) -- 2.20.1