[wishlist] [weird] TOCTOU safety / maybe use unordered atomic loads? about capnproto-rust HOT 7 CLOSED

Hi!

Thanks for giving me some interesting ideas to ponder. Hm... I think there are some fundamental issues with providing safe access to an mmapped buffer which might still be receiving writes from other processes. Note that if a Cap'n Proto message has a field of type Data, then it can be used to get a &[u8] slice view to part of the underlying buffer. If that underlying buffer can mutate, then the data underlying the &[u8] can mutate. In my understanding, that would violate important guarantees of Rust's typesystem. For instance, you could easily end up with a &str that pointed to non-UTF-8 data.

So I think that if you want to use mmap() in Rust, you need to assert to the typechecker, through some unsafe code, that the mapped buffer will not mutate. For example, in @danburkert's memmap crate the as_slice() method is unsafe, because when you call it, you are making this immutability assertion.

from capnproto-rust.

I suppose that an alternative might be to use mmap() buffers directly, without ever converting them into native Rust slices.

from capnproto-rust.

There is nothing Cap'n Proto can or should do to work around stray processes scribbling memory. @sorear I recommend using filesystem permissions or file locks to attempt to get exclusive access to the file.

from capnproto-rust.

@sorear leaving aside the data race issue, could you point out a TOCTOU violation in the code? My understanding was pointers were always validated when they are dereferenced in capnp.

from capnproto-rust.

@danburkert Not sure I understand the last one; the code is fine, if you have an immutable slice to work with. Now, I have a buffer which will not change during normal operation (I am using locks, but locks don't block disk failure). I can either unsafely convert the buffer to a slice (accepting a very small risk of segfaults if the buffer turns out to change), or copy the buffer.

I'm going to pick the former – this is not expected to be common, and copying to guard against it is flagrantly wasteful – but I'd rather not have to choose, and I had thought that a change to capnp-rust could solve that. Hence [wishlist] [weird].

That said, I'm less convinced of this now, because all of my hypothetical data corruption events could also hit the backing store of the text segment, and then there'd really be nothing capnp could do.

from capnproto-rust.

@sorear I thought you were more concerned with shared memory security rather than just corruption. It would be neat to be able to use capnp to communicate over shared memory, but I'm pretty sure optimizing for shared memory (over doing a memcpy) would involve deoptimizing for other uses.

from capnproto-rust.

Why couldn't capnp be used with shared memory?

from capnproto-rust.