First, I'd like to say that this wmail is not meant to discourage you.
HW-assisted virtualization in Redox *would* be cool, and I hope to see
it implemented some day.
... I do have some critical points though, and I think that this
hypothetical hypervisor framework will be years in the future.
So discussion in a QubesOS context IMHO primarily makes sense to collect
ideas and feature requirements for the design.
On 04/04/2018 07:12 AM, Scott Tankard wrote:
> Le jeudi 8 février 2018 22:27:58 UTC-8, TimW a écrit :
>> what would KVM be bringing to the table in terms of benefits compared to Xen. I see a list of what Xen does well (why it was initially chosen) and what KVM still can not do or do as well as Xen. But what benefits does KVM bring that Xen does not? As the opening topic was security how does KVM stack up in terms of its history and prowess in security compared to Xen
> So the actual replacement that I have had in mind, is Redox+KVM. (Or another microkernel similar to Redox.) I have been ignoring Linux+KVM, as Linux's security record is (compared to Xen) terrible.
There's a IllumOS/SmartOS port of KVM (since 2011, so without knowing
many details I assume it's fairly mature now):
https://lwn.net/Articles/459754/
They even have package signing, so much harder to compromise than your
average Rust user. :-)
> The perceived security benefits of Redox+KVM over Xen would be:
> - dramatically smaller overall TCB
Which has seen much less review than Xen, and implemented by people with
less knowledge about x86_64 virtualization than the Xen crowd.
This will no doubt improve over the years as the Rust implementation
matures, but again, it will take some years to beat this into shape.
> - better organizational prioritization of security
This is sort of in the category "would be nice, will take a lot of work
to get there." For instance the organization to host such organizational
priorities is still just an idea, and in practice establishing a
resilient, friendly community with a focus on security has proven a
non-trivial problem to solve.
I think the QubesOS, the HardenedBSD, and the Genode communities are
worth looking at, since they have somehow managed to establish this in a
not-too-corporate setting. I don't know how the Rust/Redox camps are
doing in this regard, but I hope you have a nice community, too! :-)
Linux/KVM, on the other hand, seems kind of toxic to me (that is my
subjective impression as a passive observer), and the Xen thing seems to
have a quite corporate focus.
> This is all very hypothetical (especially the third point), as Redox is not yet a mature/stable project.
>
> Aside: I noted that many of the research papers on hardening Xen basically reimplement microkernel design considerations. (They do things like segment Xen internally, bringing it closer to a microkernel design.)
>
> There are basically very few "industrial-grade" hypervisors (that have a large enough user base, developer base, and socioeconomic pressure and resources to maintain them secure and featureful...).
> There's VMWare, Xen and KVM. You could maybe add Hyper-V and Bhyve.
VMWare and Hyper-V aren't libre software, so they're out. That leaves
Xen, KVM, and Bhyve.
I'd say Muen SK is more promising than the hypothetical changes to Redox
- the Muen SK people already have running code; boots on the ground, and
the security guarantees of Ada/SPARK are *much* stronger than what Rust
provides. I'm happy to discuss this off-list if you want to go over
details, but I fear we'd stray off-topic here on the QubesOS list.
It's also worth taking a look at Genode and their list of supported targets:
https://genode.org/documentation/platforms/index
I take it you mean for x86_64, since your list is missing stuff like
AIX/POWER which introduced the concepted of IOMMU to the PC (ported from
IBM's z/OS line of operating systems that introduced the first complete
package sof hw-assisted hypervisors in 1968).
From slightly more exotic hw (these days) there's also the old and
stable Solaris LDOM:
https://en.wikipedia.org/wiki/Oracle_VM_Server_for_SPARC
Joe