linux-kernel - Re: [Tee-dev] [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=NcrbujsM8wYJXq+s=o5Vy1xY1b0uKYBGvp6UP5ex70HrB2Q@mail.gmail.com>
Date:   Thu, 1 Aug 2019 11:30:05 +0300
From:   Janne Karhunen <janne.karhunen@...il.com>
To:     Sumit Garg <sumit.garg@...aro.org>
Cc:     Rouven Czerwinski <r.czerwinski@...gutronix.de>,
        "tee-dev @ lists . linaro . org" <tee-dev@...ts.linaro.org>,
        Daniel Thompson <daniel.thompson@...aro.org>,
        Jonathan Corbet <corbet@....net>, jejb@...ux.ibm.com,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Linux Doc Mailing List <linux-doc@...r.kernel.org>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        dhowells@...hat.com, linux-security-module@...r.kernel.org,
        keyrings@...r.kernel.org, Mimi Zohar <zohar@...ux.ibm.com>,
        Casey Schaufler <casey@...aufler-ca.com>,
        linux-integrity@...r.kernel.org,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        "Serge E. Hallyn" <serge@...lyn.com>
Subject: Re: [Tee-dev] [RFC v2 0/6] Introduce TEE based Trusted Keys support

On Thu, Aug 1, 2019 at 10:58 AM Sumit Garg <sumit.garg@...aro.org> wrote:

> > Anyway, just my .02c. I guess having any new support in the kernel for
> > new trust sources is good and improvement from the current state. I
> > can certainly make my stuff work with your setup as well, what ever
> > people think is the best.
>
> Yes your implementation can very well fit under trusted keys
> abstraction framework without creating a new keytype: "ext-trusted".

The fundamental problem with the 'standardized kernel tee' still
exists - it will never be generic in real life. Getting all this in
the kernel will solve your problem and sell this particular product,
but it is quite unlikely to help that many users. If the security is
truly important to you, would you really trust any of this code to
someone else? In this day and age, I really doubt many do. Everyone
does their own thing, so this is why I really see all that as a
userspace problem.


--
Janne