linux-kernel - Re: [RFC, PATCH 1/1] rpmb: add Replay Protected Memory Block (RPMB) driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAFA6WYNzLj3ZGj0MP_8n-9ZsMrHs+nFyd11XTARTUXHv4gFs3Q@mail.gmail.com>
Date:   Thu, 24 Aug 2023 19:37:32 +0530
From:   Sumit Garg <sumit.garg@...aro.org>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Shyam Saini <shyamsaini@...ux.microsoft.com>,
        Ilias Apalodimas <ilias.apalodimas@...aro.org>,
        Jens Wiklander <jens.wiklander@...aro.org>,
        Jerome Forissier <jerome.forissier@...aro.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        linux-kernel@...r.kernel.org, linux-mmc@...r.kernel.org,
        op-tee@...ts.trustedfirmware.org, linux-scsi@...r.kernel.org,
        Alex Bennée <alex.bennee@...aro.org>,
        Tomas Winkler <tomas.winkler@...el.com>,
        Arnd Bergmann <arnd.bergmann@...aro.org>,
        Tyler Hicks <code@...icks.com>,
        "Srivatsa S . Bhat" <srivatsa@...il.mit.edu>,
        Paul Moore <paul@...l-moore.com>,
        Allen Pais <apais@...ux.microsoft.com>
Subject: Re: [RFC, PATCH 1/1] rpmb: add Replay Protected Memory Block (RPMB) driver

On Wed, 23 Aug 2023 at 13:34, Linus Walleij <linus.walleij@...aro.org> wrote:
>
> On Tue, Aug 22, 2023 at 9:07 PM Shyam Saini
> <shyamsaini@...ux.microsoft.com> wrote:
>
> > do we plan to disable access to RPMB devices, once we have this RPMB
> > driver in place. User space tools like mmc-utils/nvme/ufs utils
> > can still access RPMB and programme the key and should
> > RPMB driver deny access to RPMB ?
>
> We don't break userspace. Just not. This is not an option.
>
> The RPMB subsystem simply has to provide the rpmb character
> device the same way the MMC subsystem did, or provide an
> in-kernel backend to the MMC subsystem so that it can provide
> the same device. Whatever solution is best.
>
> No deprecation and deletion and breaking userspace. Ever.
>

Agree, that's the golden rule of thumb we follow in kernel
development. Also, we still need to allow cases where trusted
provisioning user-space tools can program OP-TEE RPMB key during
factory provisioning. And once that is provisioned, I don't think
there is much harm in still exposing the RPMB device to user-space
since it can't do anything malicious without access to OP-TEE RPMB
key.

-Sumit

> Yours,
> Linus Walleij