linux-kernel - Re: [RFC PATCH 2/2] tee: add OP-TEE 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <4984990.7rV4p0zMYU@wuerfel>
Date:	Sat, 18 Apr 2015 21:01:44 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	Javier González <javier@...igon.com>,
	Jens Wiklander <jens.wiklander@...aro.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
	Herbert Xu <herbert@...dor.apana.org.au>,
	tpmdd-devel@...ts.sourceforge.net,
	Valentin Manea <valentin.manea@...wei.com>,
	jean-michel.delorme@...com, emmanuel.michel@...com
Subject: Re: [RFC PATCH 2/2] tee: add OP-TEE driver

On Saturday 18 April 2015 20:49:03 Greg Kroah-Hartman wrote:
> On Sat, Apr 18, 2015 at 11:36:53AM +0200, Javier González wrote:
> > Hi,
> 
> A: No.
> Q: Should I include quotations after my reply?
> 
> http://daringfireball.net/2007/07/on_top
> 
> > We have discussed and implemented an in-kernel interface for the driver.
> > However, we need to agree on that interface with the kernel submodules that
> > can be interested in using it (e.g., IMA, keyring). We though it was easier
> > to have a framework in place before taking this space. This makes sense
> > since a TEE driver will be, as for today, mostly used by user space.
> > applications.
> 
> No, please provide a "real" solution, just providing a framework that no
> one uses means that I get to delete it from the kernel tree the next
> release, and I doubt you want that 
> 
> Please do all of the work here, as odds are, what you need in the end
> will be different from what you have proposed here.

I guess an alternative would be to remove all the unused infrastructure
code and only provide a user space interface for the features that
op_tee requires, but no optional user interfaces or in-kernel interfaces.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/