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=utf-8
Subject: Re: [PATCH v6 00/13] Enroll kernel keys thru MOK
From:   Eric Snowberg <eric.snowberg@oracle.com>
In-Reply-To: <20210916221416.onvqgz5iij3c7e6j@redhat.com>
Date:   Thu, 16 Sep 2021 19:58:48 -0600
Cc:     Jarkko Sakkinen <jarkko@kernel.org>, keyrings@vger.kernel.org,
        linux-integrity <linux-integrity@vger.kernel.org>,
        Mimi Zohar <zohar@linux.ibm.com>,
        David Howells <dhowells@redhat.com>,
        David Woodhouse <dwmw2@infradead.org>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        "David S . Miller" <davem@davemloft.net>,
        James Morris <jmorris@namei.org>,
        "Serge E . Hallyn" <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,
        "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DFCC5EFE-13A5-40C8-84AA-96877B2B7932@oracle.com>
References: <20210914211416.34096-1-eric.snowberg@oracle.com>
 <bee0ebc354a651ea5b263897f9b155dc604fa7c5.camel@kernel.org>
 <A02EE1DA-12BE-4998-ACE6-2D74FF380297@oracle.com>
 <f6e2e17cc6c8a3056cc066a7baa4d943eeb47c84.camel@kernel.org>
 <20210916221416.onvqgz5iij3c7e6j@redhat.com>
To:     Peter Jones <pjones@redhat.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Z2pNdUNIbjR5OVlqUGpTR01Ic2lpOWhaZHgrUkZXOVVKdnJIK0p2ZUFxc3Ir?=
 =?utf-8?B?YUpIZjVqSEV3YVdtUHVCZ2Z2SGZxYmJUNXlsamNpNzc2SkQyWGxNSUx2bk01?=
 =?utf-8?B?U2Z0VERISGZFQzZxMUw0R0g2L25yZjdOa0xqRUNvRE9IbTVtK3o4dWxmMFB1?=
 =?utf-8?B?Nkp4QkNlUTgzaGVYbDYzMHpvUDZuK0xEVlI4OHdNc0RJKzgwWThNL2xnNDJr?=
 =?utf-8?B?bzNKWndvZG1CV1NCcGhDMzdFbG9VSkxVTFpsQlJlYkZmcmlPUEQ4RGg5OUdZ?=
 =?utf-8?B?ekl5Uk1ROG9hM21aYVdoVncyalBJM20rcGtaUFJZdStkang5Vi9PejJBaEVM?=
 =?utf-8?B?aHVPQ3gvQnIyeDQ3YXlyN0VheW9TYVdORDB4TnlaVXprQjhpc1hyMWZiTUEr?=
 =?utf-8?B?YmZURGxxRUFZOFdXMUZudDhzQnZrSVhnSittNGFXUlVyNTVzemFhdWVIN2Va?=
 =?utf-8?B?M3BxWDNPRklDQnZwMkRVeVN5RlpGdEN3UElrSndKMVdFNlBmUWlwYXlPc3p5?=
 =?utf-8?B?V2VUWG85VjhyUFROWHVpYm91bThDcEQ2SnRkT1NhaDBIV1lnUUlHcmh4dlFs?=
 =?utf-8?B?cFdEUHJic3NxL1V4T3FTKzlRRDEwdVgxUkZaN2Zzc3M2RnVuZno1bHNyV0RG?=
 =?utf-8?B?YjIvQWd4Wnd2T2pZdldzN1grNFJZYXkwTFpUYkNBdmQxVVdYcTZaVlBXQ253?=
 =?utf-8?B?WEtkb0d6Yi91ZmpLNFMzb3E1MW9FMlo3NklvT0tZUURQelhZMGhpZUxKWlpF?=
 =?utf-8?B?VTlIQ3J6Z1lQTU5qeVdZUlJnRVBOc21NQTdlRXdWWCtxWmJIL1F2Zzc5RW9t?=
 =?utf-8?B?dmk4ckxzaVowb0NTSnl4UG5laklXZUZjaHN5ZnBUaVFIZGM0eFRxSTl4N05s?=
 =?utf-8?B?a3VlQitna3AwemtkTWJoRHE3cko3WUNHaDM2ZGwwUnN2R3IwSitPMUxFZDVW?=
 =?utf-8?B?c3MzcE5OSVltcVdFOFl3eG56N3BiOWxCeUM1Qm5iVUkvM3J3UHo0aXJWRVB6?=
 =?utf-8?B?dkhTeC8wV3Z4OFViQXhsdmRuOWQwY0M3LzJJcDBaWW5YMFlWY3JRYm1ZckRV?=
 =?utf-8?B?Q1dEbWVHV0ZiL29XVVlxdFVwQXpSMk83SzBTcGs3TjhTVjMxbVN4QWF1Z2ZH?=
 =?utf-8?B?V2tFUmpud0xINktkblZhSzlPRERWeDFkOFIreStHQ0JNZEN5NU1tQ3ZtWUov?=
 =?utf-8?B?MW15ZmhzTTZaaXRUODRzb1Bod2laemIvMkVrTllOTkw4dno0Skx6UHpHQ1dT?=
 =?utf-8?B?OGVNaEVQSWkzK0VyR1psZlRmR20xWWwreWF6YjNSSm1iZENqS0syM3h1ZWFz?=
 =?utf-8?B?anpsaGIvWTdvUGhZUjFTVVl5anFrb1d1aXl2anQxUmN0cTVLNkpldjBRcnUy?=
 =?utf-8?B?VUoxbnRISVhYUEFzOGpzM3BFclJPZ281ZnRDK3ZTRjc2OStMY2oxYjJkWXVn?=
 =?utf-8?B?aGsycGxHbnc3b0xTMWM0N0FIS0RLZEdoNUhrdUJUT0ZZazBqVmkzcm5IN2h0?=
 =?utf-8?B?QkE1SS9jTWd2OW9tSHdWRjd2VHJLcEdKbTFhK3IzSmJhTTV2aS9nQjFHMmtU?=
 =?utf-8?B?MFlTcXZjMG5sVkF3aHVtZFZXMGJUUm42MEhSVGY2dnRxKzhFb1NROVE5NkpC?=
 =?utf-8?B?bTI3dWNUdVhla1ZjU240LzBOd2dtTERCWEdTNmZFNmtwSnppYTBpQ1JTYjJN?=
 =?utf-8?B?SG5naXV2RzUrMkNwTDkrV2F6QW9qa0cxc2xaaEI5OG5oV0VJM3JlYjRVMVRx?=
 =?utf-8?B?VGd3TzQvRzdMemNjU3RVU0M2UmYrak1VbDNKSEl2Y1B3bUg5SW1kNndJbThx?=
 =?utf-8?Q?55eihdMZkVio2FF3N4+E/LVRvlRugAGSR03Kk=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4ebae946-156f-4395-5572-08d9797eb64f
