Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1875119pxb; Mon, 8 Mar 2021 08:24:31 -0800 (PST) X-Google-Smtp-Source: ABdhPJxyMRb+mH9B83s9VYvr0rXj3EJv3VB7d7XuL6HirxLyyUVZnpWx8LLhHblXpYMD/t7xoTA8 X-Received: by 2002:a17:906:948d:: with SMTP id t13mr15299314ejx.402.1615220670793; Mon, 08 Mar 2021 08:24:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615220670; cv=none; d=google.com; s=arc-20160816; b=hrgF2/gVI9ouuoGxO9L8K5OeoXA3QntKuuWqCpVOUqBMLXspmwv7GAyeFUyoClem0W mTUfwrk+DDoFCBXCU6IXW5cyYmHhXQ70sdFyARDDB5vOM+FR9msYHTP1s869LxUcH4c/ 6jiq+Z2AwU5dvD2rvrHyw8ZJaVBhYpXMwHds8edVOij/py3pQXYPjhJ+Ud7RXw4h8l4q yS/Pu3daJZbaYXJouBr8bqKdAd6WeN+FtHu+oCO4o1etObBnE7rrYeOi4zrLY+GolF2/ nF6CaKuIkBbllInPxPUS13E0F3irJYFEh3vb+QecAFElYA1Nd4lLdlNoGf3SALO8whf0 pS5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=mq5t5EXYTkjP+ybGzyx3+G3Vm4kxVCqgAzqjpUIRzNM=; b=kxrlUa/y2fyvxpBg5RPakN4HFHto7EDwovTQCQfGml1RLqIb/1rLFpRmTiGIGO9Azg TwYS02t25R+hy2/9Z84SsMLGH6595ji+EMTM++/khM4CX9bmY+YKWUdrwbYmGgCecvSt +dVD1wLDheNq1zLnmT86AKObf25BwNdd5ZdGCHbF9n/MnzbjrgEa+fUe4hnr7Cj+VMjd +2WrpNumiAzntCD3ub1tq7qRnq/Of4SOfb0MGGsdPxNiTcqVpuF71Q9ALl1nuliKQeHT 7FOFDgl9eWhVZK3USw8/F3/pGM2gN+jXV0hrckiit5Ecjegn8VbeG6FL3Zqui3aMgqQ+ zesw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=b+h+112y; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a8si7468604edq.601.2021.03.08.08.24.04; Mon, 08 Mar 2021 08:24:30 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=b+h+112y; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229463AbhCHQUY (ORCPT + 99 others); Mon, 8 Mar 2021 11:20:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52848 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229757AbhCHQUV (ORCPT ); Mon, 8 Mar 2021 11:20:21 -0500 Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 58236C06175F for ; Mon, 8 Mar 2021 08:20:21 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id e7so21956289lft.2 for ; Mon, 08 Mar 2021 08:20:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mq5t5EXYTkjP+ybGzyx3+G3Vm4kxVCqgAzqjpUIRzNM=; b=b+h+112y3ebiz95oGha/nSHDUyV4qWqLbh7s6HWXqpchc/KQ6l9+lY9uMVVoe2jacZ +6AGyh3Tyx9X9sN/HgSye3HXdYOxEbRa6fBqDY5mD6QEGq0gwpEhSMUW8wsgzIJiboO2 Nfc5c+q6gYUTSNdqZGlFablRt4ma1wiCHwiruWqcpj1Ie9eKyrwiRa6TE4GSQlUYOSC4 BFZ8auSPNqAHtgknYX4ZaZHhpWe0Vk/tv5G6uWoEBGqb5UF8aQ2svCv7zlrXkNowHpKV rirSDxOMW8QXt1hefFpX98AxtMOTDHy9WDfbNiCkBUpZ/GCke2KlcoBO8Bice77rNA+j z5DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mq5t5EXYTkjP+ybGzyx3+G3Vm4kxVCqgAzqjpUIRzNM=; b=G81XU/AU1EHsTfHFa8jbIRKq7IHrPz3fOkkd6lt77vHrGP7IjSgxFU4QgpS2K6gOtd b3ASVBi5h6/m7Jphqma7OmdDXPaGtvuVtOjgb7mWIw2082QQy02jNcS5ZIsmeZDV7SsU ImDJDrQRsiDAvRHIei1irXEzZw3eERINfeBI4yJyTeX5ybtQeb8OzYcoAu3aGHjXhw8L CthBJyEpXHnh6o2Wmz/S6bSaAQheKNi5CbmoK7MRKg4Fj5NN5rb9egh2gCNly13QS2r1 ty82kkTOg+7naMUAz/XyFFgJRfAy+nsA82Ju9DvxXZoILcdtPBqSjwla2Z6cCQ1CbkQQ 0xcA== X-Gm-Message-State: AOAM5318GE2qPikbF4LyNN3Ij+2eA2RZx0huVsCa76pCucdU6+XqGAX8 5UEDKHV8G7MdK3JifsLvfPDMNPs4gGeY4pes0cFVNg== X-Received: by 2002:a05:6512:10d1:: with SMTP id k17mr14325798lfg.649.1615220419656; Mon, 08 Mar 2021 08:20:19 -0800 (PST) MIME-Version: 1.0 References: <20210303135500.24673-1-alex.bennee@linaro.org> <20210303135500.24673-2-alex.bennee@linaro.org> <20210305075131.GA15940@goby> In-Reply-To: From: Linus Walleij Date: Mon, 8 Mar 2021 17:20:08 +0100 Message-ID: Subject: Re: [RFC PATCH 1/5] rpmb: add Replay Protected Memory Block (RPMB) subsystem To: Arnd Bergmann , keyrings@vger.kernel.org, David Howells , Jarkko Sakkinen Cc: Joakim Bech , =?UTF-8?B?QWxleCBCZW5uw6ll?= , "linux-kernel@vger.kernel.org" , Maxim Uvarov , Ilias Apalodimas , ruchika.gupta@linaro.org, "Winkler, Tomas" , yang.huang@intel.com, bing.zhu@intel.com, Matti.Moell@opensynergy.com, hmo@opensynergy.com, linux-mmc , linux-scsi , linux-nvme@vger.kernel.org, Ulf Hansson , Arnd Bergmann , Hector Martin Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 5, 2021 at 9:44 AM Arnd Bergmann wrote: > I think the scenario for the 'nvme-rpmb' tool that does the signing in user > space does not involve any TEE at the moment, because PCs usually > don't have one. Isn't that because (Windows-)PC:s prefer to use TPMs which include their own key storage? Apple has their "secure enclave" (separate security chip) and as illustrated by Marcan it did not make use of RPMB as of 2016: https://marcan.st/2016/03/untangling-ios-pin-code-security/ Maybe they have since started to use it? (They should.) AFAICT the use case for RPMB is: 1. Used by Android with some TEE, and if you're not running Android and some TEE then 2. Use it for whatever you like As it seems neither Microsoft nor Apple is paying it much attention (+/- new facts) it will be up to the community to define use cases for RPMB. I don't know what would make most sense, but the kernel keyring seems to make a bit of sense as it is a well maintained keyring project. So the proposal is to (as some goal) bridge the keyring subsystem to the proposed RPMB subsystem with an kernel-internal API. What do the keyring people think of this? Added David & Jarkko to the thread to get some input. I suppose it would be a bit brutal if the kernel would just go in and appropriate any empty RPMB it finds, but I suspect it is the right way to make use of this facility given that so many of them are just sitting there unused. Noone will run $CUSTOM_UTILITY any more than they run the current RPMB tools in mmc-tools. Agreeing with OP-TEE on the format and management of any one RPMB partition seems like a good idea, if for nothing else then for sharing documentation. > I agree that sharing the RPMB is not a great idea, so if you have a TEE > in the system that requires an RPMB for storage, it won't be usable by > anything else. However, you can have multiple RPMB partitions with separate > keys on an NVMe drive, and you can easily have multiple emulated > virtio-rpmb devices in a guest and use them for purposes other than the > TEE. The eMMC RPMB code even handles multiple RPMB partitions on an eMMC. But I don't think I have ever seen a device with more than one RPMB. Yours, Linus Walleij