Re: [PATCH v4 1/2] arm64: kvm: Save/restore MTE registers

From: Steven Price
Date: Thu Nov 19 2020 - 07:46:31 EST


On 18/11/2020 17:02, Catalin Marinas wrote:
On Wed, Nov 18, 2020 at 04:01:18PM +0000, Steven Price wrote:
On 17/11/2020 19:20, Marc Zyngier wrote:
On 2020-10-26 15:57, Steven Price wrote:
diff --git a/arch/arm64/include/asm/sysreg.h
b/arch/arm64/include/asm/sysreg.h
index d52c1b3ce589..7727df0bc09d 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -565,7 +565,8 @@
�#define SCTLR_ELx_M��� (BIT(0))

�#define SCTLR_ELx_FLAGS��� (SCTLR_ELx_M� | SCTLR_ELx_A | SCTLR_ELx_C | \
-������������ SCTLR_ELx_SA | SCTLR_ELx_I | SCTLR_ELx_IESB)
+������������ SCTLR_ELx_SA | SCTLR_ELx_I | SCTLR_ELx_IESB | \
+������������ SCTLR_ELx_ITFSB)

�/* SCTLR_EL2 specific flags. */
�#define SCTLR_EL2_RES1��� ((BIT(4))� | (BIT(5))� | (BIT(11)) |
(BIT(16)) | \
diff --git a/arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h
b/arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h
index 7a986030145f..a124ffa49ba3 100644
--- a/arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h
+++ b/arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h
@@ -18,6 +18,11 @@
�static inline void __sysreg_save_common_state(struct
kvm_cpu_context *ctxt)
�{
���� ctxt_sys_reg(ctxt, MDSCR_EL1)��� = read_sysreg(mdscr_el1);
+��� if (system_supports_mte()) {
+������� ctxt_sys_reg(ctxt, RGSR_EL1)��� = read_sysreg_s(SYS_RGSR_EL1);
+������� ctxt_sys_reg(ctxt, GCR_EL1)��� = read_sysreg_s(SYS_GCR_EL1);
+������� ctxt_sys_reg(ctxt, TFSRE0_EL1)��� =
read_sysreg_s(SYS_TFSRE0_EL1);

As far as I can tell, HCR_EL2.ATA is still clear when running a guest.
So why, do we save/restore this state yet?

Also, I wonder whether we should keep these in the C code. If one day
we enable MTE in the kernel, we will have to move them to the assembly
part, much like we do for PAuth. And I fear that "one day" is pretty
soon:

https://lore.kernel.org/linux-arm-kernel/cover.1605046192.git.andreyknvl@xxxxxxxxxx/

Good point. Although for MTE we do have the option of setting TCO in PSTATE
so this could remain in C if we're not bothered about the 'gap' in KASAN
coverage. I haven't yet got my head around how (or indeed if) that series
handles guests.

I think we should be fine with the currently proposed in-kernel MTE
support. However, setting GCR_EL1 can get in the way if stack tagging is
ever enabled (it breaks single image). The compiler uses GCR_EL1 to
generate different colours for variables on the stack and changing it in
the middle of a function may cause confusion. You'd have to set
PSTATE.TCO for the whole function, either from the caller or, if the
compiler gets smarter, some function attribute.


If the compiler might start playing with TCO then this could also be an issue for VMMs which will (at least with the current design) need to use TCO to safely access guest memory. Especially if we enforce PROT_MTE mappings for the VMM.

Steve