[tpmdd-devel] [PATCH RESEND 3/3] tpm-chip: Export TPM device to user space even when startup failed

[Peter Huewe]

Thabks Michal!

Am 29. August 2017 15:17:39 MESZ schrieb "Michal Suchánek" <msuchanek at suse.de>:
>Hello,
>
>On Tue, 29 Aug 2017 15:55:09 +0300
>Jarkko Sakkinen <jarkko.sakkinen at linux.intel.com> wrote:
>
>> On Mon, Aug 28, 2017 at 05:15:58PM +0000,
>> Alexander.Steffen at infineon.com wrote:
>> > But is that just because nobody bothered to implement the necessary
>> > logic or for some other reason?  
>> 
>> We do not want user space to access broken hardware. It's a huge risk
>> for system stability and potentially could be used for evil purposes.
>> 
>> This is not going to mainline as it is not suitable for general
>> consumption. You must use a patched kernel if you want this.
>> 
>> /Jarkko
>> 
>
>It has been pointed out that userspace applications that use direct IO
>access exist for the purpose. So using a kernel driver is an
>improvement over that if the interface is otherwise sane.
+1

>
>What do you expect is the potential for instability or evil use?
>
>With a kernel driver arbitrating the bus access as it would in any
>other case I do not see much potential for instability. 

Exactly.
 

>If there are
>cases when the arbitration fails they can surely be more likely
>triggered in cases other than userspace sending arbitrary requests to a
>device which is in a state the kernel does not support but otherwise
>responsive.

Its the same as with every other device - as long as it communicates like a tpm, talks like a tpm, behaves like a tpm - it's a tpm. 
Even if the kernel does not recognize the tpm's internal state.


>If you really think that accessing a device that is in unsupported
>state at boot (as opposed to getting unto unsupported state during
>device operation after boot) is a real problem it can be selectable as
>compile time option so people who do not want the code do not get it.

I would more favor a module option, 
but honestly I don't see a reason to not pull this code in, as it is.
Maybe mark the kernel as tainted if you think it is an issue.

Adding this as a out of tree patch is far from userfriendly.
If there is a chance to debug and fix a "unknown" state using the kernel as the communication layer, I would like to use this way.


Peter

>
>Thanks
>
>Michal
>
>------------------------------------------------------------------------------
>Check out the vibrant tech community on one of the world's most
>engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>_______________________________________________
>tpmdd-devel mailing list
>tpmdd-devel at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

-- 
Sent from my mobile
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html