1. 26 4月, 2021 3 次提交
  2. 17 3月, 2021 1 次提交
  3. 10 3月, 2021 1 次提交
  4. 27 2月, 2021 1 次提交
  5. 19 2月, 2021 2 次提交
  6. 03 2月, 2021 1 次提交
  7. 16 1月, 2021 1 次提交
  8. 15 1月, 2021 7 次提交
    • G
      riscv: Enable per-task stack canaries · fea2fed2
      Guo Ren 提交于
      This enables the use of per-task stack canary values if GCC has
      support for emitting the stack canary reference relative to the
      value of tp, which holds the task struct pointer in the riscv
      kernel.
      
      After compare arm64 and x86 implementations, seems arm64's is more
      flexible and readable. The key point is how gcc get the offset of
      stack_canary from gs/el0_sp.
      
      x86: Use a fix offset from gs, not flexible.
      
      struct fixed_percpu_data {
      	/*
      	 * GCC hardcodes the stack canary as %gs:40.  Since the
      	 * irq_stack is the object at %gs:0, we reserve the bottom
      	 * 48 bytes of the irq stack for the canary.
      	 */
      	char            gs_base[40]; // :(
      	unsigned long   stack_canary;
      };
      
      arm64: Use -mstack-protector-guard-offset & guard-reg
      	gcc options:
      	-mstack-protector-guard=sysreg
      	-mstack-protector-guard-reg=sp_el0
      	-mstack-protector-guard-offset=xxx
      
      riscv: Use -mstack-protector-guard-offset & guard-reg
      	gcc options:
      	-mstack-protector-guard=tls
      	-mstack-protector-guard-reg=tp
      	-mstack-protector-guard-offset=xxx
      
       GCC's implementation has been merged:
       commit c931e8d5a96463427040b0d11f9c4352ac22b2b0
       Author: Cooper Qu <cooper.qu@linux.alibaba.com>
       Date:   Mon Jul 13 16:15:08 2020 +0800
      
           RISC-V: Add support for TLS stack protector canary access
      
      In the end, these codes are inserted by gcc before return:
      
      *  0xffffffe00020b396 <+120>:   ld      a5,1008(tp) # 0x3f0
      *  0xffffffe00020b39a <+124>:   xor     a5,a5,a4
      *  0xffffffe00020b39c <+126>:   mv      a0,s5
      *  0xffffffe00020b39e <+128>:   bnez    a5,0xffffffe00020b61c <_do_fork+766>
         0xffffffe00020b3a2 <+132>:   ld      ra,136(sp)
         0xffffffe00020b3a4 <+134>:   ld      s0,128(sp)
         0xffffffe00020b3a6 <+136>:   ld      s1,120(sp)
         0xffffffe00020b3a8 <+138>:   ld      s2,112(sp)
         0xffffffe00020b3aa <+140>:   ld      s3,104(sp)
         0xffffffe00020b3ac <+142>:   ld      s4,96(sp)
         0xffffffe00020b3ae <+144>:   ld      s5,88(sp)
         0xffffffe00020b3b0 <+146>:   ld      s6,80(sp)
         0xffffffe00020b3b2 <+148>:   ld      s7,72(sp)
         0xffffffe00020b3b4 <+150>:   addi    sp,sp,144
         0xffffffe00020b3b6 <+152>:   ret
         ...
      *  0xffffffe00020b61c <+766>:   auipc   ra,0x7f8
      *  0xffffffe00020b620 <+770>:   jalr    -1764(ra) # 0xffffffe000a02f38 <__stack_chk_fail>
      Signed-off-by: NGuo Ren <guoren@linux.alibaba.com>
      Signed-off-by: NCooper Qu <cooper.qu@linux.alibaba.com>
      Reviewed-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>
      fea2fed2
    • G
      riscv: Add support for function error injection · ee55ff80
      Guo Ren 提交于
      Inspired by the commit 42d038c4 ("arm64: Add support for function
      error injection"), this patch supports function error injection for
      riscv.
      
      This patch mainly support two functions: one is regs_set_return_value()
      which is used to overwrite the return value; the another function is
      override_function_with_return() which is to override the probed
      function returning and jump to its caller.
      
      Test log:
       cd /sys/kernel/debug/fail_function
       echo sys_clone > inject
       echo 100 > probability
       echo 1 > interval
       ls /
      [  313.176875] FAULT_INJECTION: forcing a failure.
      [  313.176875] name fail_function, interval 1, probability 100, space 0, times 1
      [  313.184357] CPU: 0 PID: 87 Comm: sh Not tainted 5.8.0-rc5-00007-g6a758cc #117
      [  313.187616] Call Trace:
      [  313.189100] [<ffffffe0002036b6>] walk_stackframe+0x0/0xc2
      [  313.191626] [<ffffffe00020395c>] show_stack+0x40/0x4c
      [  313.193927] [<ffffffe000556c60>] dump_stack+0x7c/0x96
      [  313.194795] [<ffffffe0005522e8>] should_fail+0x140/0x142
      [  313.195923] [<ffffffe000299ffc>] fei_kprobe_handler+0x2c/0x5a
      [  313.197687] [<ffffffe0009e2ec4>] kprobe_breakpoint_handler+0xb4/0x18a
      [  313.200054] [<ffffffe00020357e>] do_trap_break+0x36/0xca
      [  313.202147] [<ffffffe000201bca>] ret_from_exception+0x0/0xc
      [  313.204556] [<ffffffe000201bbc>] ret_from_syscall+0x0/0x2
      -sh: can't fork: Invalid argument
      Signed-off-by: NGuo Ren <guoren@linux.alibaba.com>
      Reviewed-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Cc: Palmer Dabbelt <palmerdabbelt@google.com>
      Cc: Paul Walmsley <paul.walmsley@sifive.com>
      Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>
      ee55ff80
    • G
      riscv: Add uprobes supported · 74784081
      Guo Ren 提交于
      This patch adds support for uprobes on riscv architecture.
      
      Just like kprobe, it support single-step and simulate instructions.
      Signed-off-by: NGuo Ren <guoren@linux.alibaba.com>
      Reviewed-by: NPekka Enberg <penberg@kernel.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Palmer Dabbelt <palmerdabbelt@google.com>
      Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>
      74784081
    • G
      riscv: Add KPROBES_ON_FTRACE supported · 829adda5
      Guo Ren 提交于
      This patch adds support for kprobes on ftrace call sites to avoids
      much of the overhead with regular kprobes. Try it with simple
      steps:
      
       echo 'p:myprobe sys_clone a0=%a0 a1=%a1 stack_val=+4($stack)' > /sys/kernel/de
      bug/tracing/kprobe_events
       echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable
       cat /sys/kernel/debug/tracing/trace
       tracer: nop
      
       entries-in-buffer/entries-written: 1/1   #P:1
      
                                      _-----=> irqs-off
                                     / _----=> need-resched
                                    | / _---=> hardirq/softirq
                                    || / _--=> preempt-depth
                                    ||| /     delay
                 TASK-PID     CPU#  ||||   TIMESTAMP  FUNCTION
                    | |         |   ||||      |         |
                    sh-92      [000] ....   369.899962: myprobe: (sys_clone+0x0/0x28) a0=0x1200011 a1=0x0 stack_val=0x201c20ffffffe0
       cat /sys/kernel/debug/kprobes/list
      ffffffe00020b584  k  sys_clone+0x0    [FTRACE]
                                             ^^^^^^
      Signed-off-by: NGuo Ren <guoren@linux.alibaba.com>
      Reviewed-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>
      829adda5
    • G
      riscv: Add kprobes supported · c22b0bcb
      Guo Ren 提交于
      This patch enables "kprobe & kretprobe" to work with ftrace
      interface. It utilized software breakpoint as single-step
      mechanism.
      
      Some instructions which can't be single-step executed must be
      simulated in kernel execution slot, such as: branch, jal, auipc,
      la ...
      
      Some instructions should be rejected for probing and we use a
      blacklist to filter, such as: ecall, ebreak, ...
      
      We use ebreak & c.ebreak to replace origin instruction and the
      kprobe handler prepares an executable memory slot for out-of-line
      execution with a copy of the original instruction being probed.
      In execution slot we add ebreak behind original instruction to
      simulate a single-setp mechanism.
      
      The patch is based on packi's work [1] and csky's work [2].
       - The kprobes_trampoline.S is all from packi's patch
       - The single-step mechanism is new designed for riscv without hw
         single-step trap
       - The simulation codes are from csky
       - Frankly, all codes refer to other archs' implementation
      
       [1] https://lore.kernel.org/linux-riscv/20181113195804.22825-1-me@packi.ch/
       [2] https://lore.kernel.org/linux-csky/20200403044150.20562-9-guoren@kernel.org/Signed-off-by: NGuo Ren <guoren@linux.alibaba.com>
      Co-developed-by: NPatrick Stählin <me@packi.ch>
      Signed-off-by: NPatrick Stählin <me@packi.ch>
      Acked-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Tested-by: NZong Li <zong.li@sifive.com>
      Reviewed-by: NPekka Enberg <penberg@kernel.org>
      Cc: Patrick Stählin <me@packi.ch>
      Cc: Palmer Dabbelt <palmerdabbelt@google.com>
      Cc: Björn Töpel <bjorn.topel@gmail.com>
      Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>
      c22b0bcb
    • P
      RISC-V: Implement ptrace regs and stack API · dcdc7a53
      Patrick Stählin 提交于
      Needed for kprobes support. Copied and adapted from arm64 code.
      
      Guo Ren fixup pt_regs type for linux-5.8-rc1.
      Signed-off-by: NPatrick Stählin <me@packi.ch>
      Signed-off-by: NGuo Ren <guoren@linux.alibaba.com>
      Reviewed-by: NPekka Enberg <penberg@kernel.org>
      Reviewed-by: NZong Li <zong.li@sifive.com>
      Reviewed-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>
      dcdc7a53
    • A
      riscv: Add numa support for riscv64 platform · 4f0e8eef
      Atish Patra 提交于
      Use the generic numa implementation to add NUMA support for RISC-V.
      This is based on Greentime's patch[1] but modified to use generic NUMA
      implementation and few more fixes.
      
      [1] https://lkml.org/lkml/2020/1/10/233Co-developed-by: NGreentime Hu <greentime.hu@sifive.com>
      Signed-off-by: NGreentime Hu <greentime.hu@sifive.com>
      Signed-off-by: NAtish Patra <atish.patra@wdc.com>
      Reviewed-by: NAnup Patel <anup@brainfault.org>
      Reviewed-by: NPalmer Dabbelt <palmerdabbelt@google.com>
      Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>
      4f0e8eef
  9. 16 12月, 2020 1 次提交
    • M
      arch, mm: restore dependency of __kernel_map_pages() on DEBUG_PAGEALLOC · 5d6ad668
      Mike Rapoport 提交于
      The design of DEBUG_PAGEALLOC presumes that __kernel_map_pages() must
      never fail.  With this assumption is wouldn't be safe to allow general
      usage of this function.
      
      Moreover, some architectures that implement __kernel_map_pages() have this
      function guarded by #ifdef DEBUG_PAGEALLOC and some refuse to map/unmap
      pages when page allocation debugging is disabled at runtime.
      
      As all the users of __kernel_map_pages() were converted to use
      debug_pagealloc_map_pages() it is safe to make it available only when
      DEBUG_PAGEALLOC is set.
      
      Link: https://lkml.kernel.org/r/20201109192128.960-4-rppt@kernel.orgSigned-off-by: NMike Rapoport <rppt@linux.ibm.com>
      Acked-by: NDavid Hildenbrand <david@redhat.com>
      Acked-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Albert Ou <aou@eecs.berkeley.edu>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
      Cc: Heiko Carstens <hca@linux.ibm.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Palmer Dabbelt <palmer@dabbelt.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Paul Walmsley <paul.walmsley@sifive.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vasily Gorbik <gor@linux.ibm.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Will Deacon <will@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5d6ad668
  10. 12 12月, 2020 1 次提交
  11. 26 11月, 2020 1 次提交
  12. 21 11月, 2020 1 次提交
  13. 31 10月, 2020 1 次提交
    • A
      timekeeping: default GENERIC_CLOCKEVENTS to enabled · 0774a6ed
      Arnd Bergmann 提交于
      Almost all machines use GENERIC_CLOCKEVENTS, so it feels wrong to
      require each one to select that symbol manually.
      
      Instead, enable it whenever CONFIG_LEGACY_TIMER_TICK is disabled as
      a simplification. It should be possible to select both
      GENERIC_CLOCKEVENTS and LEGACY_TIMER_TICK from an architecture now
      and decide at runtime between the two.
      
      For the clockevents arch-support.txt file, this means that additional
      architectures are marked as TODO when they have at least one machine
      that still uses LEGACY_TIMER_TICK, rather than being marked 'ok' when
      at least one machine has been converted. This means that both m68k and
      arm (for riscpc) revert to TODO.
      
      At this point, we could just always enable CONFIG_GENERIC_CLOCKEVENTS
      rather than leaving it off when not needed. I built an m68k
      defconfig kernel (using gcc-10.1.0) and found that this would add
      around 5.5KB in kernel image size:
      
         text	   data	    bss	    dec	    hex	filename
      3861936	1092236	 196656	5150828	 4e986c	obj-m68k/vmlinux-no-clockevent
      3866201	1093832	 196184	5156217	 4ead79	obj-m68k/vmlinux-clockevent
      
      On Arm (MACH_RPC), that difference appears to be twice as large,
      around 11KB on top of an 6MB vmlinux.
      Reviewed-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Tested-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      0774a6ed
  14. 09 10月, 2020 1 次提交
  15. 05 10月, 2020 2 次提交
  16. 03 10月, 2020 3 次提交
  17. 20 9月, 2020 1 次提交
  18. 09 9月, 2020 1 次提交
  19. 21 8月, 2020 1 次提交
  20. 31 7月, 2020 7 次提交
  21. 10 7月, 2020 1 次提交
  22. 05 7月, 2020 1 次提交