You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We use the bitflags library in Shadow. One of the larger use-cases is for representing syscall API flags. Since we don't control the values passed into syscall handlers, the application may have set bits that aren't represented where we define the type using the bitflags! macro.
It's unclear exactly how the bitflags library handles unknown bits. For example if you invert/negate a bitflags type, does it only flip the known bits, or all of the bits? In bitflags 2.3.3 there were changes to the ! operator, and it also introduced a const ALL = !0 flag to indicate that any bit pattern is valid. The bitflags author also introduced a specification document that supposedly explains the current behaviour. They have also indicated that the default behaviour may be changing in the future.
Since this is all confusing, we should figure out exactly what the current behaviour is, make sure our current code is behaving properly, and preferably make any changes needed so that it will continue to work in the future. This probably involves adding a const ALL = !0 to a bunch of types, especially around the syscall interface and in the "linux-api" library.
The text was updated successfully, but these errors were encountered:
We use the bitflags library in Shadow. One of the larger use-cases is for representing syscall API flags. Since we don't control the values passed into syscall handlers, the application may have set bits that aren't represented where we define the type using the
bitflags!
macro.It's unclear exactly how the bitflags library handles unknown bits. For example if you invert/negate a bitflags type, does it only flip the known bits, or all of the bits? In bitflags 2.3.3 there were changes to the
!
operator, and it also introduced aconst ALL = !0
flag to indicate that any bit pattern is valid. The bitflags author also introduced a specification document that supposedly explains the current behaviour. They have also indicated that the default behaviour may be changing in the future.Since this is all confusing, we should figure out exactly what the current behaviour is, make sure our current code is behaving properly, and preferably make any changes needed so that it will continue to work in the future. This probably involves adding a
const ALL = !0
to a bunch of types, especially around the syscall interface and in the "linux-api" library.The text was updated successfully, but these errors were encountered: