On 4/25/19 2:45 PM, Mike Rapoport wrote: > The idea behind the prevention is that if we fault in pages in the > execution path, we can compare target address against the kernel symbol > table. So if we're in a function, we allow local jumps (and simply falling > of the end of a page) but if we're jumping to a new function it must be to > an external label in the symbol table. Since ROP attacks are all about > jumping to gadget code which is effectively in the middle of real > functions, the jumps they induce are to code that doesn't have an external > symbol, so it should mostly detect when they happen. This turns the problem from: "attackers can leverage any data/code that the kernel has mapped (anything)" to "attackers can leverage any code/data that the current syscall has faulted in". That seems like a pretty restrictive change. > At this time we are not suggesting any API that will enable the system > calls isolation. Because of the overhead required for this, it should only > be activated for processes or containers we know should be untrusted. We > still have no actual numbers, but surely forcing page faults during system > call execution will not come for free. What's the minimum number of faults that have to occur to handle the simplest dummy fault?
