Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset=us-ascii
Subject: Re: [PATCH v6 00/13] Enroll kernel keys thru MOK
From:   Eric Snowberg <eric.snowberg@oracle.com>
In-Reply-To: <bee0ebc354a651ea5b263897f9b155dc604fa7c5.camel@kernel.org>
Date:   Wed, 15 Sep 2021 15:28:39 -0600
Cc:     keyrings@vger.kernel.org, linux-integrity@vger.kernel.org,
        zohar@linux.ibm.com, dhowells@redhat.com, dwmw2@infradead.org,
        herbert@gondor.apana.org.au, davem@davemloft.net,
        jmorris@namei.org, serge@hallyn.com, keescook@chromium.org,
        gregkh@linuxfoundation.org, torvalds@linux-foundation.org,
        scott.branden@broadcom.com, weiyongjun1@huawei.com,
        nayna@linux.ibm.com, ebiggers@google.com, ardb@kernel.org,
        nramas@linux.microsoft.com, lszubowi@redhat.com,
        linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
        linux-security-module@vger.kernel.org,
        James.Bottomley@HansenPartnership.com, pjones@redhat.com,
        "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A02EE1DA-12BE-4998-ACE6-2D74FF380297@oracle.com>
References: <20210914211416.34096-1-eric.snowberg@oracle.com>
 <bee0ebc354a651ea5b263897f9b155dc604fa7c5.camel@kernel.org>
To:     Jarkko Sakkinen <jarkko@kernel.org>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?S4bSIb3oQVDimH654MCzEzgD8FICX8LTz4xoZqmWPP8ETFAOLsJ4j/NInluk?=
 =?us-ascii?Q?LndJtcWa9PmDeB1wVQ2xV9VDpdy7oX91hy6D0Zq+OZrS9DNuN8wsd1bPPlhc?=
 =?us-ascii?Q?KThTGEEsmkPDTniYfh+nXZcXDP6KqF/qs/KtuQ+UStiIBHfBStzrYuvWSg6D?=
 =?us-ascii?Q?2NJi8+eN8y/YSk1mHbFGRWeYj+s0lgE+FONzvTNpItctxgs9gdXZLHpoibsw?=
 =?us-ascii?Q?5tSICDmU5hMD1kF+4372IMqTOKAjAgyHyMpRg52aUh1dwEXH2blH5h++ZgIM?=
 =?us-ascii?Q?621/6Vr7a9xly04PwTYu8O+VVy96FVz+E61ecqH4w0PalAcNUMa1uqelSFMl?=
 =?us-ascii?Q?RsrDrn/G8wE4TSLZBTB9b8FGgnKSe5cvtdYNkW3ZLYB6nLsNLPjM2jUlLJV2?=
 =?us-ascii?Q?WnlOaRJDgSN+PPcG7dJVXIxWPD6ixSvhePlSJAIjHEaay4KWusDIXoSl+yrW?=
 =?us-ascii?Q?1zUh9kc1M9KzXCMf93oNBxD8zMg8CjCaChV8QoeMnnHOBIis7LIqNb5pF4ZH?=
 =?us-ascii?Q?3zYMS/YKcknMvjcaSwG34l1k4TKB0gSLjXWbm/3no8hCrL4Y3KLs6Rtt8Gmo?=
 =?us-ascii?Q?el78JP+6DVXgY1EiP/SppBp3lLhkxUAq6BRd8PhmNzbTynY1Og5GoE9BeZMG?=
 =?us-ascii?Q?7doJwUw6lbe4w7C9pNyLU2xOC0BP2eYUQ5WGe7Gre2Mv4TwTP9WvLppWXwzS?=
 =?us-ascii?Q?MEPOoX15YZZm7w+xlJNoG0fcm4mWC1qUbtFyg/tyMpmanheANhYyD9EHzsGj?=
 =?us-ascii?Q?4CpHky75TSPdJk1+HKQcR7lxJvSNudappX5ej2xy9iG78W5oBh2J2VHub2SF?=
 =?us-ascii?Q?i47bljliY3aUG42ZOJsrPSSScIN7wVuPeg8JMVF6RcTAAsiU6dDTAlB5FskH?=
 =?us-ascii?Q?lKlUwWY1XfLlWnhfMiePPCilUIRjEEGYM5xfhZ4ziiy1CHrE9CEuTsSD9zaJ?=
 =?us-ascii?Q?v+WTurva92l2caEDUSsPw3zKrKuHuqkWFpAsYGVsxwcH05kKGtMlXrvWAQ3C?=
 =?us-ascii?Q?r7UxyM4Q5cstiuZrdSTJc0OzcmJMQTHuQlV/gV7NqFL+RF03lo4W/aUruJnK?=
 =?us-ascii?Q?8bX0wc+9Ln2QXlBtM3iINOBUtJJ85RAwl6uFgTrS+N9NE6IKwJf1lZ+YPIJ2?=
 =?us-ascii?Q?cCc3SWZVVLJRDqHDxwKeuvYy63Gn/cTYyHEo7KL+8ow7ls69/IRm+/sIm4qp?=
 =?us-ascii?Q?sEU3AJK0VY6cR6LCF9gzVMAzQhTUMWdrPQIULVYpDAyKeCYn/ojFs2h2PJW3?=
 =?us-ascii?Q?UuN1y5ygXdGCOg/Z1WRQ2zuxK2lPsCnvTgin4OkAUgPV+r7Xk8rGGUj1TDbK?=
 =?us-ascii?Q?waq2d9qzKC9K0hru81LTxZv9qmr9BGSFHWdr7fzRdLJAxA=3D=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3e85c1eb-a4b5-4e38-9cab-08d9788fcea0
