linux-kernel - Re: [tpmdd-devel] [PATCH 09/13] tpm: Pull everything related to sysfs into tpm-sysfs.c

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]

Date:	Mon, 30 Sep 2013 17:09:51 -0500
From:	Joel Schopp <jschopp@...ux.vnet.ibm.com>
To:	Daniel De Graaf <dgdegra@...ho.nsa.gov>,
	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
CC:	Leonidas Da Silva Barbosa <leosilva@...ux.vnet.ibm.com>,
	Rajiv Andrade <mail@...jiv.net>,
	tpmdd-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org,
	Sirrix AG <tpmdd@...rix.com>,
	Richard Maciel Costa <richardm@...ibm.com>,
	"trousers-tech@...ts.sourceforge.net" 
	<trousers-tech@...ts.sourceforge.net>
Subject: Re: [tpmdd-devel] [PATCH 09/13] tpm: Pull everything related to sysfs
 into tpm-sysfs.c

<snip>

> There is also the fact that the driver may not be able to tell if a
> locality is available without doing some kind of test command. The Xen
> TPM interface doesn't expose what localities are available, for example,
> and the TIS interface may need to test to see if locality 3 and 4 are
> actually blocked by the chipset - at least 3 might be available on some
> systems (the spec leaves this "implementation dependent").
> 
>>> Perhaps:
>>> 	default_locality - default to CONFIG_USER_DEFAULT_LOCALITY
>>> 		sysfs node permissions 0644
>>> 	kernel_locality - default to #CONFIG_KERNEL_DEFAULT_LOCALITY
>>> 		0444 if CONFIG_KERNEL_ONLY_LOCALITY=y
>>> 		0644 if CONFIG_KERNEL_ONLY_LOCALITY=n
>>> 	ioctl TPM_{GET,SET}_LOCALITY on an open /dev/tpmX
>>>
>>> If CONFIG_KERNEL_ONLY_LOCALITY=y, the userspace locality is not
>>> permitted to be equal to kernel_locality (but may take any other valid
>>> value).  Drivers may reject locality values that they consider invalid
>>> (the default should be to only allow 0-4, which is all that is defined
>>> in the spec) or may fail on attempted use of the TPM by passing down an
>>> error from the hardware - I would expect the latter to be the case on
>>> attempts to use locality 4 in the tpm_tis driver.
>>
>> Seems resonable, CONFIG_KERNEL_ONLY_LOCALITY could be
>> CONFIG_TPM_ONE_TIME_LOCALITY (eg you get to set kernel_locality only
>> once)
> 
> Hmm, how much trouble would it be to make this a menu selection? Even
> with the one-time-set option, you still need a default set either in
> the code or by CONFIG_ so that the TPM is not unavailable before the
> sysfs write. The options would be:
> 
>   - CONFIG_TPM_KERNEL_DEFAULT_LOCALITY = [int]
>   - CONFIG_TPM_KERNEL_LOCALITY_FIXED - no changes from userspace
>   - CONFIG_TPM_KERNEL_LOCALITY_ONESHOT - only one change possible
>   - CONFIG_TPM_KERNEL_LOCALITY_ANY - may be changed freely
> 
> The userspace locality is not allowed to use the kernel locality if
> the mode is either FIXED or ONESHOT, but may share locality if ANY
> is used.
> 
> Or, for more flexibility (I actually like this one better):
> 
>   - CONFIG_TPM_KERNEL_DEFAULT_LOCALITY = [int]
>   - CONFIG_TPM_KERNEL_LOCALITY_FIXED = [bool]

This seems best of the options discussed to me.

> 
> And sysfs contains:
>   - kernel_locality [0644, int; 0444 if FIXED=y or when locked(?)]
>   - lock_kernel_locality [write-once; only exists if FIXED=n]
> 
> Where kernel_locality may be changed until a write is made to
> local_kernel_locality, at which time the value of kernel_locality
> becomes read-only and no longer available via /dev/tpmX.
> 
>>> The only one I see immediately is seal/unseal (security/keys/trusted.c).
>>> The invocation of the seal command would need to be changed to seal the
>>> trusted keys to the kernel-only locality in order to take advantage of
>>> the increased protection provided by a kernel-only locality.
>>
>> Right
> 
> Actually, only the invocation needs to be changed - the PCR selection
> is passed in from userspace, which will just need to use PCR_INFO_LONG
> with the proper locality mask.
> 
>>>> Do you know anyone on the userspace SW side who could look at this?
>>
>>> I should be able to find someone.
>>
>> Okay, let me know. I'd like to get a few more clean ups done before
>> mucking with the sysfs, but the way forward for locality looks pretty
>> clear..
>>
>> Thanks,
>> Jason
> 
> So far, nobody I have talked to has offered any strong opinions on
> what locality should be used or how it should be set. I think finding
> a developer of trousers may be the most useful to talk about how the
> ioctl portion of this would need to be set up - if someone is actually
> needed.
> 

I am a TrouSerS developer and am ccing Richard, another TrouSerS
developer, and ccing the trousers-tech list.  It would be good if you
could elaborate on the question and context for those not following the
entire thread, myself included.

--
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/