linux-kernel - Re: [PATCH v1 00/24] Opt-in always-on nVHE hypervisor

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] [day] [month] [year] [list]

Message-ID: <CAE=NcraN8NcnJEneno=U6dPj3esHSjChfqu9XKLNPE49ULhxwQ@mail.gmail.com>
Date:   Tue, 19 Jan 2021 15:17:29 +0200
From:   Janne Karhunen <janne.karhunen@...il.com>
To:     Marc Zyngier <maz@...nel.org>
Cc:     Christoph Hellwig <hch@...radead.org>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Andrew Walbran <qwandor@...gle.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Will Deacon <will@...nel.org>, Tejun Heo <tj@...nel.org>,
        Dennis Zhou <dennis@...nel.org>,
        Christoph Lameter <cl@...ux.com>, kernel-team@...roid.com,
        kvmarm@...ts.cs.columbia.edu,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v1 00/24] Opt-in always-on nVHE hypervisor

On Tue, Nov 10, 2020 at 1:19 PM Marc Zyngier <maz@...nel.org> wrote:

> > Why?  I thought we were trying to kill nVHE off now that newer CPUs
> > provide the saner virtualization extensions?
>
> We can't kill nVHE at all, because that is the only game in town.
> You can't even buy a decent machine with VHE, no matter how much money
> you put on the table.

As I mentioned it earlier, we did this type of nVHE hypervisor and the
proof of concept is here:
https://github.com/jkrh/kvms

See the README. It runs successfully on multiple pieces of arm64
hardware and provides a tiny QEMU based development environment via
the makefiles for the QEMU 'max' CPU. The code is rough, the amount of
man hours put to it is not sky high, but it does run. I'll update a
new kernel patch to patches/ dir for one of the later kernels
hopefully next week, up to now we have only supported kernels between
4.9 .... 5.6 as this is what our development hardware(s) run with. It
requires a handful of hooks in the kvm code, but the actual kvm calls
are just rerouted back to the kernel symbols. This way the hypervisor
itself can be kept very tiny.

The s2 page tables are fully owned by the hyp and the guests are
unmapped from the host memory when configured with the option (we call
it host blinding). Multiple VMs can be run without pinning them into
the memory.  It also provides a tiny out of tree driver prototype stub
to protect the critical sections of the kernel memory beyond the
kernel's own reach. There are still holes in the implementation such
as the virtio-mapback handling via whitelisting and paging integrity
checks, and many things are not quite all the way there yet. One step
at a time.

--
Janne