betrusted-io / xous-core

The Xous microkernel
Apache License 2.0
533 stars 85 forks source link

`pledge` syscall to manage process syscall scope #15

Open bunnie opened 3 years ago

bunnie commented 3 years ago

Not all processes should be able to make all syscalls to the kernel.

Processes are born with the full scope of syscalls available to them, and the pledge call reduces the scope of syscalls available.

Note that a process can have pledge() called on its scope before it is runnable, to restrict its scope before it is executed.

hasheddan commented 3 years ago

@bunnie @xobs I'd be happy to work on implementing this if y'all are open to someone contributing in a larger / more formal role

xobs commented 3 years ago

Hi @hasheddan,

Thanks for offering to help! An example of how to create a syscall can be found at https://github.com/betrusted-io/xous-core/commit/f165130931bbccfafc3cfa9d0c5b1a109e5b9da6#diff-1e7eb6a2fa6b0945e8c39b8c25b4a174b89e04e6d9bac16e05ccf6aca5edb17f

The crux of the issue is that each process needs to have a table that lists what syscalls it's allowed to make. The thought I had was to stuff it in the ProcessInner struct, which is available at https://github.com/betrusted-io/xous-core/blob/master/kernel/src/services.rs#L109-L138. You'll want to add a usize to that table, then remove 4 bytes of _padding from https://github.com/betrusted-io/xous-core/blob/master/kernel/src/arch/riscv/process.rs#L44-L63 in order to keep the overall entry at 128 bytes.

bunnie commented 3 years ago

@bunnie @xobs I'd be happy to work on implementing this if y'all are open to someone contributing in a larger / more formal role

I think that'd be amazing if you could help out! let us know if there's any questions and/or things we can do to help navigate the source code. We're still laying the foundations, so things are shifting around quite a bit.

eau-u4f commented 1 year ago

do you have already defined syscalls subsets that would be gathered in pledge promises? I guess it became more clear with implementation of new "apps" on precursor. (this is just curiosity)

bunnie commented 1 year ago

I think the thought was to allow processes to "give up" any set of syscalls, but there are some that are rarely used some that are more diagnostic that would be first candidates to pledge out. For example, claiming an IRQ isn't something you should need to do spontaneously. In theory it should be "harmless" for someone to try to claim an already claimed one (it'll just throw an error) but it's also an attack surface that isn't necessary. Reverse-resolving virtual to physical pages is another candidate call to pledge out -- this call is purely diagnostic in nature, and is in fact a feature flag right now. It'd be nice if "high risk" apps that form the initial attack surface for things like the network stack would also be coded in a way such that most calls are pledged out, since they could just be DoS vectors (e.g. trying to allocate lots of heap to crash the system, etc.)...