> > 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 ? 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 ? Cheers, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
