W. Trevor King

> Is this needed at the runtime level because of interactions with the tmp and user namespaces? Is there a `tpm` namespace? I agree that handing this outside of the...

On Mon, Sep 11, 2017 at 09:20:57PM +0000, Stefan Berger wrote: > So in the case of vTPM we may not just have kernel parameters but > also emulator parameters...

> What do we gain by making the runtime a middleman between the emulator and the runtime-caller? As an example of this in another context, making the runtime a middleman...

> … if we take the runtime, which I suppose you are referring to is represented by this code base here, out, does that mean we wouldn't have anything vTPM...

> If we express a vTPM instance as shown above with a device on the level of the runtime-spec, then how do we represent it at the level of runc...

> Who is the 'caller' in this case? The runtime-caller (e.g., see the steps I floated [here][1]). > Do you want to support vTPM on the runc level or push...

> I extended RunC with vTPM. When running RunC with vTPM support in Docker-CE one surprise was that when running 'docker restart' the vTPM state path was deleted and thus...

On Thu, Dec 08, 2016 at 11:57:08AM -0800, Jonathan Boulle wrote: > Honestly I'd like to see this in the spec itself (of course always > as optional guidelines, never...

On Tue, Dec 20, 2016 at 01:31:56PM -0800, Stephen Day wrote: > The main issue, as I have explained to @lizrice on many occasions, > is that multiple things that...

> * `valueTwo` could be `REQUIRED` for this `op`, it would require using a pointer in the Golang struct. > * Or, the spec could mention that `valueTwo` defaults to...