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 -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html