linux-toradex.git/arch/arm64/xen, branch v4.16-rc3

arm64: kpti: Fix the interaction between ASID switching and software PAN

2018-01-16T17:37:48+00:00

With ARM64_SW_TTBR0_PAN enabled, the exception entry code checks the
active ASID to decide whether user access was enabled (non-zero ASID)
when the exception was taken. On return from exception, if user access
was previously disabled, it re-instates TTBR0_EL1 from the per-thread
saved value (updated in switch_mm() or efi_set_pgd()).

Commit 7655abb95386 ("arm64: mm: Move ASID from TTBR0 to TTBR1") makes a
TTBR0_EL1 + ASID switching non-atomic. Subsequently, commit 27a921e75711
("arm64: mm: Fix and re-enable ARM64_SW_TTBR0_PAN") changes the
__uaccess_ttbr0_disable() function and asm macro to first write the
reserved TTBR0_EL1 followed by the ASID=0 update in TTBR1_EL1. If an
exception occurs between these two, the exception return code will
re-instate a valid TTBR0_EL1. Similar scenario can happen in
cpu_switch_mm() between setting the reserved TTBR0_EL1 and the ASID
update in cpu_do_switch_mm().

This patch reverts the entry.S check for ASID == 0 to TTBR0_EL1 and
disables the interrupts around the TTBR0_EL1 and ASID switching code in
__uaccess_ttbr0_disable(). It also ensures that, when returning from the
EFI runtime services, efi_set_pgd() doesn't leave a non-zero ASID in
TTBR1_EL1 by using uaccess_ttbr0_{enable,disable}.

The accesses to current_thread_info()->ttbr0 are updated to use
READ_ONCE/WRITE_ONCE.

As a safety measure, __uaccess_ttbr0_enable() always masks out any
existing non-zero ASID TTBR1_EL1 before writing in the new ASID.

Fixes: 27a921e75711 ("arm64: mm: Fix and re-enable ARM64_SW_TTBR0_PAN")
Acked-by: Will Deacon 
Reported-by: Ard Biesheuvel 
Tested-by: Ard Biesheuvel 
Reviewed-by: James Morse 
Tested-by: James Morse 
Co-developed-by: Marc Zyngier 
Signed-off-by: Catalin Marinas

arm64: mm: Fix and re-enable ARM64_SW_TTBR0_PAN

2017-12-11T13:40:35+00:00

With the ASID now installed in TTBR1, we can re-enable ARM64_SW_TTBR0_PAN
by ensuring that we switch to a reserved ASID of zero when disabling
user access and restore the active user ASID on the uaccess enable path.

Reviewed-by: Mark Rutland 
Tested-by: Laura Abbott 
Tested-by: Shanker Donthineni 
Signed-off-by: Will Deacon

xen/privcmd: Add IOCTL_PRIVCMD_DM_OP

2017-02-14T20:13:43+00:00

Recently a new dm_op[1] hypercall was added to Xen to provide a mechanism
for restricting device emulators (such as QEMU) to a limited set of
hypervisor operations, and being able to audit those operations in the
kernel of the domain in which they run.

This patch adds IOCTL_PRIVCMD_DM_OP as gateway for __HYPERVISOR_dm_op.

NOTE: There is no requirement for user-space code to bounce data through
      locked memory buffers (as with IOCTL_PRIVCMD_HYPERCALL) since
      privcmd has enough information to lock the original buffers
      directly.

[1] http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=524a98c2

Signed-off-by: Paul Durrant 
Acked-by: Stefano Stabellini 
Signed-off-by: Boris Ostrovsky

arm64: don't pull uaccess.h into *.S

2016-12-26T18:05:17+00:00

Split asm-only parts of arm64 uaccess.h into a new header and use that
from *.S.

Signed-off-by: Al Viro

Replace with globally

2016-12-24T19:46:01+00:00

This was entirely automated, using the script by Al:

  PATT='^[[:blank:]]*#[[:blank:]]*include[[:blank:]]*'
  sed -i -e "s!$PATT!#include !" \
        $(git grep -l "$PATT"|grep -v ^include/linux/uaccess.h)

to do the replacement at the end of the merge window.

Requested-by: Al Viro 
Signed-off-by: Linus Torvalds

arm64: xen: Enable user access before a privcmd hvc call

2016-11-21T18:48:55+00:00

Privcmd calls are issued by the userspace. The kernel needs to enable
access to TTBR0_EL1 as the hypervisor would issue stage 1 translations
to user memory via AT instructions. Since AT instructions are not
affected by the PAN bit (ARMv8.1), we only need the explicit
uaccess_enable/disable if the TTBR0 PAN option is enabled.

Reviewed-by: Julien Grall 
Acked-by: Stefano Stabellini 
Cc: Will Deacon 
Cc: James Morse 
Cc: Kees Cook 
Cc: Mark Rutland 
Signed-off-by: Catalin Marinas

arm/xen: add support for vm_assist hypercall

2016-07-06T09:42:14+00:00

Add support for the Xen HYPERVISOR_vm_assist hypercall.

Signed-off-by: Juergen Gross 
Reviewed-by: Boris Ostrovsky 
Reviewed-by: Julien Grall 
Reviewed-by: Stefano Stabellini 
Signed-off-by: David Vrabel

ARM64: XEN: Add a function to initialize Xen specific UEFI runtime services

2016-07-06T09:34:46+00:00

When running on Xen hypervisor, runtime services are supported through
hypercall. Add a Xen specific function to initialize runtime services.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
Tested-by: Julien Grall 
Acked-by: Catalin Marinas

xen/arm: introduce HYPERVISOR_platform_op on arm and arm64

2015-12-21T14:40:56+00:00

Signed-off-by: Stefano Stabellini

arm: xen: implement multicall hypercall support.

2014-04-24T12:09:46+00:00

As part of this make the usual change to xen_ulong_t in place of unsigned long.
This change has no impact on x86.

The Linux definition of struct multicall_entry.result differs from the Xen
definition, I think for good reasons, and used a long rather than an unsigned
long. Therefore introduce a xen_long_t, which is a long on x86 architectures
and a signed 64-bit integer on ARM.

Use uint32_t nr_calls on x86 for consistency with the ARM definition.

Build tested on amd64 and i386 builds. Runtime tested on ARM.

Signed-off-by: Ian Campbell 
Cc: Stefano Stabellini 
Cc: Konrad Rzeszutek Wilk 
Cc: Boris Ostrovsky 
Signed-off-by: David Vrabel