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] [thread-next>] [day] [month] [year] [list]
Message-Id: <CVS3NIJ8OO6Y.2C6GJ9OBR6COC@suppilovahvero>
Date:   Mon, 25 Sep 2023 18:22:22 +0300
From:   "Jarkko Sakkinen" <jarkko@...nel.org>
To:     "David Gstir" <david@...ma-star.at>,
        "Mimi Zohar" <zohar@...ux.ibm.com>,
        "James Bottomley" <jejb@...ux.ibm.com>,
        "Herbert Xu" <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>
Cc:     "Shawn Guo" <shawnguo@...nel.org>,
        "Jonathan Corbet" <corbet@....net>,
        "Sascha Hauer" <s.hauer@...gutronix.de>,
        "Pengutronix Kernel Team" <kernel@...gutronix.de>,
        "Fabio Estevam" <festevam@...il.com>,
        "NXP Linux Team" <linux-imx@....com>,
        "Ahmad Fatoum" <a.fatoum@...gutronix.de>,
        "sigma star Kernel Team" <upstream+dcp@...ma-star.at>,
        "David Howells" <dhowells@...hat.com>,
        "Li Yang" <leoyang.li@....com>, "Paul Moore" <paul@...l-moore.com>,
        "James Morris" <jmorris@...ei.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        "Randy Dunlap" <rdunlap@...radead.org>,
        "Catalin Marinas" <catalin.marinas@....com>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        "Tejun Heo" <tj@...nel.org>,
        "Steven Rostedt (Google)" <rostedt@...dmis.org>,
        <linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-integrity@...r.kernel.org>, <keyrings@...r.kernel.org>,
        <linux-crypto@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linuxppc-dev@...ts.ozlabs.org>,
        <linux-security-module@...r.kernel.org>,
        "Richard Weinberger" <richard@....at>,
        "David Oberhollenzer" <david.oberhollenzer@...ma-star.at>
Subject: Re: [PATCH v3 1/3] crypto: mxs-dcp: Add support for hardware
 provided keys

On Mon Sep 18, 2023 at 5:18 PM EEST, David Gstir wrote:
> DCP is capable to performing AES with hardware-bound keys.
> These keys are not stored in main memory and are therefore not directly
> accessible by the operating system.
>
> So instead of feeding the key into DCP, we need to place a
> reference to such a key before initiating the crypto operation.
> Keys are referenced by a one byte identifiers.

Not sure what the action of feeding key into DCP even means if such
action does not exists.

What you probably would want to describe here is how keys get created
and how they are referenced by the kernel.

For the "use" part please try to avoid academic paper style long
expression starting with "we" pronomine.

So the above paragraph would normalize into "The keys inside DCP
are referenced by one byte identifier". Here of course would be
for the context nice to know what is this set of DCP keys. E.g.
are total 256 keys or some subset?

When using too much prose there can be surprsingly little digestable
information, thus this nitpicking.

> DCP supports 6 different keys: 4 slots in the secure memory area,
> a one time programmable key which can be burnt via on-chip fuses
> and an unique device key.
>
> Using these keys is restricted to in-kernel users that use them as building
> block for other crypto tools such as trusted keys. Allowing userspace
> (e.g. via AF_ALG) to use these keys to crypt or decrypt data is a security
> risk, because there is no access control mechanism.

Unless this patch has anything else than trusted keys this should not
be an open-ended sentence. You want to say roughly that DCP hardware
keys are implemented for the sake to implement trusted keys support,
and exactly and only that.

This description also lacks actions taken by the code changes below,
which is really the beef of any commit description.

BR, Jarkko

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