On Wed Sep 27, 2023 at 9:25 AM EEST, David Gstir wrote: > Jarkko, > > > On 25.09.2023, at 17:22, Jarkko Sakkinen <jar...@kernel.org> wrote: > > > > 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. > > Thanks for reviewing that in detail! I’ll rephrase the commit > messages on all patches to get rid of the academic paper style. > > > > > >> 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. > > You’re right. I’ll add that.
Yup, I'm just doing my part of the job, as I'm expected to do it :-) Thanks for understanding. > Thanks, > - David BR, Jarkko
