[RFC/RFT PATCH 0/2] arm64: per-task stack canaries

Laura Abbott labbott at redhat.com
Tue Feb 13 10:32:21 PST 2018


On 02/12/2018 02:49 AM, Ard Biesheuvel wrote:
> On 9 February 2018 at 20:20, Laura Abbott <labbott at redhat.com> wrote:
>> On 01/23/2018 05:03 AM, Ard Biesheuvel wrote:
>>>
>>> This is a proof of concept implementation of per-task stack canaries for
>>> arm64. The purpose is to reach agreement between the arm64 kernel and GCC
>>> maintainers on how to implement support for this in the compiler.
>>>
>>> What these patches show is that we can support per-task stack canaries
>>> on arm64 using only very minor changes on the kernel side, i.e., all
>>> that is needed is exposing the offset of stack_canary in task_struct
>>> via an ELF symbol. With that in place, the compiler needs to emit the
>>> following sequence when -fstack-protector-guard=tls is enabled
>>>
>>>     movz    xN, :abs_g0:__stack_chk_guard_offset
>>>     msr     xM, sp_el0
>>>     ldr     xM, [xM, xN]
>>>
>>> Note that this does not involve per-CPU variables, and so there are no
>>> concurrency issues to be addressed. sp_el0 is the current task pointer,
>>> whose value never changes from the POV of the task, even when migrating
>>> to another CPU.
>>>
>>> Patch #1 implements a GCC plugin that patches the sequence
>>>
>>>     adrp    xN, __stack_chk_guard
>>>     add     xN, Xn, :lo12:__stack_chk_guard
>>>
>>> into
>>>
>>>     mrs     xN, sp_el0
>>>     add     xN, xN, :lo12:__stack_chk_guard_offset
>>>
>>> which is a poor man's version of the movz/msr/ldr sequence above (and only
>>> works for small model code), but is sufficient as a proof of concept.
>>>
>>> Patch #2 exposes the __stack_chk_guard_offset symbol and wires up the
>>> plugin
>>> (if enabled in Kconfig)
>>>
>>> Again, the point is not to use GCC plugin based hacks, but to reach
>>> agreement
>>> on how to proceed with this for GCC.
>>>
>>> Comments welcome.
>>>
>>
>> I was seeing some crashes with these when I tried to boot up on my
>> full Fedora system. It looked like a compiler bug with grabbing
>> the wrong literal but I don't think it's worth looking at it since
>> it's probably just something with the plugin which isn't the real
>> focus here. I can send along the crash if you are interested.
>>
> 
> Yes please. Did it crash in a modules? Did you build with
> KASLR/erratum 843419 disabled?
> 

Turning off erratum 843419 makes it work. The crashes were in
modules:

