On Sat, Dec 15, 2018 at 11:19:37AM -0800, Andy Lutomirski wrote: > Hi all- > > Some security researchers pointed out that writing to the delay slot > emulation page is a great exploit technique on MIPS. It was > introduced in: > > commit 432c6bacbd0c16ec210c43da411ccc3855c4c010 > Author: Paul Burton <paul.bur...@imgtec.com> > Date: Fri Jul 8 11:06:19 2016 +0100 > > MIPS: Use per-mm page to execute branch delay slot instructions > > With my vDSO hat on, I hereby offer a couple of straightforward > suggestions for fixing it. The offending code is: > > base = mmap_region(NULL, STACK_TOP, PAGE_SIZE, > VM_READ|VM_WRITE|VM_EXEC| > VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC, > 0, NULL); > > VM_WRITE | VM_EXEC is a big no-no, especially at a fixed address. > > The really simple but possibly suboptimal fix is to get rid of > VM_WRITE and to use get_user_pages(..., FOLL_FORCE) to write to it. > > A possibly nicer way to accomplish more or less the same thing would > be to allocate the area with _install_special_mapping() and arrange to > keep a reference to the struct page around. > > The really nice but less compatible fix would be to let processes or > even the whole system opt out by promising not to put anything in FPU > branch delay slots, of course.
As I noted on Twitter when Mudge brought this topic back up, there's a much more compatible, elegant, and safe fix possible that does not involve any W+X memory. Emulate the delay slot in kernel-space. This is trivial to do safely for pretty much everything but loads/stores. For loads/stores, where you want them to execute with user privilege level, what you do is compute the effective address in kernel-space, then return to a fixed instruction in the vdso page that performs a generic load/store using the register the kernel put the effective address result in, then restores registers off the stack and jumps to the branch destination. Rich
