Messages in this thread | ![/](/images/icornerl.gif) | | From | Paul Burton <> | Subject | Re: Fixing MIPS delay slot emulation weakness? | Date | Sat, 15 Dec 2018 21:26:45 +0000 |
| |
Hi Andy,
On Sat, Dec 15, 2018 at 11:19:37AM -0800, Andy Lutomirski wrote: > 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.burton@imgtec.com> > Date: Fri Jul 8 11:06:19 2016 +0100 > > MIPS: Use per-mm page to execute branch delay slot instructions
Are there any further details you can share? You'd still need to persuade a program to both write to & jump to the page, right? We're talking purely about this providing writable+executable memory?
For the record prior to this patch we had to keep the user's stack executable & write instructions there, so this didn't make things any worse.
> 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.
Right, I can look into that.
> 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.
The ultimate fix comes with a switch to the nanoMIPS ISA which has no delay slots :)
Thanks, Paul
| ![\](/images/icornerr.gif) |