lkml.org 
[lkml]   [2013]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [tpmdd-devel] [PATCH 09/13] tpm: Pull everything related to sysfs into tpm-sysfs.c
On Mon, Sep 23, 2013 at 06:00:46PM -0400, Daniel De Graaf wrote:

> In a PC client TPM, normal OS code (as opposed to firmware or microcode)
> is already restricted to locality 0-2. It may make sense to restrict
> locality 2 to the kernel, which would allow an in-kernel TPM seal
> command to be able to bind data so that userspace cannot unseal it.
> However, only allowing localities 0 and 1 to userspace may be too
> restrictive if userspace also wishes to use locality for separation,
> since locality 1 does not have the ability to reset any PCRs that
> locality 0 cannot also reset.
> The kernel could reserve only locality 1 for its own use, giving it the
> ability to seal data but not interfering with the ability to reset PCRs.
> This would be my preference, although it is less intuitive to allow code
> of lower privilege (userspace) to control the higher numbered locality
> 2.

This matches my vague understanding (we don't use localities here)

>> Perhaps a .config option would be useful to allow the system designer to
>> choose what, if any, locality to reserve for kernel use?

A runtime sysfs seems reasonable..

Would:
user_default_locality
kernel_default_locality
user_allowed_localities (bitmask)
supported_localities (bitmask)
a GET_LOCALITY/SET_LOCALITY IOCTL to change localities of an open'd
/dev/tpmX

Do the job?

At first glance anyhow. I wonder what in-kernel users would be
impacted by localities..

Any thoughts on root vs not-root? Would middelware want to use
localities?

Do you know anyone on the userspace SW side who could look at this?

Jason


\
 
 \ /
  Last update: 2013-09-24 00:41    [W:0.132 / U:8.440 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site