Re: [tpmdd-devel] [PATCH 4/4] keys, trusted: seal/unseal with TPM 2.0 chips

[Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>]

On Tue, Oct 06, 2015 at 01:16:02PM +0000, Fuchs, Andreas wrote:
> > > I was just trying to point out that the concept is not too difficult, since
> > > kernel-space (minimal) resource-manager makes a lot of people go "oh god,
> > > never ever, way too big, way too complicated", which IMHO it is not.
> > > Until then, I think that the call should just return -EBUSY when you cannot
> > > load the sealed data if no slots are available ?
> > 
> > Well this is kind of argument where there is no argument. I already had
> > plans how to do access broker back in 2014 that are more or less along
> > the lines of the pseudo code you sent. The problem is the lack of active
> > maintainers in the subsystem. That's why I get easily frustated
> > discussing about access broker in the first place :)
> > 
> > I would have implemented access broker months and months ago if I didn't
> > have so much code in the queue for this subsystem. There can be literally
> > months delay without any feedback. Right now I have four different
> > patches or patch sets in the queue:
> > 
> > - PPI support (yes you cannot enable TPM chips at the moment from Linux)
> > - Two bug fixes (CRB command buffer alignment, dTPM2 ACPI hot plugging)
> > - Basic trusted keys
> > 
> > I wouldn't blame any particular person about the situation but things
> > cannot continue like this. I've been thinking if I could acquire
> > co-maintainership of the subsystem for TPM 2 parts (don't really have
> > time or expertise for TPM 1.x parts).
> 
> I think I know this situation. You have all my sympathies... ;-)
> 
> > I could post my architecture (never really written it except in my head
> > but should not take too long time) to my blog at jsakkine.blogspot.com
> > if you are interested discussing more.
> 
> Well, I came in to tpmdd-devel rather recently and only with a small time budget
> to spend, but I'd be highly interested to learn about your thoughts.
> 
> As you can tell, I've been involved on the userspace side of things and
> therefore already bent my head around some different architectures for
> different scenarios. Also your input might help us in the specification of
> userspace side as well.
> 
> So please go ahead and write it up, if you can spare the time.
> Or let's get on the phone some time.
> 
> > > I looked at Patch 3/4 and it seems you default to -EPERM on TPM2_Create()-
> > > and TPM2_Load()-failures ?
> > > You might want to test against rc == TPM_RC_OBJECT_MEMORY and return -EBUSY
> > > in those cases. Would you agree ?
> > > (P.S. I can cross-post there if that's prefered ?)
> > 
> > Have to check the return values. I posted this patch set already in
> > early July. You are the first reviewer in three months for this patch
> > set.
> > 
> > I think the reason was that for TPM 1.x returned -EPERM in all error
> > scenarios and I didn't want to endanger behaviour of command-line tools
> > such as 'keyctl'. I would keep it that way unless you can guarantee that
> > command-line tools will continue work correctly if I change it to
> > -EBUSY.
> > 
> > Anyway, I will recheck this part of the patch set but likely are not
> > going to do any changes because I don't want to break the user space.
> > 
> > I will consider revising the patch set with keyhandle required as an
> > explicit option.
> 
> Hmm... Will the old keyctl work without modification with the 2.0 patches
> anyways ?

Yes it does and it should. I've been using keyctl utility to test my
patch set.

> The different keyHandle values and missing default keyHandle will yield
> "differences" anyways, I'd say.
> IMHO, we should get it as correct as possible given that TPM 2.0 is still
> very young.
> 
> Is adding "additional" ReturnCodes considered ABI-incompatible breaking
> anyways ?

Yes they are if they make the user space utiltiy malfunction.

> Cheers,
> Andreas

/Jarkko