[    5.105030] Internal error: Accessing user space memory outside uaccess.hP
[    5.115500] Modules linked in: sdhci_of_arasan(+) sdhci_pltfm i2s
[    5.127261] CPU: 5 PID: 336 Comm: systemd-udevd Not tainted 4.15.0-canary+ #6
[    5.135909] Hardware name: AppliedMicro X-Gene Mustang Board/X-Gene M6
[    5.146981] pstate: 20400005 (nzCv daif +PAN -UAO)
[    5.153130] pc : sdhci_arasan_probe+0x30/0x638 [sdhci_of_ara]
[    5.160482] lr : platform_drv_probe+0x60/0xc0
[    5.166190] sp : ffff00000c17b970
[    5.170866] x29: ffff00000c17b970 x28: ffff000008ae48a8
[    5.177530] x27: ffff000000b5f298 x26: ffff000000b5f108
[    5.184194] x25: ffff000000b5f280 x24: ffff8003fffe6ea8
[    5.190857] x23: ffff000000b5f028 x22: 0000000000000000
[    5.197002] x21: 0000000000000590 x20: ffff8003ec98e010
[    5.202288] x19: ffff8003ec98e000 x18: 0000000000000001
[    5.207573] x17: 0000000000000004 x16: 0000000000000000
[    5.212859] x15: ffffffffffffffff x14: ffff8003e3e85f90
[    5.218145] x13: ffff8003937afb0a x12: 0000000000000030
[    5.223430] x11: 0000000000000003 x10: 0101010101010101
[    5.228716] x9 : fffffffffffffffa x8 : 7f7f7f7f7f7f7f7f
[    5.234000] x7 : fefefeff646c606d x6 : 1e0e1a00f2ade4ef
[    5.239286] x5 : 6f642d72001a0e1e x4 : 8080808000000000
[    5.244572] x3 : 837bbb2b916b2378 x2 : 82962d9749f72000
[    5.249856] x1 : ffff000000b5e850 x0 : ffff000008726598
[    5.255142] Process systemd-udevd (pid: 336, stack limit = 0x00000000d88c80b)
[    5.262329] Call trace:
[    5.264765]  sdhci_arasan_probe+0x30/0x638 [sdhci_of_arasan]
[    5.270395]  platform_drv_probe+0x60/0xc0
[    5.274384]  driver_probe_device+0x2a0/0x468
[    5.278632]  __driver_attach+0x124/0x128
[    5.282534]  bus_for_each_dev+0x84/0xd8
[    5.286349]  driver_attach+0x30/0x40
[    5.289906]  bus_add_driver+0x26c/0x298
[    5.293721]  driver_register+0x6c/0x110
[    5.297537]  __platform_driver_register+0x54/0x60
[    5.302218]  sdhci_arasan_driver_init+0x1c/0x1000 [sdhci_of_arasan]
[    5.308455]  do_one_initcall+0x58/0x160
[    5.312271]  do_init_module+0x60/0x1f0
[    5.316001]  load_module+0x13fc/0x1728
[    5.319730]  SyS_finit_module+0xfc/0x118
[    5.323632]  __sys_trace_return+0x0/0x4
[    5.327449] Code: d503201f 58002ae1 58002a55 f9413e78 (f94002a0)
[    5.333513] ---[ end trace aabd65049cbf2f2e ]---

