[lkml]   [2017]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager

Am 10.01.2017 um 21:05 schrieb Jason Gunthorpe:
> On Tue, Jan 10, 2017 at 01:16:35AM +0200, Jarkko Sakkinen wrote:
>> On Wed, Jan 04, 2017 at 10:12:41AM -0600, Dr. Greg Wettstein wrote:
>>> The kernel needs a resource manager. Everyone needs to think VERY
>>> hard and VERY, VERY carefully about what gets put into the kernel. In
>>> making a decision, put the ABSOLUTE smallest amount of code into the
>>> kernel which allows various 'TPM2 personalities' to be implemented in
>>> userspace and functionally verified and protected by the physical
>>> instance. The emergence of commodity TEE's (SGX, should be in
>>> the back of everyone's mind as a factor in the roadmap.
>> Here's my cuts for the kernel:
>> - Kernel virtualizes handle areas. It's mechanical.
>> - Kernel does not virtualize bodies. It's not mechanical.
>> - At least the first version of the RM will not do other than session
>> isolation for sessions.
>> This keeps the core for RM inside the kernel small and tight.

You need to do virtualization inside bodies, because TPM2_FlushContext
carries it's handles inside the parameter body.
Yep, huge blunder in the TPM spec, but hey, time for quirks... ;-)

> I think this makes sense.
> In addition the kernel should only permit RM operations that are known
> to be 100% correct with the RM.
> I think you should stick with your original design basic design,
> except instead of using an ioctl to switch modes, use an ioctl to
> execute the operation:
> struct tpm_ioctl_operation {
> u16 mode; // == TPM1_RAW,TPM2_RAW,TPM1_RM,TPM2_RM
> u16 locality;
> u32 txlen;
> u32 rxlen;
> const void *txbuf;
> void *rxbuf;
> };

could we please get an ioctl, that switches the "mode" of the fd entirely.
I'd like to see the write()/read() support still intact.
All my current code uses main-loop based poll on the fd and I don't want
to be force to start using threads...


> The userspace broker would be expected to use a mixture of RM and RAW
> operations.
> Let's deal with the idea of another cdev some other day when someone
> can figure out a comprehensive way to do that securely for unpriv..
> Jason
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.
> _______________________________________________
> tpmdd-devel mailing list

 \ /
  Last update: 2017-01-11 11:02    [W:0.124 / U:0.540 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site