On Mon, Oct 05, 2015 at 01:36:18PM +0000, Fuchs, Andreas wrote: > > It's still unnecessary functionality and increases the kernel image size > > and every hack requires maintenance. It would probably end up needing > > compilation flag as there exists efforts like: > > > > https://tiny.wiki.kernel.org/ > > > > My simple and stupid solution does not *prevent* adding better > > synchronization. I would go with that and implement access broker > > properly and not for just one use case later on. > > Unfortunately, I'm not able to write up some code for this myself atm. > Other priorities unfortunately. > > I was just pointing out, that the proposed patch will not fit in with > the current approach in TSS2.0, before this user-facing kernel API is > set in stone and _corrected_ new syscalls need to be added later.
Why you would want new system calls? Do you know how hard it is to get new system calls accepted? It's usually nearly impossible to get new system calls in. You are going wrong direction there. I do not see why couldn't survive in TSS 2.0 implementation for a while without in-kernel access broker even if the world isn't perfect and improve from that when the support becomes available. I'm not frankly following your rationale here. On the other hand I see use for the kernel images without access broker in small embdedded devices. I CC'd to Will Arthur as he has been working with TSS 2.0 for along time just in case. > Also, the pseudo-code proposal should be a proper minimal access broker > that should solve most accesses to TPM transient objects down the road. > Session-brokering is a different beast of course. I don't mean to be rude but pseudo code doesn't matter much. We know what is required from an access broker in terms of TPM 2.0 commands and locking. Only working code matters at this point. I still don't see why you couldn't add access broker later on. The patch set does not make the API worse than it is right now. > Cheers, > Andreas /Jarkko -- 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/