[OpenWrt-Devel] [PATCH] kernel: MIPS: math-emu Write-protect delay slot emulation pages

Hauke Mehrtens hauke at hauke-m.de
Sat Dec 22 13:28:34 EST 2018

On 12/22/18 10:26 AM, Yousong Zhou wrote:
> On Sat, 22 Dec 2018 at 16:03, Kevin 'ldir' Darbyshire-Bryant
> <ldir at darbyshire-bryant.me.uk> wrote:
>>> On 22 Dec 2018, at 04:04, Yousong Zhou <yszhou4tech at gmail.com> wrote:
>>> On Sat, 22 Dec 2018 at 01:21, Kevin 'ldir' Darbyshire-Bryant
>>> <ldir at darbyshire-bryant.me.uk> wrote:
>>>> Backport https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=adcc81f148d733b7e8e641300c5590a2cdc13bf3
>>>> "Mapping the delay slot emulation page as both writeable & executable
>>>> presents a security risk, in that if an exploit can write to & jump into
>>>> the page then it can be used as an easy way to execute arbitrary code.
>>>> Prevent this by mapping the page read-only for userland, and using
>>>> access_process_vm() with the FOLL_FORCE flag to write to it from
>>>> mips_dsemul().
>>>> This will likely be less efficient due to copy_to_user_page() performing
>>>> cache maintenance on a whole page, rather than a single line as in the
>>>> previous use of flush_cache_sigtramp(). However this delay slot
>>>> emulation code ought not to be running in any performance critical paths
>>>> anyway so this isn't really a problem, and we can probably do better in
>>>> copy_to_user_page() anyway in future.
>>>> A major advantage of this approach is that the fix is small & simple to
>>>> backport to stable kernels.
>>>> Reported-by: Andy Lutomirski <luto at kernel.org>
>>>> Signed-off-by: Paul Burton <paul.burton at mips.com>
>>>> Fixes: 432c6bacbd0c ("MIPS: Use per-mm page to execute branch delay slot instructions")"
>>>> Without patch:
>>>> cat /proc/self/maps
>>>> 00400000-0047a000 r-xp 00000000 1f:03 1823       /bin/busybox
>>>> 00489000-0048a000 r-xp 00079000 1f:03 1823       /bin/busybox
>>>> 0048a000-0048b000 rwxp 0007a000 1f:03 1823       /bin/busybox
>>>> 77ec8000-77eed000 r-xp 00000000 1f:03 2296       /lib/libgcc_s.so.1
>>>> 77eed000-77eee000 rwxp 00015000 1f:03 2296       /lib/libgcc_s.so.1
>>>> 77eee000-77f81000 r-xp 00000000 1f:03 2470       /lib/libc.so
>>>> 77f90000-77f92000 rwxp 00092000 1f:03 2470       /lib/libc.so
>>>> 77f92000-77f94000 rwxp 00000000 00:00 0
>>>> 7f946000-7f967000 rw-p 00000000 00:00 0          [stack]
>>>> 7fefb000-7fefc000 rwxp 00000000 00:00 0
>>>> 7ffac000-7ffad000 r--p 00000000 00:00 0          [vvar]
>>>> 7ffad000-7ffae000 r-xp 00000000 00:00 0          [vdso]
>>> Hi,
>>> I must miss something.  After reading another thread on mips security,
>>> I was thinking that all segments with w and x permission set were
>>> problematic:  the same attacker can write and execute shellcode there,
>>> right?  Sorry, if the answer is too apparent ;(
>>> Regards,
>>>                 yousong
>> Hi Yousong,
>> My limited understanding goes something like this:  Most of the other segments address ranges change on each execution due to ASLR, thus whilst they can be written to things are harder for an attacker because locations change.  The math emulation page was especially bad because a) user space had write permission to it and b) it was always in a fixed location.  The patch removes user space write permission to the page thus the process should receive a SIGSEGV if it attempts to do so.
>> Cheers,
>> Kevin D-B
> Thanks for the confirmation ;) . Indeed, I just did a quick read on
> the kernel code, that region is mapped at STACK_TOP, essentially a
> constant.
> It's also worth noting that segments of the executable itself is also
> not randomized.  I checked OpenWrt x86/64, malta/be, and CentOS7, they
> are all the same.  It's quite a surprise to me.  I always assumed
> randomization was applied to all segments.
> Regards,
>                  yousong

Hi Yousong,

ASLR is currently not activated by default in OpenWrt, so the binary 
itself is not randomized. Activate CONFIG_PKG_ASLR_PIE to compile 
Openwrt with ASLR, but this increases the size of the binary.

I haven't understood why some parts of the busybox binary and other 
binaries are mapped rwx, when I look into it with readelf no section is 
mapped rwx, but it looks like some sections are ending at an not page 
aligned offset and the next section starts directly after that. I assume 
that Linux merges the permissions when one page needs different permissions.

I am still not sure if the common mips CPUs (24Kec, 74Kec) support 
restricting execution on pages anyway.


openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list