Stream: wasmtime

Topic: wiggly strings


view this post on Zulip Dan Gohman (Mar 25 2020 at 13:44):

Is it a deliberate decision to pass functions like path_open a GuestPtr<'_, str> rather than resolving that to a &str in the wrapper?

view this post on Zulip Jakub Konka (Mar 25 2020 at 13:50):

Currently yes, since obtaining &str is unsafe and requires manually tracking borrows. That's why whenever you want to obtain a &str, you'required to invoke

let mut bc = GuestBorrows::new();
unsafe { &*ptr.as_raw(&mut bc) }

This way we're trying to avoid any overlapping borrows that may occur.

view this post on Zulip Jakub Konka (Mar 25 2020 at 13:51):

Now, I'm not sure how valid or difficult it would be to push the resolution to the layer above the trait method such as path_open

view this post on Zulip Jakub Konka (Mar 25 2020 at 13:52):

I'm worried it might become quite tricky to properly track borrows then, although in case of strings, they are meant to be immutable (for now at least) and we create a new borrow checker instance per each resolution of &str

view this post on Zulip Dan Gohman (Mar 25 2020 at 13:54):

Would it help if we could assume that no witx API will have aliasing of any mutable references?

view this post on Zulip Jakub Konka (Mar 25 2020 at 13:55):

It probably would in part, but what about reentrancy e.g., recursive calls, etc?

view this post on Zulip Dan Gohman (Mar 25 2020 at 13:56):

Ah, interesting. So nothing in WASI currently is recursive, but in the general case, witx APIs could be.

view this post on Zulip Jakub Konka (Mar 25 2020 at 13:58):

Yep, that was the motivating factor behind the current design.

view this post on Zulip Dan Gohman (Mar 25 2020 at 14:01):

Hmm, but even with recursive functions, how could you get aliasing between a mutable buffer and another pointer in the same scope?

view this post on Zulip Jakub Konka (Mar 25 2020 at 14:08):

Hmm, so assuming you could get &str to some region in guest's memory, and then from WASI's host function you'd want to call back in guest's memory again, that would potentially require some intricate mechanism for tracking borrows, wouldn't it? At least that's how I understood it when chatting with @Alex Crichton about it.

view this post on Zulip Alex Crichton (Mar 25 2020 at 14:09):

yes this is protections in general against bugs in wasmtime

view this post on Zulip Alex Crichton (Mar 25 2020 at 14:10):

even without recursion once you have &str you can't modify the contents, but using the APIs of Memory it's very easy to modify the contents with an accidentally aliasing guest mutable pointer

view this post on Zulip Alex Crichton (Mar 25 2020 at 14:10):

acquisition of &str is a pretty unsafe operation (basically just runs into these examples)

view this post on Zulip Jakub Konka (Mar 25 2020 at 14:19):

We could however copy out the contents of that region into a String and pass that around, but I'm worried this might be somewhat heavy and unnecessary at times?

view this post on Zulip Alex Crichton (Mar 25 2020 at 14:27):

it's true that is almost always safe, yeah

view this post on Zulip Jakub Konka (Mar 25 2020 at 14:29):

@Dan Gohman do you think passing paths as String would be something we could consider?

view this post on Zulip Dan Gohman (Mar 26 2020 at 23:06):

I wouldn't rule it out, but it doesn't seem like something we need to do right now.

view this post on Zulip Dan Gohman (Mar 26 2020 at 23:11):

I'd like to think a bit and see what other ideas we can come up with.

view this post on Zulip Dan Gohman (Mar 26 2020 at 23:12):

Such as, what if we added a parameter to from_witx which could say "I promise that none of my implementations will re-enter (on penalty of undefined behavior)"

view this post on Zulip Dan Gohman (Mar 26 2020 at 23:14):

"or call memory.grow or equivalent"


Last updated: Nov 22 2024 at 16:03 UTC