linux-kernel - Re: [PATCH v17 6/6] KVM: arm64: Document MTE capability and ioctl

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <874kdqchlx.wl-maz@kernel.org>
Date:   Tue, 22 Jun 2021 11:35:06 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Fuad Tabba <tabba@...gle.com>
Cc:     Steven Price <steven.price@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        "Dr. David Alan Gilbert" <dgilbert@...hat.com>,
        qemu-devel@...gnu.org, Dave Martin <Dave.Martin@....com>,
        Juan Quintela <quintela@...hat.com>,
        Richard Henderson <richard.henderson@...aro.org>,
        linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
        kvmarm@...ts.cs.columbia.edu, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v17 6/6] KVM: arm64: Document MTE capability and ioctl

On Tue, 22 Jun 2021 10:42:42 +0100,
Fuad Tabba <tabba@...gle.com> wrote:
> 
> Hi,
> 
> 
> On Mon, Jun 21, 2021 at 12:18 PM Steven Price <steven.price@....com> wrote:
> >
> > A new capability (KVM_CAP_ARM_MTE) identifies that the kernel supports
> > granting a guest access to the tags, and provides a mechanism for the
> > VMM to enable it.
> >
> > A new ioctl (KVM_ARM_MTE_COPY_TAGS) provides a simple way for a VMM to
> > access the tags of a guest without having to maintain a PROT_MTE mapping
> > in userspace. The above capability gates access to the ioctl.
> >
> > Reviewed-by: Catalin Marinas <catalin.marinas@....com>
> > Signed-off-by: Steven Price <steven.price@....com>
> > ---
> >  Documentation/virt/kvm/api.rst | 61 ++++++++++++++++++++++++++++++++++
> >  1 file changed, 61 insertions(+)
> >
> > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> > index 7fcb2fd38f42..97661a97943f 100644
> > --- a/Documentation/virt/kvm/api.rst
> > +++ b/Documentation/virt/kvm/api.rst
> > @@ -5034,6 +5034,43 @@ see KVM_XEN_VCPU_SET_ATTR above.
> >  The KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_ADJUST type may not be used
> >  with the KVM_XEN_VCPU_GET_ATTR ioctl.
> >
> > +4.130 KVM_ARM_MTE_COPY_TAGS
> > +---------------------------
> > +
> > +:Capability: KVM_CAP_ARM_MTE
> > +:Architectures: arm64
> > +:Type: vm ioctl
> > +:Parameters: struct kvm_arm_copy_mte_tags
> > +:Returns: number of bytes copied, < 0 on error (-EINVAL for incorrect
> > +          arguments, -EFAULT if memory cannot be accessed).
> > +
> > +::
> > +
> > +  struct kvm_arm_copy_mte_tags {
> > +       __u64 guest_ipa;
> > +       __u64 length;
> > +       void __user *addr;
> > +       __u64 flags;
> > +       __u64 reserved[2];
> > +  };
> > +
> > +Copies Memory Tagging Extension (MTE) tags to/from guest tag memory. The
> > +``guest_ipa`` and ``length`` fields must be ``PAGE_SIZE`` aligned. The ``addr``
> > +field must point to a buffer which the tags will be copied to or from.
> > +
> > +``flags`` specifies the direction of copy, either ``KVM_ARM_TAGS_TO_GUEST`` or
> > +``KVM_ARM_TAGS_FROM_GUEST``.
> > +
> > +The size of the buffer to store the tags is ``(length / 16)`` bytes
> > +(granules in MTE are 16 bytes long). Each byte contains a single tag
> > +value. This matches the format of ``PTRACE_PEEKMTETAGS`` and
> > +``PTRACE_POKEMTETAGS``.
> > +
> > +If an error occurs before any data is copied then a negative error code is
> > +returned. If some tags have been copied before an error occurs then the number
> > +of bytes successfully copied is returned. If the call completes successfully
> > +then ``length`` is returned.
> > +
> >  5. The kvm_run structure
> >  ========================
> >
> > @@ -6362,6 +6399,30 @@ default.
> >
> >  See Documentation/x86/sgx/2.Kernel-internals.rst for more details.
> >
> > +7.26 KVM_CAP_ARM_MTE
> > +--------------------
> > +
> > +:Architectures: arm64
> > +:Parameters: none
> > +
> > +This capability indicates that KVM (and the hardware) supports exposing the
> > +Memory Tagging Extensions (MTE) to the guest. It must also be enabled by the
> > +VMM before creating any VCPUs to allow the guest access. Note that MTE is only
> > +available to a guest running in AArch64 mode and enabling this capability will
> > +cause attempts to create AArch32 VCPUs to fail.
> 
> I was wondering if there might be an issue with AArch32 at EL0 and
> MTE, because I think that even if AArch64 at EL1 is disallowed, the

Did you mean AArch32 here?

> guest can still run AArch32 at EL0.

I don't get your question:

- If the guest is AArch32 at EL1, there is not MTE whatsoever (where
  would you place the tag?)

- If the guest is AArch64, it can have MTE enabled or not,
  irrespective of the EL. If this guest decides to run an AArch32 EL0,
  the architecture rules still apply, and it cannot expose MTE to its
  own 32bit userspace. Nothing that KVM needs to do about this.

What KVM enforces is that at the point where the guest is in charge,
we have a consistent architectural behaviour.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.