linux-kernel - Re: [RFC v2 0/6] Introduce TEE based Trusted Keys support

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: <CAE=Ncrb23q++z8R8UMbjDE2epEq4YVcNGzrRD31eH3JAooYejg@mail.gmail.com>
Date:   Wed, 31 Jul 2019 14:02:53 +0300
From:   Janne Karhunen <janne.karhunen@...il.com>
To:     Sumit Garg <sumit.garg@...aro.org>
Cc:     keyrings@...r.kernel.org, linux-integrity@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        Jens Wiklander <jens.wiklander@...aro.org>,
        Jonathan Corbet <corbet@....net>, dhowells@...hat.com,
        jejb@...ux.ibm.com,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        Mimi Zohar <zohar@...ux.ibm.com>,
        James Morris <jmorris@...ei.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Casey Schaufler <casey@...aufler-ca.com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Daniel Thompson <daniel.thompson@...aro.org>,
        Linux Doc Mailing List <linux-doc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        "tee-dev @ lists . linaro . org" <tee-dev@...ts.linaro.org>
Subject: Re: [RFC v2 0/6] Introduce TEE based Trusted Keys support

On Wed, Jul 31, 2019 at 1:26 PM Sumit Garg <sumit.garg@...aro.org> wrote:

> > Interesting, I wrote something similar and posted it to the lists a while back:
> > https://github.com/jkrh/linux/commit/d77ea03afedcb5fd42234cd834da8f8a0809f6a6
> >
> > Since there are no generic 'TEEs' available,
>
> There is already a generic TEE interface driver available in kernel.
> Have a look here: "Documentation/tee.txt".

I guess my wording was wrong, tried to say that physical TEEs in the
wild vary massively hardware wise. Generalizing these things is rough.


> > I implemented the same
> > thing as a generic protocol translator. The shared memory binding for
> > instance already assumes fair amount about the TEE and how that is
> > physically present in the system. Besides, the help from usage of shm
> > is pretty limited due to the size of the keydata.
> >
>
> If you look at patch #1 and #2, they add support to register kernel
> memory buffer (keydata buffer in this case) with TEE to operate on. So
> there isn't any limitation due to the size of the keydata.

Ah, didn't mean that. Meant that the keydata is typically pretty small
in size, so there is limited benefit from passing that in via shm if
that complicates anything.


-- 
Janne