* Mike Rapoport <rppt@xxxxxxxxxxxxx> wrote: > When enabled, the system call isolation (SCI) would allow execution of > the system calls with reduced page tables. These page tables are almost > identical to the user page tables in PTI. The only addition is the code > page containing system call entry function that will continue > exectution after the context switch. > > Unlike PTI page tables, there is no sharing at higher levels and all > the hierarchy for SCI page tables is cloned. > > The SCI page tables are created when a system call that requires > isolation is executed for the first time. > > Whenever a system call should be executed in the isolated environment, > the context is switched to the SCI page tables. Any further access to > the kernel memory will generate a page fault. The page fault handler > can verify that the access is safe and grant it or kill the task > otherwise. > > The initial SCI implementation allows access to any kernel data, but it > limits access to the code in the following way: > * calls and jumps to known code symbols without offset are allowed > * calls and jumps into a known symbol with offset are allowed only if that > symbol was already accessed and the offset is in the next page > * all other code access are blocked > > After the isolated system call finishes, the mappings created during its > execution are cleared. > > The entire SCI page table is lazily freed at task exit() time. So this basically uses a similar mechanism to the horrendous PTI CR3 switching overhead whenever a syscall seeks "protection", which overhead is only somewhat mitigated by PCID. This might work on PTI-encumbered CPUs. While AMD CPUs don't need PTI, nor do they have PCID. So this feature is hurting the CPU maker who didn't mess up, and is hurting future CPUs that don't need PTI .. I really don't like it where this is going. In a couple of years I really want to be able to think of PTI as a bad dream that is mostly over fortunately. I have the feeling that compiler level protection that avoids corrupting the stack in the first place is going to be lower overhead, and would work in a much broader range of environments. Do we have analysis of what the compiler would have to do to prevent most ROP attacks, and what the runtime cost of that is? I mean, C# and Java programs aren't able to corrupt the stack as long as the language runtime is corect. Has to be possible, right? Thanks, Ingo
