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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3FD6DC433DB for ; Thu, 11 Mar 2021 21:09:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F016464F85 for ; Thu, 11 Mar 2021 21:08:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230445AbhCKVIk (ORCPT ); Thu, 11 Mar 2021 16:08:40 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60938 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230417AbhCKVIK (ORCPT ); Thu, 11 Mar 2021 16:08:10 -0500 Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E2349C061761 for ; Thu, 11 Mar 2021 13:08:09 -0800 (PST) Received: by mail-ed1-x52d.google.com with SMTP id bf3so4914132edb.6 for ; Thu, 11 Mar 2021 13:08:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version:content-transfer-encoding; bh=WprC7wQ8pjk4v3rRNQRsNnfM+sFohsfztPY3hS+tZkY=; b=dqHaE7uAtCtfTturKUgGaMRMcA5A6xT5Sf8lWsZrZvnIOXfijL+712llEvyyGGggiF wBWpjvliIAbOJwKVKtia5E8gK+FEXGp883lN5XdlpTcUthISPjGAzEDaQzMjNHqIAyOS gQxFTfquWRQsSAYvti2QLI1048+HoB/47fTF6sUFrKPoXb2cwjYenOd15JYOR4ifTgKP Y/aP63Q2Vv9xef4NdGHljiTVumdtsFEIsGT/+DcDiRDvrywW83Y9ZV/VMTxOfTmODQul 6JA203LPm32+ADaE3s3VxsP3fZrJNfIzDdNhjPisiCu+P05s6e6Z3rOo4A6pucodFt3d MOWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject:date :in-reply-to:message-id:mime-version:content-transfer-encoding; bh=WprC7wQ8pjk4v3rRNQRsNnfM+sFohsfztPY3hS+tZkY=; b=ghApHHMJ3Mc5HYU4adpWIwVy52ghQ+DshoS1eoejxAw4wTfCD5S756i5lV149W/ZZ1 u3Yjd0aexJpHb8OCTad0I8dWBqhMoqxSmPpAp7WlryGR3trd8oW0HFNvmuD0cBkiGIB4 U2jobumJsbU7xOZpU6diZjI4vsaPv2Kj2a1jOwdp/FeT/x7RUcgpQG519NZ96dJ+0kGq eSTUf2h7A+mFpaeJciRLjjj22NIzLoS9QAxZ898J6sZoOepynB3Ieboouxw14Y4HrL3/ LncxWk7/9Fv07b1kwHW8m+0vr4O+wgcChDOeG62wwYhIcY8JgmBHs5UAla0SDSxHS1YD AAZA== X-Gm-Message-State: AOAM530S/NBxOWtU5qloVG4oJpId/J4Uv8Slqz4CrOZ873YilKcdRhlH 4/AOV97G9u0yQmOGs2rdCNnHEA== X-Google-Smtp-Source: ABdhPJwAmSWpyfZATg+lLALZWFEJgeSck6q627M8RqFqEoi+++wgypQpRJHtQ7KuVGQHjPuTtFTqTQ== X-Received: by 2002:a05:6402:3075:: with SMTP id bs21mr10586641edb.274.1615496888399; Thu, 11 Mar 2021 13:08:08 -0800 (PST) Received: from zen.linaroharston ([51.148.130.216]) by smtp.gmail.com with ESMTPSA id r17sm1875032ejz.109.2021.03.11.13.08.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Mar 2021 13:08:07 -0800 (PST) Received: from zen (localhost [127.0.0.1]) by zen.linaroharston (Postfix) with ESMTP id 85CC91FF7E; Thu, 11 Mar 2021 21:08:06 +0000 (GMT) References: <20210303135500.24673-1-alex.bennee@linaro.org> <20210303135500.24673-2-alex.bennee@linaro.org> <20210305075131.GA15940@goby> <6c542548-cc16-af68-c755-df52bd13b209@marcan.st> <02d035ca-697d-1634-a434-a43b9c01f4a9@marcan.st> User-agent: mu4e 1.5.8; emacs 28.0.50 From: Alex =?utf-8?Q?Benn=C3=A9e?= To: Hector Martin Cc: Linus Walleij , Sumit Garg , Arnd Bergmann , "open list:ASYMMETRIC KEYS" , David Howells , Jarkko Sakkinen , Joakim Bech , "linux-kernel@vger.kernel.org" , Maxim Uvarov , Ilias Apalodimas , Ruchika Gupta , "Winkler, Tomas" , yang.huang@intel.com, bing.zhu@intel.com, Matti.Moell@opensynergy.com, hmo@opensynergy.com, linux-mmc , linux-scsi , Ulf Hansson , Arnd Bergmann Subject: Re: [RFC PATCH 1/5] rpmb: add Replay Protected Memory Block (RPMB) subsystem Date: Thu, 11 Mar 2021 20:57:50 +0000 In-reply-to: <02d035ca-697d-1634-a434-a43b9c01f4a9@marcan.st> Message-ID: <87k0qd7615.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org Hector Martin writes: > On 11/03/2021 23.31, Linus Walleij wrote: >> I understand your argument, is your position such that the nature >> of the hardware is such that community should leave this hardware >> alone and not try to make use of RPMB for say ordinary (self-installed) >> Linux distributions? > > It's not really that the community should leave this hardware alone, so=20 > much that I think there is a very small subset of users who will be able= =20 > to benefit from it, and that subset will be happy with a usable=20 > kernel/userspace interface and some userspace tooling for this purpose,=20 > including provisioning and such. > > Consider the prerequisites for using RPMB usefully here: > > * You need (user-controlled) secureboot > * You need secret key storage - so either some kind of CPU-fused key, or= =20 > one protected by a TPM paired with the secureboot (key sealed to PCR=20 > values and such) > * But if you have a TPM, that can handle secure counters for you already= =20 > AIUI, so you don't need RPMB > * So this means you must be running a non-TPM secureboot system > > And so we're back to embedded platforms like Android phones and other=20 > SoC stuff... user-controlled secureboot is already somewhat rare here,=20 > and even rarer are the cases where the user controls the whole chain=20 > including the TEE if any (otherwise it'll be using RPMB already); this=20 > pretty much excludes all production Android phones except for a few=20 > designed as completely open systems; we're left with those and a subset=20 > of dev boards (e.g. the Jetson TX1 I did fuse experiments on). In the=20 > end, those systems will probably end up with fairly bespoke set-ups for=20 > any given device or SoC family, for using RPMB. > > But then again, if you have a full secureboot system where you control=20 > the TEE level, wouldn't you want to put the RPMB shenanigans there and=20 > get some semblance of secure TPM/keystore/attempt throttling=20 > functionality that is robust against Linux exploits and has a smaller=20 > attack surface? Systems without EL3 are rare (Apple M1 :-)) so it makes=20 > more sense to do this on those that do have it. If you're paranoid=20 > enough to be getting into building your own secure system with=20 > anti-rollback for retry counters, you should be heading in that directly= =20 > anyway. > > And now Linux's RPMB code is useless because you're running the stack in= =20 > the secure monitor instead :-) Well quiet - the principle use-case of virtio-rpmb is to provide a RPMB like device emulation for things like OPTEE when running under QEMU's full-system emulation. However when it came to testing it out I went for Thomas' patches because that was the only virtio FE implementation available. When I finished the implementation and Ilias started on the uBoot front-end for virtio-rpmb. uBoot being firmware could very well be running in the secure world so would have a valid use case accessing an RPMB device. We ran into API dissonance because uboot's driver model is roughly modelled on the kernel so expects to be talking to eMMC devices which lead to requirements to fake something up to keep the driver stacks happy. I guess what we are saying is that real secure monitors should come up with their own common API for interfacing with RPMB devices without looking to the Linux kernel for inspiration? --=20 Alex Benn=C3=A9e