0000000000000840 <sdhci_arasan_probe>:
  840:   a9b67bfd        stp     x29, x30, [sp, #-160]!
  844:   910003fd        mov     x29, sp
  848:   a90153f3        stp     x19, x20, [sp, #16]
  84c:   f90013f5        str     x21, [sp, #32]
  850:   a90363f7        stp     x23, x24, [sp, #48]
  854:   f90023f9        str     x25, [sp, #64]
  858:   aa0003f3        mov     x19, x0
  85c:   aa1e03e0        mov     x0, x30
  860:   94000000        bl      0 <_mcount>
  864:   58002ae1        ldr     x1, dc0 <sdhci_arasan_probe+0x580>
  868:   58002a55        ldr     x21, db0 <sdhci_arasan_probe+0x570> <---- This looks like garbage
  86c:   f9413e78        ldr     x24, [x19, #632]
  870:   f94002a0        ldr     x0, [x21]

There was another crash in xfs:

[    6.273348] Internal error: Accessing user space memory outside uaccess.h roP
[    6.282530] Modules linked in: xfs libcrc32c sdhci_of_arasan(+) sdhci_pltfm s
[    6.294138] CPU: 1 PID: 467 Comm: mount Tainted: G      D          4.15.0-ca6
[    6.302016] Hardware name: AppliedMicro X-Gene Mustang Board/X-Gene Mustang 6
[    6.311710] pstate: 40400005 (nZcv daif +PAN -UAO)
[    6.316666] pc : xfs_parseargs+0x2c/0x668 [xfs]
[    6.321330] lr : xfs_fs_fill_super+0x120/0x550 [xfs]
[    6.326269] sp : ffff00000c82bba0
[    6.329566] x29: ffff00000c82bba0 x28: ffff800393869e00
[    6.334852] x27: ffff000008ad1000 x26: 0000000fffffffe0
[    6.340138] x25: 0000000000000590 x24: 0000000000000000
[    6.345424] x23: ffff000000c5df68 x22: ffff00000819cef8
[    6.350709] x21: ffff8003929b1000 x20: ffff800393431000
[    6.355995] x19: ffff8003929b1000 x18: 0000000000000009
[    6.361280] x17: 0000000000000000 x16: 0000000000000000
[    6.366566] x15: ffffffffffffffff x14: ffffffffff000000
[    6.371851] x13: ffffffffffffffff x12: 0000000000000018
[    6.377136] x11: 0101010101010101 x10: ffff00000c82bcb0
[    6.382421] x9 : 0000000000000000 x8 : ffff800393432000
[    6.387706] x7 : 0000000000000000 x6 : ffff000000bdfaf8
[    6.392992] x5 : ffff000000be0670 x4 : 0000000000000000
[    6.398277] x3 : 0000000000000000 x2 : 00000000000000c0
[    6.403562] x1 : 0000000000000000 x0 : ffff000000bf71f8
[    6.408850] Process mount (pid: 467, stack limit = 0x00000000cda0c16d)
[    6.415344] Call trace:
[    6.417933]  xfs_parseargs+0x2c/0x668 [xfs]
[    6.422256]  xfs_fs_fill_super+0x120/0x550 [xfs]
[    6.426854]  mount_bdev+0x1a0/0x1d0
[    6.430477]  xfs_fs_mount+0x40/0x58 [xfs]
[    6.434468]  mount_fs+0x5c/0x190
[    6.437680]  vfs_kern_mount.part.9+0x54/0x178
[    6.442014]  do_mount+0x1f8/0xc68
[    6.445312]  SyS_mount+0xfc/0x118
[    6.448612]  __sys_trace_return+0x0/0x4
[    6.452431] Code: d503201f 58002ed9 52801802 f9400293 (f9400320)
[    6.458496] ---[ end trace aabd65049cbf2f2f ]---

0000000000088a00 <xfs_parseargs>:
    88a00:       a9b47bfd        stp     x29, x30, [sp, #-192]!
    88a04:       910003fd        mov     x29, sp
    88a08:       a90153f3        stp     x19, x20, [sp, #16]
    88a0c:       f90023f9        str     x25, [sp, #64]
    88a10:       aa0003f4        mov     x20, x0
    88a14:       aa1e03e0        mov     x0, x30
    88a18:       f90037e1        str     x1, [sp, #104]
    88a1c:       94000000        bl      0 <_mcount>
    88a20:       58002ed9        ldr     x25, 88ff8 <xfs_parseargs+0x5f8> <---- also looks bogus
    88a24:       52801802        mov     w2, #0xc0                       // #192
    88a28:       f9400293        ldr     x19, [x20]
    88a2c:       f9400320        ldr     x0, [x25]
...
    88fec:       a90363f7        stp     x23, x24, [sp, #48]
    88ff0:       a904effa        stp     x26, x27, [sp, #72]
    88ff4:       94000000        bl      0 <__stack_chk_fail>
         ...


> 
>> It looked good to me otherwise.
>>
> 
> Thanks. I intend to try and restart the discussion on this topic this week.
> 
>>
>>> Ard Biesheuvel (2):
>>>     gcc-plugins: add support plugin for arm64 per-task stack canaries
>>>     arm64: kernel: use a unique stack canary value for each task
>>>
>>>    arch/Kconfig                                    |   4 +
>>>    arch/arm64/Kconfig                              |   7 ++
>>>    arch/arm64/include/asm/stackprotector.h         |   4 +-
>>>    arch/arm64/kernel/asm-offsets.c                 |   3 +
>>>    arch/arm64/kernel/process.c                     |   4 +
>>>    arch/arm64/kernel/vmlinux.lds.S                 |   8 ++
>>>    scripts/Makefile.gcc-plugins                    |   2 +
>>>    scripts/gcc-plugins/arm64_ssp_per_task_plugin.c | 121
>>> ++++++++++++++++++++
>>>    8 files changed, 152 insertions(+), 1 deletion(-)
>>>    create mode 100644 scripts/gcc-plugins/arm64_ssp_per_task_plugin.c
>>>
>>




More information about the linux-arm-kernel mailing list