linux-kernel - Re: [PATCH v5 0/2] MTE support for KVM guest

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: <8c39b104-39c3-7cca-82b9-2e47d7cb9a9a@linaro.org>
Date:   Wed, 9 Dec 2020 12:27:59 -0600
From:   Richard Henderson <richard.henderson@...aro.org>
To:     Catalin Marinas <catalin.marinas@....com>,
        Marc Zyngier <maz@...nel.org>
Cc:     Steven Price <steven.price@....com>,
        Peter Maydell <peter.maydell@...aro.org>,
        Haibo Xu <haibo.xu@...aro.org>,
        lkml - Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Juan Quintela <quintela@...hat.com>,
        QEMU Developers <qemu-devel@...gnu.org>,
        "Dr. David Alan Gilbert" <dgilbert@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Will Deacon <will@...nel.org>,
        kvmarm <kvmarm@...ts.cs.columbia.edu>,
        arm-mail-list <linux-arm-kernel@...ts.infradead.org>,
        Dave Martin <Dave.Martin@....com>
Subject: Re: [PATCH v5 0/2] MTE support for KVM guest

On 12/9/20 9:27 AM, Catalin Marinas wrote:
> On Wed, Dec 09, 2020 at 01:25:18PM +0000, Marc Zyngier wrote:
>> Would this syscall operate on the guest address space? Or on the VMM's
>> own mapping?
...
> Whatever is easier for the VMM, I don't think it matters as long as the
> host kernel can get the actual physical address (and linear map
> correspondent). Maybe simpler if it's the VMM address space as the
> kernel can check the access permissions in case you want to hide the
> guest memory from the VMM for other reasons (migration is also off the
> table).

Indeed, such a syscall is no longer specific to vmm's and may be used for any
bulk move of tags that userland might want.

> Without syscalls, an option would be for the VMM to create two mappings:
> one with PROT_MTE for migration and the other without for normal DMA
> etc. That's achievable using memfd_create() or shm_open() and two mmap()
> calls, only one having PROT_MTE. The VMM address space should be
> sufficiently large to map two guest IPAs.

I would have thought that the best way is to use TCO, so that we don't have to
have dual mappings (and however many MB of extra page tables that might imply).


r~