-
Notifications
You must be signed in to change notification settings - Fork 341
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve handling of failed operations in isolation mode #1034
Comments
@oli-obk I'd be interested in your opinion here: right now we abort execution on shims that are unsupported due to isolation; if we instead continue execution pretending the function errored that might be unexpected. Though OTOH this is what "normal" sandboxes do so I think it's actually expected. We could emit a warning the first time this happens -- this might be a good test project for #797. |
hmm... we do this already for all the pthread code, so we do have precedent. I'm fine with it and I don't think we'd need a warning. I would expect a sandboxed |
If we decide to make disabled functions return an error code, I think we should have a command-line flag to opt in to the old behavior. There should be a way of running Miri such that either:
|
While I personally don't see a reason for such a flag, I won't block it if there is strong desire for it. We've been doing quite well with just having unsupported functions return even success return values and do nothing. Going a step further and reporting error return values for unsupported functions where the caller has a fallback or otherwise useful code path seems totally alright to me. |
Same.
Note that we cannot guarantee this due to things like pointer-integer casts, or libc functions that return the stack size (we just return some constant, 16k if I remember correctly). And we already don't try to be faithful for most things "implemented" in |
Here's another example where it would be good if isolated operations returned failure instead of aborting execution: seanmonstar/num_cpus#96 makes |
This would be great to have for my usecase. I'm wanting to add miri support to https://github.com/camshaft/bolero and wanted to read the fuzz corpus from the filesystem, if possible, otherwise fall back to only generating some random tests cases with a warning saying to disable isolation if desired. |
I'm going to try working on this. |
@camelid that's great. :-) |
@camelid Are you still working on this or can I take a shot at this? |
@henryboisdequin I never ended up getting to this, so you can try! |
Hi @RalfJung , I opened a PR fixing get and set cwd ops. Let me know what you think. |
With #1797 we now support returning |
I guess most of the |
Yes, I think that would make a lot of sense. |
#1838 takes care of fs shims. |
Fix use of deprecated `check_no_isolation` in posix fs shims Update posix fs shims to use new API `reject_in_isolation`, which allows rejection with error code instead of always forcing abort. Error code chosen for each op is the most appropriate one from the list in corresponding syscall's manual. Updated helper APIs to not use quotes (\`) around input name while preparing the message. This allows callers to pass multi-word string like -- "\`read\` from stdin". Cc #1034
With #1838 landing soon, the remaining uses of
|
Currently, we abort program execution when we try to access the external environment in isolation mode. However,
libstd
currently callsgetcwd
when printing out a panic backtrace. To ensure that panicking works in isolation mode, we've disabled the call togetcwd
whenlibstd
hascfg(miri)
enabled.Eventually, it would be good to remove this hack, and start returning proper error codes from disabled functions, rather than aborting the process.
See rust-lang/rust#60026 (comment) for more discussion
The text was updated successfully, but these errors were encountered: