1. 25 Jan, 2016 4 commits
    • Catalin Marinas's avatar
      arm64: Honour !PTE_WRITE in set_pte_at() for kernel mappings · ac15bd63
      Catalin Marinas authored
      Currently, set_pte_at() only checks the software PTE_WRITE bit for user
      mappings when it sets or clears the hardware PTE_RDONLY accordingly. The
      kernel ptes are written directly without any modification, relying
      solely on the protection bits in macros like PAGE_KERNEL. However,
      modifying kernel pte attributes via pte_wrprotect() would be ignored by
      set_pte_at(). Since pte_wrprotect() does not set PTE_RDONLY (it only
      clears PTE_WRITE), the new permission is not taken into account.
      
      This patch changes set_pte_at() to adjust the read-only permission for
      kernel ptes as well. As a side effect, existing PROT_* definitions used
      for kernel ioremap*() need to include PTE_DIRTY | PTE_WRITE.
      
      (additionally, white space fix for PTE_KERNEL_ROX)
      Acked-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Tested-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Reported-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      ac15bd63
    • Lorenzo Pieralisi's avatar
      arm64: kernel: fix architected PMU registers unconditional access · f436b2ac
      Lorenzo Pieralisi authored
      The Performance Monitors extension is an optional feature of the
      AArch64 architecture, therefore, in order to access Performance
      Monitors registers safely, the kernel should detect the architected
      PMU unit presence through the ID_AA64DFR0_EL1 register PMUVer field
      before accessing them.
      
      This patch implements a guard by reading the ID_AA64DFR0_EL1 register
      PMUVer field to detect the architected PMU presence and prevent accessing
      PMU system registers if the Performance Monitors extension is not
      implemented in the core.
      
      Cc: Peter Maydell <peter.maydell@linaro.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: <stable@vger.kernel.org>
      Fixes: 60792ad3 ("arm64: kernel: enforce pmuserenr_el0 initialization and restore")
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Reported-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Tested-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      f436b2ac
    • Ard Biesheuvel's avatar
      arm64: kasan: ensure that the KASAN zero page is mapped read-only · 7b1af979
      Ard Biesheuvel authored
      When switching from the early KASAN shadow region, which maps the
      entire shadow space read-write, to the permanent KASAN shadow region,
      which uses a zero page to shadow regions that are not subject to
      instrumentation, the lowest level table kasan_zero_pte[] may be
      reused unmodified, which means that the mappings of the zero page
      that it contains will still be read-write.
      
      So update it explicitly to map the zero page read only when we
      activate the permanent mapping.
      Acked-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      7b1af979
    • Ard Biesheuvel's avatar
      arm64: hide __efistub_ aliases from kallsyms · 75feee3d
      Ard Biesheuvel authored
      Commit e8f3010f ("arm64/efi: isolate EFI stub from the kernel
      proper") isolated the EFI stub code from the kernel proper by prefixing
      all of its symbols with __efistub_, and selectively allowing access to
      core kernel symbols from the stub by emitting __efistub_ aliases for
      functions and variables that the stub can access legally.
      
      As an unintended side effect, these aliases are emitted into the
      kallsyms symbol table, which means they may turn up in backtraces,
      e.g.,
      
        ...
        PC is at __efistub_memset+0x108/0x200
        LR is at fixup_init+0x3c/0x48
        ...
        [<ffffff8008328608>] __efistub_memset+0x108/0x200
        [<ffffff8008094dcc>] free_initmem+0x2c/0x40
        [<ffffff8008645198>] kernel_init+0x20/0xe0
        [<ffffff8008085cd0>] ret_from_fork+0x10/0x40
      
      The backtrace in question has nothing to do with the EFI stub, but
      simply returns one of the several aliases of memset() that have been
      recorded in the kallsyms table. This is undesirable, since it may
      suggest to people who are not aware of this that the issue they are
      seeing is somehow EFI related.
      
      So hide the __efistub_ aliases from kallsyms, by emitting them as
      absolute linker symbols explicitly. The distinction between those
      and section relative symbols is completely irrelevant to these
      definitions, and to the final link we are performing when these
      definitions are being taken into account (the distinction is only
      relevant to symbols defined inside a section definition when performing
      a partial link), and so the resulting values are identical to the
      original ones. Since absolute symbols are ignored by kallsyms, this
      will result in these values to be omitted from its symbol table.
      
      After this patch, the backtrace generated from the same address looks
      like this:
        ...
        PC is at __memset+0x108/0x200
        LR is at fixup_init+0x3c/0x48
        ...
        [<ffffff8008328608>] __memset+0x108/0x200
        [<ffffff8008094dcc>] free_initmem+0x2c/0x40
        [<ffffff8008645198>] kernel_init+0x20/0xe0
        [<ffffff8008085cd0>] ret_from_fork+0x10/0x40
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      75feee3d
  2. 24 Jan, 2016 36 commits