1. 30 11月, 2019 1 次提交
    • I
      s390: implement perf_arch_fetch_caller_regs · 914d52e4
      Ilya Leoshkevich 提交于
      On s390 bpf_get_stack_raw_tp() returns 0 entries for both kernel and
      user stacks. While there is no practical unwinding solution for userspace
      on s390 at this moment, there certainly is a kernel unwinder. However,
      it is not properly integrated with BPF.
      
      In order to start unwinding, bpf_get_stack_raw_tp() obtains the current
      kernel register values using perf_fetch_caller_regs(), which is not
      implemented for s390. The actual unwinding then happens by passing those
      registers to perf_callchain_kernel().
      
      Implement perf_arch_fetch_caller_regs() for s390, where
      __builtin_frame_address(0) points to back_chain.
      Signed-off-by: NIlya Leoshkevich <iii@linux.ibm.com>
      Acked-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
      914d52e4
  2. 21 11月, 2019 3 次提交
    • P
      arm64: uaccess: Remove uaccess_*_not_uao asm macros · e50be648
      Pavel Tatashin 提交于
      It is safer and simpler to drop the uaccess assembly macros in favour of
      inline C functions. Although this bloats the Image size slightly, it
      aligns our user copy routines with '{get,put}_user()' and generally
      makes the code a lot easier to reason about.
      
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: NMark Rutland <mark.rutland@arm.com>
      Tested-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NPavel Tatashin <pasha.tatashin@soleen.com>
      [will: tweaked commit message and changed temporary variable names]
      Signed-off-by: NWill Deacon <will@kernel.org>
      e50be648
    • P
      arm64: uaccess: Ensure PAN is re-enabled after unhandled uaccess fault · 94bb804e
      Pavel Tatashin 提交于
      A number of our uaccess routines ('__arch_clear_user()' and
      '__arch_copy_{in,from,to}_user()') fail to re-enable PAN if they
      encounter an unhandled fault whilst accessing userspace.
      
      For CPUs implementing both hardware PAN and UAO, this bug has no effect
      when both extensions are in use by the kernel.
      
      For CPUs implementing hardware PAN but not UAO, this means that a kernel
      using hardware PAN may execute portions of code with PAN inadvertently
      disabled, opening us up to potential security vulnerabilities that rely
      on userspace access from within the kernel which would usually be
      prevented by this mechanism. In other words, parts of the kernel run the
      same way as they would on a CPU without PAN implemented/emulated at all.
      
      For CPUs not implementing hardware PAN and instead relying on software
      emulation via 'CONFIG_ARM64_SW_TTBR0_PAN=y', the impact is unfortunately
      much worse. Calling 'schedule()' with software PAN disabled means that
      the next task will execute in the kernel using the page-table and ASID
      of the previous process even after 'switch_mm()', since the actual
      hardware switch is deferred until return to userspace. At this point, or
      if there is a intermediate call to 'uaccess_enable()', the page-table
      and ASID of the new process are installed. Sadly, due to the changes
      introduced by KPTI, this is not an atomic operation and there is a very
      small window (two instructions) where the CPU is configured with the
      page-table of the old task and the ASID of the new task; a speculative
      access in this state is disastrous because it would corrupt the TLB
      entries for the new task with mappings from the previous address space.
      
      As Pavel explains:
      
        | I was able to reproduce memory corruption problem on Broadcom's SoC
        | ARMv8-A like this:
        |
        | Enable software perf-events with PERF_SAMPLE_CALLCHAIN so userland's
        | stack is accessed and copied.
        |
        | The test program performed the following on every CPU and forking
        | many processes:
        |
        |	unsigned long *map = mmap(NULL, PAGE_SIZE, PROT_READ|PROT_WRITE,
        |				  MAP_SHARED | MAP_ANONYMOUS, -1, 0);
        |	map[0] = getpid();
        |	sched_yield();
        |	if (map[0] != getpid()) {
        |		fprintf(stderr, "Corruption detected!");
        |	}
        |	munmap(map, PAGE_SIZE);
        |
        | From time to time I was getting map[0] to contain pid for a
        | different process.
      
      Ensure that PAN is re-enabled when returning after an unhandled user
      fault from our uaccess routines.
      
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: NMark Rutland <mark.rutland@arm.com>
      Tested-by: NMark Rutland <mark.rutland@arm.com>
      Cc: <stable@vger.kernel.org>
      Fixes: 338d4f49 ("arm64: kernel: Add support for Privileged Access Never")
      Signed-off-by: NPavel Tatashin <pasha.tatashin@soleen.com>
      [will: rewrote commit message]
      Signed-off-by: NWill Deacon <will@kernel.org>
      94bb804e
    • T
      s390/cpumf: Adjust registration of s390 PMU device drivers · 6a82e23f
      Thomas Richter 提交于
      Linux-next commit titled "perf/core: Optimize perf_init_event()"
      changed the semantics of PMU device driver registration.
      It was done to speed up the lookup/handling of PMU device driver
      specific events. It also enforces that only one PMU device
      driver will be registered of type PERF_EVENT_RAW.
      
      This change added these line in function perf_pmu_register():
      
        ...
        +       ret = idr_alloc(&pmu_idr, pmu, max, 0, GFP_KERNEL);
        +       if (ret < 0)
                      goto free_pdc;
        +
        +       WARN_ON(type >= 0 && ret != type);
      
      The warn_on generates a message. We have 3 PMU device drivers,
      each registered as type PERF_TYPE_RAW.
      The cf_diag device driver (arch/s390/kernel/perf_cpumf_cf_diag.c)
      always hits the WARN_ON because it is the second PMU device driver
      (after sampling device driver arch/s390/kernel/perf_cpumf_sf.c)
      which is registered as type 4 (PERF_TYPE_RAW).
      So when the sampling device driver is registered, ret has value 4.
      When cf_diag device driver is registered with type 4,
      ret has value of 5 and WARN_ON fires.
      
      Adjust the PMU device drivers for s390 to support the new
      semantics required by perf_pmu_register().
      Signed-off-by: NThomas Richter <tmricht@linux.ibm.com>
      Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
      6a82e23f
  3. 20 11月, 2019 6 次提交
  4. 14 11月, 2019 3 次提交
    • S
      KVM: x86/mmu: Take slots_lock when using kvm_mmu_zap_all_fast() · ed69a6cb
      Sean Christopherson 提交于
      Acquire the per-VM slots_lock when zapping all shadow pages as part of
      toggling nx_huge_pages.  The fast zap algorithm relies on exclusivity
      (via slots_lock) to identify obsolete vs. valid shadow pages, because it
      uses a single bit for its generation number. Holding slots_lock also
      obviates the need to acquire a read lock on the VM's srcu.
      
      Failing to take slots_lock when toggling nx_huge_pages allows multiple
      instances of kvm_mmu_zap_all_fast() to run concurrently, as the other
      user, KVM_SET_USER_MEMORY_REGION, does not take the global kvm_lock.
      (kvm_mmu_zap_all_fast() does take kvm->mmu_lock, but it can be
      temporarily dropped by kvm_zap_obsolete_pages(), so it is not enough
      to enforce exclusivity).
      
      Concurrent fast zap instances causes obsolete shadow pages to be
      incorrectly identified as valid due to the single bit generation number
      wrapping, which results in stale shadow pages being left in KVM's MMU
      and leads to all sorts of undesirable behavior.
      The bug is easily confirmed by running with CONFIG_PROVE_LOCKING and
      toggling nx_huge_pages via its module param.
      
      Note, until commit 4ae5acbc4936 ("KVM: x86/mmu: Take slots_lock when
      using kvm_mmu_zap_all_fast()", 2019-11-13) the fast zap algorithm used
      an ulong-sized generation instead of relying on exclusivity for
      correctness, but all callers except the recently added set_nx_huge_pages()
      needed to hold slots_lock anyways.  Therefore, this patch does not have
      to be backported to stable kernels.
      
      Given that toggling nx_huge_pages is by no means a fast path, force it
      to conform to the current approach instead of reintroducing the previous
      generation count.
      
      Fixes: b8e8c830 ("kvm: mmu: ITLB_MULTIHIT mitigation", but NOT FOR STABLE)
      Signed-off-by: NSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      ed69a6cb
    • M
      sparc: vdso: fix build error of vdso32 · 53472914
      Masahiro Yamada 提交于
      Since commit 54b8ae66 ("kbuild: change *FLAGS_<basetarget>.o to
      take the path relative to $(obj)"), sparc allmodconfig fails to build
      as follows:
      
        CC      arch/sparc/vdso/vdso32/vclock_gettime.o
      unrecognized e_machine 18 arch/sparc/vdso/vdso32/vclock_gettime.o
      arch/sparc/vdso/vdso32/vclock_gettime.o: failed
      
      The cause of the breakage is that -pg flag not being dropped.
      
      The vdso32 files are located in the vdso32/ subdirectory, but I missed
      to update the Makefile.
      
      I removed the meaningless CFLAGS_REMOVE_vdso-note.o since it is only
      effective for C file.
      
      vdso-note.o is compiled from assembly file:
      
        arch/sparc/vdso/vdso-note.S
        arch/sparc/vdso/vdso32/vdso-note.S
      
      Fixes: 54b8ae66 ("kbuild: change *FLAGS_<basetarget>.o to take the path relative to $(obj)")
      Reported-by: NAnatoly Pugachev <matorola@gmail.com>
      Reported-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Tested-by: NAnatoly Pugachev <matorola@gmail.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      53472914
    • A
      arm64: Kconfig: add a choice for endianness · d8e85e14
      Anders Roxell 提交于
      When building allmodconfig KCONFIG_ALLCONFIG=$(pwd)/arch/arm64/configs/defconfig
      CONFIG_CPU_BIG_ENDIAN gets enabled. Which tends not to be what most
      people want. Another concern that has come up is that ACPI isn't built
      for an allmodconfig kernel today since that also depends on !CPU_BIG_ENDIAN.
      
      Rework so that we introduce a 'choice' and default the choice to
      CPU_LITTLE_ENDIAN. That means that when we build an allmodconfig kernel
      it will default to CPU_LITTLE_ENDIAN that most people tends to want.
      Reviewed-by: NJohn Garry <john.garry@huawei.com>
      Acked-by: NWill Deacon <will@kernel.org>
      Signed-off-by: NAnders Roxell <anders.roxell@linaro.org>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      d8e85e14
  5. 13 11月, 2019 3 次提交
  6. 12 11月, 2019 12 次提交
  7. 09 11月, 2019 2 次提交
    • M
      arm64: kaslr: Check command line before looking for a seed · 2203e1ad
      Mark Brown 提交于
      Now that we print diagnostics at boot the reason why we do not initialise
      KASLR matters. Currently we check for a seed before we check if the user
      has explicitly disabled KASLR on the command line which will result in
      misleading diagnostics so reverse the order of those checks. We still
      parse the seed from the DT early so that if the user has both provided a
      seed and disabled KASLR on the command line we still mask the seed on
      the command line.
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Acked-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      2203e1ad
    • M
      arm64: kaslr: Announce KASLR status on boot · 294a9ddd
      Mark Brown 提交于
      Currently the KASLR code is silent at boot unless it forces on KPTI in
      which case a message will be printed for that. This can lead to users
      incorrectly believing their system has the feature enabled when it in
      fact does not, and if they notice the problem the lack of any
      diagnostics makes it harder to understand the problem. Add an initcall
      which prints a message showing the status of KASLR during boot to make
      the status clear.
      
      This is particularly useful in cases where we don't have a seed. It
      seems to be a relatively common error for system integrators and
      administrators to enable KASLR in their configuration but not provide
      the seed at runtime, often due to seed provisioning breaking at some
      later point after it is initially enabled and verified.
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Acked-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      294a9ddd
  8. 07 11月, 2019 3 次提交
  9. 06 11月, 2019 7 次提交
    • M
      arm64: ftrace: minimize ifdeffery · 7f08ae53
      Mark Rutland 提交于
      Now that we no longer refer to mod->arch.ftrace_trampolines in the body
      of ftrace_make_call(), we can use IS_ENABLED() rather than ifdeffery,
      and make the code easier to follow. Likewise in ftrace_make_nop().
      
      Let's do so.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: NTorsten Duwe <duwe@suse.de>
      Tested-by: NAmit Daniel Kachhap <amit.kachhap@arm.com>
      Tested-by: NTorsten Duwe <duwe@suse.de>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will@kernel.org>
      7f08ae53
    • T
      arm64: implement ftrace with regs · 3b23e499
      Torsten Duwe 提交于
      This patch implements FTRACE_WITH_REGS for arm64, which allows a traced
      function's arguments (and some other registers) to be captured into a
      struct pt_regs, allowing these to be inspected and/or modified. This is
      a building block for live-patching, where a function's arguments may be
      forwarded to another function. This is also necessary to enable ftrace
      and in-kernel pointer authentication at the same time, as it allows the
      LR value to be captured and adjusted prior to signing.
      
      Using GCC's -fpatchable-function-entry=N option, we can have the
      compiler insert a configurable number of NOPs between the function entry
      point and the usual prologue. This also ensures functions are AAPCS
      compliant (e.g. disabling inter-procedural register allocation).
      
      For example, with -fpatchable-function-entry=2, GCC 8.1.0 compiles the
      following:
      
      | unsigned long bar(void);
      |
      | unsigned long foo(void)
      | {
      |         return bar() + 1;
      | }
      
      ... to:
      
      | <foo>:
      |         nop
      |         nop
      |         stp     x29, x30, [sp, #-16]!
      |         mov     x29, sp
      |         bl      0 <bar>
      |         add     x0, x0, #0x1
      |         ldp     x29, x30, [sp], #16
      |         ret
      
      This patch builds the kernel with -fpatchable-function-entry=2,
      prefixing each function with two NOPs. To trace a function, we replace
      these NOPs with a sequence that saves the LR into a GPR, then calls an
      ftrace entry assembly function which saves this and other relevant
      registers:
      
      | mov	x9, x30
      | bl	<ftrace-entry>
      
      Since patchable functions are AAPCS compliant (and the kernel does not
      use x18 as a platform register), x9-x18 can be safely clobbered in the
      patched sequence and the ftrace entry code.
      
      There are now two ftrace entry functions, ftrace_regs_entry (which saves
      all GPRs), and ftrace_entry (which saves the bare minimum). A PLT is
      allocated for each within modules.
      Signed-off-by: NTorsten Duwe <duwe@suse.de>
      [Mark: rework asm, comments, PLTs, initialization, commit message]
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Reviewed-by: NAmit Daniel Kachhap <amit.kachhap@arm.com>
      Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: NTorsten Duwe <duwe@suse.de>
      Tested-by: NAmit Daniel Kachhap <amit.kachhap@arm.com>
      Tested-by: NTorsten Duwe <duwe@suse.de>
      Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Julien Thierry <jthierry@redhat.com>
      Cc: Will Deacon <will@kernel.org>
      3b23e499
    • M
      arm64: asm-offsets: add S_FP · 1f377e04
      Mark Rutland 提交于
      So that assembly code can more easily manipulate the FP (x29) within a
      pt_regs, add an S_FP asm-offsets definition.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: NTorsten Duwe <duwe@suse.de>
      Tested-by: NAmit Daniel Kachhap <amit.kachhap@arm.com>
      Tested-by: NTorsten Duwe <duwe@suse.de>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will@kernel.org>
      1f377e04
    • M
      arm64: insn: add encoder for MOV (register) · e3bf8a67
      Mark Rutland 提交于
      For FTRACE_WITH_REGS, we're going to want to generate a MOV (register)
      instruction as part of the callsite intialization. As MOV (register) is
      an alias for ORR (shifted register), we can generate this with
      aarch64_insn_gen_logical_shifted_reg(), but it's somewhat verbose and
      difficult to read in-context.
      
      Add a aarch64_insn_gen_move_reg() wrapper for this case so that we can
      write callers in a more straightforward way.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: NTorsten Duwe <duwe@suse.de>
      Tested-by: NAmit Daniel Kachhap <amit.kachhap@arm.com>
      Tested-by: NTorsten Duwe <duwe@suse.de>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will@kernel.org>
      e3bf8a67
    • M
      arm64: module/ftrace: intialize PLT at load time · f1a54ae9
      Mark Rutland 提交于
      Currently we lazily-initialize a module's ftrace PLT at runtime when we
      install the first ftrace call. To do so we have to apply a number of
      sanity checks, transiently mark the module text as RW, and perform an
      IPI as part of handling Neoverse-N1 erratum #1542419.
      
      We only expect the ftrace trampoline to point at ftrace_caller() (AKA
      FTRACE_ADDR), so let's simplify all of this by intializing the PLT at
      module load time, before the module loader marks the module RO and
      performs the intial I-cache maintenance for the module.
      
      Thus we can rely on the module having been correctly intialized, and can
      simplify the runtime work necessary to install an ftrace call in a
      module. This will also allow for the removal of module_disable_ro().
      
      Tested by forcing ftrace_make_call() to use the module PLT, and then
      loading up a module after setting up ftrace with:
      
      | echo ":mod:<module-name>" > set_ftrace_filter;
      | echo function > current_tracer;
      | modprobe <module-name>
      
      Since FTRACE_ADDR is only defined when CONFIG_DYNAMIC_FTRACE is
      selected, we wrap its use along with most of module_init_ftrace_plt()
      with ifdeffery rather than using IS_ENABLED().
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Reviewed-by: NAmit Daniel Kachhap <amit.kachhap@arm.com>
      Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: NTorsten Duwe <duwe@suse.de>
      Tested-by: NAmit Daniel Kachhap <amit.kachhap@arm.com>
      Tested-by: NTorsten Duwe <duwe@suse.de>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: James Morse <james.morse@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Will Deacon <will@kernel.org>
      f1a54ae9
    • M
      arm64: module: rework special section handling · bd8b21d3
      Mark Rutland 提交于
      When we load a module, we have to perform some special work for a couple
      of named sections. To do this, we iterate over all of the module's
      sections, and perform work for each section we recognize.
      
      To make it easier to handle the unexpected absence of a section, and to
      make the section-specific logic easer to read, let's factor the section
      search into a helper. Similar is already done in the core module loader,
      and other architectures (and ideally we'd unify these in future).
      
      If we expect a module to have an ftrace trampoline section, but it
      doesn't have one, we'll now reject loading the module. When
      ARM64_MODULE_PLTS is selected, any correctly built module should have
      one (and this is assumed by arm64's ftrace PLT code) and the absence of
      such a section implies something has gone wrong at build time.
      
      Subsequent patches will make use of the new helper.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: NTorsten Duwe <duwe@suse.de>
      Tested-by: NAmit Daniel Kachhap <amit.kachhap@arm.com>
      Tested-by: NTorsten Duwe <duwe@suse.de>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: James Morse <james.morse@arm.com>
      Cc: Will Deacon <will@kernel.org>
      bd8b21d3
    • M
      module/ftrace: handle patchable-function-entry · a1326b17
      Mark Rutland 提交于
      When using patchable-function-entry, the compiler will record the
      callsites into a section named "__patchable_function_entries" rather
      than "__mcount_loc". Let's abstract this difference behind a new
      FTRACE_CALLSITE_SECTION, so that architectures don't have to handle this
      explicitly (e.g. with custom module linker scripts).
      
      As parisc currently handles this explicitly, it is fixed up accordingly,
      with its custom linker script removed. Since FTRACE_CALLSITE_SECTION is
      only defined when DYNAMIC_FTRACE is selected, the parisc module loading
      code is updated to only use the definition in that case. When
      DYNAMIC_FTRACE is not selected, modules shouldn't have this section, so
      this removes some redundant work in that case.
      
      To make sure that this is keep up-to-date for modules and the main
      kernel, a comment is added to vmlinux.lds.h, with the existing ifdeffery
      simplified for legibility.
      
      I built parisc generic-{32,64}bit_defconfig with DYNAMIC_FTRACE enabled,
      and verified that the section made it into the .ko files for modules.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Acked-by: NHelge Deller <deller@gmx.de>
      Acked-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: NTorsten Duwe <duwe@suse.de>
      Tested-by: NAmit Daniel Kachhap <amit.kachhap@arm.com>
      Tested-by: NSven Schnelle <svens@stackframe.org>
      Tested-by: NTorsten Duwe <duwe@suse.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
      Cc: Jessica Yu <jeyu@kernel.org>
      Cc: linux-parisc@vger.kernel.org
      a1326b17
反馈
建议
客服 返回
顶部