X-MS-Exchange-CrossTenant-AuthSource: CH2PR10MB4150.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Sep 2021 01:58:58.2950
 (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: iGHD7NMEN22qNJ45d5jvsNj6HQJ547CoaRXbSDbpbcdzuszNQODCfgVVCwZJGd5jM/Kgjq0iXdlVqDDhSsTpDV14BeIcB7FTVJTca7JupjQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR10MB4844
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10109 signatures=668682
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 phishscore=0 malwarescore=0
 adultscore=0 mlxscore=0 mlxlogscore=999 suspectscore=0 bulkscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109030001
 definitions=main-2109170010
X-Proofpoint-GUID: K7G6aflYudMSNqEiKx5ft8RRboQoqJGg
X-Proofpoint-ORIG-GUID: K7G6aflYudMSNqEiKx5ft8RRboQoqJGg
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org


> On Sep 16, 2021, at 4:14 PM, Peter Jones <pjones@redhat.com> wrote:
>=20
> On Thu, Sep 16, 2021 at 06:15:50PM +0300, Jarkko Sakkinen wrote:
>> On Wed, 2021-09-15 at 15:28 -0600, Eric Snowberg wrote:
>>>> On Sep 15, 2021, at 11:57 AM, Jarkko Sakkinen <jarkko@kernel.org> wrot=
e:
>>>>=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 kern=
el,
>>>>> including the Secure Boot keys. Many distributions carry one of these=
=20
>>>>> rejected attempts [2], [3], [4]. This series tries to solve this prob=
lem=20
>>>>> with a solution that takes into account all the problems brought up i=
n=20
>>>>> the previous attempts.
>>>>>=20
>>>>> On UEFI based systems, this series introduces a new Linux kernel keyr=
ing=20
>>>>> containing the Machine Owner Keys (MOK) called machine. It also defin=
es
>>>>> a new MOK variable in shim. This variable allows the end-user to deci=
de=20
>>>>> if they want to load MOK keys into the machine keyring. Mimi has sugg=
ested=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 use=
s=20
>>>>> MOK variables to enable/disable signature validation as well as use/i=
gnore=20
>>>>> the db. Any kernel operation that uses either the builtin or secondar=
y=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 want=
ed=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 th=
e
>>>>> MOK key and enroll the MOK into the MOKList.  Afterwards the signed k=
ernel
>>>>> 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)?
>>>=20
>>> 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 necessa=
ry
>>> changes [2].
>>>=20
>>> [1] https://github.com/rhboot/shim
>>> [2] https://github.com/esnowberg/shim/tree/mokvars-v2
>>>=20
>>=20
>> So, my 2nd Q would be: which order these should be upstreamed?
>>=20
>> Linux patch set cannot depend on "yet to be upstreamed" things.
>>=20
>> Code changes look good enough to me.
>=20
> We can carry this support in shim before it's in kernel.  Eric's current
> patch for shim and mokutil looks mostly reasonable, though I see a few
> minor nits we'll have to sort out.

Thanks Peter.  Previously I had not sent it for a shim review since I wante=
d=20
to make sure this approach had a path forward.  I=E2=80=99ll work on submit=
ting the=20
shim changes for review now.