Re: Xen article for the FreeBSD Journal

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Mon, Nov 18, 2024 at 12:16:08PM +0000, Andrew Cooper wrote:
> On 14/11/2024 3:16 pm, Roger Pau Monné wrote:
> > I've been told the article should be submitted by the middle of
> > November, I'm a bit short on time.  I would like to give them
> > something on Monday so they also have time to provide feedback.
> 
> In the introduction, s/viertual/virtual/
> 
> In paragraph after architecture.jpg, you want a semicolon rather than a
> comma here: "on x86; options for".
> 
> "so far the only OSes to have x86 Xen PV support are Linux and NetBSD."
> isn't quite true.  They're the only ones that remain today.  Windows had
> support at one point, but never saw the light of day, and Solaris and
> support too, IIRC.  I have a vague inkling that so did Novel Netware,
> but I don't know if that was a derivation of another OS, or something of
> it's own right.

I've adjusted the paragraph to:

"The main limitation with such approach is that it requires extensive changes to
core parts of guests kernel OSes.  Currently the only OSes that still have x86
Xen PV support are Linux and NetBSD.  There was an initial port of Windows to
run as a PV guest that was never published, plus Solaris also had PV
support."

> "due to the amount of logic required to handle data transfers".  While
> true, it's more the overhead of emulating legacy interfaces.  (As a
> counterpoint, emulated NVMe for windows turns out to beat our PV drivers
> for performance.  NVMe is a very well written spec.)

I've reworded this a bit, but I haven't mentioned NVMe as I think
that's outside of the point I wanted to make.

> For features unique to Xen, It might be worth mentioning OpenXT too next
> to QubeOS, nothing that it's used by governments.

I've added:

"Similarly to QubesOS there's also OpenXT: a Xen based Linux distribution
focused on client security used by governments."

I'm not sure if there's any difference between QubesOS and OpenXT
that's worth mentioning.

> Also, we really should discuss Introspection and VM-Fork.  Drakvuf is
> used by CERT.pl for a malware analysis
> (https://github.com/CERT-Polska/drakvuf-sandbox) and
> https://github.com/intel/kernel-fuzzer-for-xen-project is a fuzzing
> integration into AFL.

I've added:

A couple more of unique Xen x86 features that are used by diverse products:

 * Introspection: allows external monitors (usually running in user-space on a
   different VM) to requests notifications for actions performed by a guest.
   Such monitoring include for example accesses to a certain registers, MSR, or
   changes in execution privilege level.  A practical application of this
   technology is DRAKVUF, a malware analysis tool that doesn't require any 
monitor
   to be installed in the guest OS.
 * VM-fork: much like process forking, Xen allows forking of running VMs.  Such
   feature still doesn't create a fully functional fork, but it's enough to be
   used for kernel fuzzing.  The KF/x fuzzing project puts the kernel into a 
very
   specific state, and then starts fuzzing by creating forks of the guest  All
   forks start execution at the same instruction but with different inputs.  
Being
   able to fork a VM in a very specific state extremely fast and in parallel is
   key to achieving a very high rate of iterations per minute.

> 
> Overall, LGTM.  I would however try and say (somewhere) that PV guests
> use Ring Deprivileging because that's the technical name for what we're
> doing with PV guests, and is a good term to search for.

I've added a mention in the initial section that describes the guest
types.

> It might also be worth saying that Xen, having become an established
> hypervisor in its own right, was involved in the design of x86 hardware
> virt extensions.

Maybe that's a bit too much?  I don't mind adding, but I've already
past the requested article size, so it's possibly fine if I leave it
out?

Thanks, Roger.