Add experimental stub_syscalls config option#3332
Add experimental stub_syscalls config option#3332stevenengler wants to merge 1 commit intoshadow:mainfrom
stub_syscalls config option#3332Conversation
robgjansen
left a comment
There was a problem hiding this comment.
This looks like a reasonable improvement to me!
One concern is that there are stubs that require more than just return 0, but maybe there are not that many of those so adding manual stubs for them would not be too onerous? This does make me wonder for how many of our missing syscalls does return 0 make sense...
| Log the syscalls for each process to individual "strace" files [default: "off"] | ||
|
|
||
| --stub-syscalls <syscalls> | ||
| List of syscall numbers to add "return 0" stubs for. [default: []] |
There was a problem hiding this comment.
Do we have any stubs already in Shadow that we would want to remove but then set as default in this configuration option instead (i.e., so that it goes through the new stub logic)? Or maybe we just want to keep those in place, because if the default for --stub-syscalls is x,y,z but the user has a new syscall 666 that they want Shadow to treat as a stub, they would probably get confused and accidentally drop the defaults by writing --stub-syscalls=666 instead of --stub-syscalls=x,y,z,666?
There was a problem hiding this comment.
I don't see any existing syscall stubs in Shadow that we'd want to use this for. But we might want to add another config option in the future for adding stubs for socket options, and in that case we probably would want to add defaults for for those socket options.
they would probably get confused and accidentally drop the defaults by writing
--stub-syscalls=666instead of--stub-syscalls=x,y,z,666
Yeah, this is similar to the --args option of tornettools simulate, where adding new args drops the default args. I'm not sure what the solution to this is.
I can't think of any syscalls that someone might want to stub which don't return 0. Any syscall I can think of which returns a non-zero value typically needs to do something to arrive at the returned value, and I don't see how returning a constant value would be useful. My thinking is that it would be easiest to just support returning 0 for now, and then if someone has a more complicated use case, we could change the option somehow to support that as well. |
|
I'm closing this for now since I think there are still some open questions, especially if we want to also include stubs for socket options and ioctls and have them be consistent with syscall stubs. I don't have any immediate plans to work on these other stubs, and it would be better to have some cohesive design for them. Anyone can reopen or copy these changes to a new PR if they want. |
In #3280 we discussed allowing users to add stubs for features that Shadow is missing. There are a lot of different features that users may want to add stubs for (ex: syscalls, socket options, ioctl commands, misc syscall flags, etc).
This PR adds an experimental
stub_syscalls(or--stub-syscalls) configuration option that allows you to list syscall numbers that you wish to add stubs for. This only covers a small part of #3280. I'm thinking that we could cover the rest of #3280 with a secondstub_featuresoption or something. But it might make sense to handle syscalls separately with their ownstub_syscallsoption.This new option takes syscall numbers instead of names so that users can specify syscalls that shadow doesn't know about. For example if a new Linux version introduces a new syscall and we haven't added it to linux-api yet. It also helps prevent mistakes from misspellings or differences between linux syscall names and libc function names.
@robgjansen Wdyt? I'm open to alternative designs.