X-MS-Exchange-CrossTenant-AuthSource: MN2PR10MB4157.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Sep 2021 21:28:49.5011
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: KLgdzxy7M5gIQTMJQIFVnV3XFQt6sj8QbVblvVCeQsguHzwd2k6bDZ+vnutQmdXkmTtlQhHtKmdzARWTtuDI12A1q5BqzMa+xi3m0Oyk6WU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR10MB5362
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10108 signatures=668682
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxscore=0
 mlxlogscore=999 adultscore=0 bulkscore=0 spamscore=0 phishscore=0
 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2109030001 definitions=main-2109150123
X-Proofpoint-GUID: TokkM_9nLXReEnly-k1dGbRS95gO7PQY
X-Proofpoint-ORIG-GUID: TokkM_9nLXReEnly-k1dGbRS95gO7PQY
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org


> On Sep 15, 2021, at 11:57 AM, Jarkko Sakkinen <jarkko@kernel.org> wrote:
>=20
> On Tue, 2021-09-14 at 17:14 -0400, Eric Snowberg wrote:
>> Back in 2013 Linus requested a feature to allow end-users to have the=20
>> ability "to add their own keys and sign modules they trust". This was
>> his *second* order outlined here [1]. There have been many attempts=20
>> over the years to solve this problem, all have been rejected.  Many=20
>> of the failed attempts loaded all preboot firmware keys into the kernel,
>> including the Secure Boot keys. Many distributions carry one of these=20
>> rejected attempts [2], [3], [4]. This series tries to solve this problem=
=20
>> with a solution that takes into account all the problems brought up in=20
>> the previous attempts.
>>=20
>> On UEFI based systems, this series introduces a new Linux kernel keyring=
=20
>> containing the Machine Owner Keys (MOK) called machine. It also defines
>> a new MOK variable in shim. This variable allows the end-user to decide=
=20
>> if they want to load MOK keys into the machine keyring. Mimi has suggest=
ed=20
>> that only CA keys contained within the MOK be loaded into the machine=20
>> keyring. All other certs will load into the platform keyring instead.
>>=20
>> By default, nothing changes; MOK keys are not loaded into the machine
>> keyring.  They are only loaded after the end-user makes the decision=20
>> themselves.  The end-user would set this through mokutil using a new=20
>> --trust-mok option [5]. This would work similar to how the kernel uses=20
>> MOK variables to enable/disable signature validation as well as use/igno=
re=20
>> the db. Any kernel operation that uses either the builtin or secondary=20
>> trusted keys as a trust source shall also reference the new machine=20
>> keyring as a trust source.
>>=20
>> Secure Boot keys will never be loaded into the machine keyring.  They
>> will always be loaded into the platform keyring.  If an end-user wanted=
=20
>> to load one, they would need to enroll it into the MOK.
>>=20
>> Steps required by the end user:
>>=20
>> Sign kernel module with user created key:
>> $ /usr/src/kernels/$(uname -r)/scripts/sign-file sha512 \
>>   machine_signing_key.priv machine_signing_key.x509 my_module.ko
>>=20
>> Import the key into the MOK
>> $ mokutil --import machine_signing_key.x509
>>=20
>> Setup the kernel to load MOK keys into the .machine keyring
>> $ mokutil --trust-mok
>>=20
>> Then reboot, the MokManager will load and ask if you want to trust the
>> MOK key and enroll the MOK into the MOKList.  Afterwards the signed kern=
el
>> module will load.
>>=20
>> I have included links to both the mokutil [5] and shim [6] changes I
>> have made to support this new functionality.
>=20
> How hard it is to self-compile shim and boot it with QEMU (I
> do not know even the GIT location of Shim)?

It is not hard, that is the setup I use for my testing.  Upstream shim=20
is located here [1].  Or you can use my repo which contains the necessary
changes [2].

[1] https://github.com/rhboot/shim
[2] https://github.com/esnowberg/shim/tree/mokvars-v2