compio-driver is internally unsound

[George-Miao]

Currently we make all OpCodes !Unpin and Pin it onto heap with Key so that buffers submitted into kernel stays at where they are. However when operations are finished, we take the OpCodes out and return them back to user, and this violates Pin contract. What's more, some ops contains self referential pointers, and those pointers will become dangling when the op is returned, even though we're not accessing those (for now). This doesn't cause any runtime error but conceptually it is unsound and undefined behavior MAY happen in future.

[Berrysoft]

Yes. However, that's unavoidable. We use Pin because the OpCode stores the pointer to the buffer. We move the OpCode because we need to return the buffer to the user. If the buffer is !Unpin, we have to violate the Pin contract.

Other runtimes solve the problem by contraint the buffer to be !Unpin, but we implemented the buffer traits for arrays and ArrayVec for convenience.

[George-Miao]

@Berrysoft It's not just for buffers. We require ops to be able to self referential, and have stable addresses so that the kernel can reference them. One solution I can think of is to have two types, one for submitting (think of a builder) and one for running state, that can be converted freely from each other.

[Berrysoft]

Fair enough. Though it might be a big project.

[Berrysoft]

@George-Miao I'm considering a smaller change. Still two types. One for running and one for return.

[Berrysoft]

According to the document,

Pin is specifically targeted at allowing the implementation of safe interfaces around types which have some state during which they become “address-sensitive.” A value in such an “address-sensitive” state is not okay with being moved around at-will. Such a value must stay un-moved and valid during the address-sensitive portion of its lifespan because some interface is relying on those invariants to be true in order for its implementation to be sound.

I admit that there're some OpCodes are "address-sensitive" during being processed by the driver or kernel, but when they complete, they are not "address-sensitive". The self-referential pointers are not used anymore.

The only problem is that, according to the document,

...if an element of your type could have been pinned, you must treat Drop as implicitly taking self: Pin<&mut Self>.

I have tried the two-types solution, but failed. I would like to fallback to the solution that mark the requirements in the safety notes of OpCode: the type should not implement Drop, or if the author insists, the drop method should not access the address-sensitive portion.

An alternative suggestion: add a method clear_self_references to OpCode, and ensure that it'll be called before self being moved.