2 ms·

Those mitigations affect syscall speed. Syscalls are not required for IPC.

by junon 5y ago

detaro 5y ago
They affect syscall speed because in "conventional" OSes that's the barrier between privileges that's crossed, at which point memory permissions need to be readjusted. If you replace syscalls with calls to other processes, the same potentially applies. Also, IPC does often involve calling to kernel space to execute the IPC? And from a quick google, sel4 did indeed add such mitigations: https://research.csiro.au/tsblog/crisis-security-vs-performance/ https://research.csiro.au/tsblog/crisis-security-vs-performa... > The question of whether or not a userspace attacker can attack another userspace thread running on seL4 is an unequivocal yes. > We are currently in the middle of deploying the branch-prediction barriers (x86) and BTB flushing mechanisms (ARMv6, ARMv7) that are necessary to prevent attackers from attacking other userspace threads on seL4. > [....] > seL4 will allow userspace processes to specify whether or not they want to take the performance hit that is incurred by effectively flushing the branch predictor when switching between processes on x86 (which is currently the only way to mitigate this variant of Spectre). The performance penalty of flushing the branch predictor on x86 processors is, unfortunately, very high. And later regarding performance, although I'm not 100% sure on which parts this exactly applies: > Initial tentative estimations of the impact are that they will likely be higher than those experienced by a monolithic kernel for the simple reason that microkernels switch address spaces more due to their essential function as an IPC engine, and the SKIM window patch alone increases the number of address space switches that the kernel must do.
- junon 5y ago
  > They affect syscall speed because in "conventional" OSes that's the barrier between privileges that's crossed That's not the only case where privilege barriers can be crossed. In x86, that is the most common way for calling into kernel code, but it is not the only way. See io_uring. > Also, IPC does often involve calling to kernel space to execute the IPC? Often. Not always.

Those mitigations affect syscall speed. Syscalls are not required for IPC.

by junon 5y ago

Those mitigations affect syscall speed. Syscalls are not required for IPC.

They affect syscall speed because in "conventional" OSes that's the barrier between privileges that's crossed, at which point memory permissions need to be readjusted. If you replace syscalls with calls to other processes, the same potentially applies. Also, IPC does often involve calling to kernel space to execute the IPC? And from a quick google, sel4 did indeed add such mitigations: https://research.csiro.au/tsblog/crisis-security-vs-performance/ https://research.csiro.au/tsblog/crisis-security-vs-performa... > The question of whether or not a userspace attacker can attack another userspace thread running on seL4 is an unequivocal yes. > We are currently in the middle of deploying the branch-prediction barriers (x86) and BTB flushing mechanisms (ARMv6, ARMv7) that are necessary to prevent attackers from attacking other userspace threads on seL4. > [....] > seL4 will allow userspace processes to specify whether or not they want to take the performance hit that is incurred by effectively flushing the branch predictor when switching between processes on x86 (which is currently the only way to mitigate this variant of Spectre). The performance penalty of flushing the branch predictor on x86 processors is, unfortunately, very high. And later regarding performance, although I'm not 100% sure on which parts this exactly applies: > Initial tentative estimations of the impact are that they will likely be higher than those experienced by a monolithic kernel for the simple reason that microkernels switch address spaces more due to their essential function as an IPC engine, and the SKIM window patch alone increases the number of address space switches that the kernel must do.

junon 5y ago
> They affect syscall speed because in "conventional" OSes that's the barrier between privileges that's crossed That's not the only case where privilege barriers can be crossed. In x86, that is the most common way for calling into kernel code, but it is not the only way. See io_uring. > Also, IPC does often involve calling to kernel space to execute the IPC? Often. Not always.