>>108268326
i use ubuntu via wsl2

>>108268328
>i use ubuntu via wsl2
windows is obviously terrible and not even hypervisor?
what cpu do you even have there, or is that a random trollpost without reading OP?

Nobody uses Xen anymore, we have Proxmox for that

>>108268350
>Nobody uses Xen anymore, we have Proxmox for that

"Two types of virtualization are supported: container-based with LXC (starting from version 4.0 replacing OpenVZ used in version up to 3.4, included[11]), and full virtualization with KVM.[12]"

Neither LXC or KVM are hypervisors, nor provide the isolation level that hypervisors such as Xen provide.

>>108268336
huh? anyways i use a 10950x3d

>>108268355
>KVM isn't a hypervisor
Are you retarded or just a shill?

>>108268383
>>KVM isn't a hypervisor
>Are you retarded or just a shill?
allright, is it the same hypervisor TYPE as Xen, or totally different security characteristics?

Seems to me that in order of isolation we have
- KVM - most simple, least isolation, possible to break out when bugs occur, which is easier since much bigger attack surface
- Xen - much smaller attack surface. Xen kernel starts fist and restricts (memory protections etc) the Linux kernels (also Linux in Dom0)
- real MICROKERNEL hypervisors, probably such as Genoed+NOVA. (other microkernels: Sel4, such as Genode/Sel4)

but I'm here to learn

>>108268363
>huh? anyways i use a 10950x3d
I aim for smallest attack surface against attacker that wants to break out of program running in VM (or in domain 0) and take control of the machine.

It seems Liunx with KVM exposes the most. The entire linux kernel running on host must be free of exploits, otherwise a root in VM can gain access to entire machine, right? Linux with KVM shields the goest VMs, does nothing to make the host Linux kernel more secure (when it is compromised it gets the entire machine).

On Windows it seems we have the same, and Windows kernel is also very big (plus I would never trust microsoft, and can't review their source code).

With Xen, it seems the attack surface is much smaller: the "host OS" (the linux in dom0) is restricted by Xen (memory protections/isolation). The Xen itself is very small.

And Microkernl hypervisors such as Genode+NOVA have the smallest possible code running with the full privileges, everything else - including device drivers of the host - is protected (drivers in Genode, same as other microkernels, are just user processes). So attack surface is smallest.

Genode+NOVA and similar > Xen > KVM > Windows VM solutions

File: Kernel-based_Virtual_Machine.png (129 KB, 960x1018)

129 KB PNG

>>108268421
KVM and Xen are both Type-1 hypervisors (running on the hardware, what you want.)
Things like VirtualBox or VMware workstation are Type-2 hypervisors (running under the OS)
If you're worried about attack surface you can run a minimal distro like Alpine and manage your VMs manually without adding anything more than ssh.
It's worth considering that Xen also is not "OS free" and you are running it as a kernel module on linux or bsd (source: https://xenproject.org/projects/hypervisor/ ) the same as kvm would, you're not virtualizing anything with no kernel running to load the hypervisor, just don't run a bunch of vulnerable software and expose tons of things on your VM host and you'll be fine.

>>108268486
No, KVM is type-2 hypervisor, KVM is a Linux kernel module, KVM runs inside the Linux kernel, not the other way around. Maybe you can consider the whole Linux kernel with KVM as a type-1 hypervisor but it's clearly not the same as Xen

>>108268471
maybe you should skip virtualization entirely and just use a fleet of thin clients and minipcs for each application you intend to run if you're that worried about hypervisor escapes

>>108268326
nobody uses xen thoughbeit

>>108268486
I think they differ a lot.
Perhaps let's identify possible attacks and then we have clear picture of which solutions target what.

So you want in the end to run guest VMs, and we assume VMs might become has hostile as possible (attacker will get, or even is the root e.g. when you provide hosting; and even if root is restricted there, such as SELinux, grsecuirty, we assume he can break out to full control of the guest "machine").

The hostile VM wants to attack other VMs, or the host.

Also external factors want to attack the host, e.g. malicious incoming network packages to the physical network card aiming to trigger a vuln in network driver, or drawing commands/data tries to trigger bugs in video driver. Both do happen.

--- Microkernels ---
Only the microkernel (MK) itself can access entire memory/addr space/devices, and sets their protections. The code is as small as possible, most easy to audit.

For example: NOVA + Genode.
Privilege levels:

Hardware

NOVA (VMX root, highest privilege)

Genode core (user mode)

Drivers / VMM / services (user mode)

Guest VMs (VMX non-root)

Starting from malicious VM, we need to at least find exploit in NOVA, which is the microkernel so has smallest attack surface - this is most secure philosophy as for operating systems hosting VM guests.
Starting from attack on hardware from outside: invalid data trigger bug in networks driver - only lands in the hosts's userspace (the Genode drive, btw. usually imported code from linux drivers) - it still can not get the Genode MK "root", can not remove memory protections, can not read/write mem of other processes nor any (other) VM nor physical devices.

... 1/2

>>108268350
i was thinking this, a little confused, because i havent heard xen even mentioned since college 20 years ago.

I don't think anyone is targeting your threadripper workstation with million dollar 0-day hypervisor breaks, unless you're specifically running malicious software on it in which case what are you doing not separating it from your main system to begin with.

... 2/2

--- Xen ---

Hardware

Xen Hypervisor (ring -1, highest privilege)

Dom0 (privileged VM, runs device drivers, admin tools)

Driver domains (optional, user mode inside Dom0)

DomU / Guest VMs (ring 0 inside VM, VMX non-root)

Starting from VM: trigger bug in the drivers - that are the Dom0 - just Linux drivers - and you are in Dom0 root. You can now access other VM. Attacking on the hardware level of machine still is a bit hindered with pre-existing protections set up by Xen itself.
Starting from external to hardware: trigger bug in Linux driver - also you are now in Dom0 root, same as above. Xen might set up some stronger protections limiting some exploits.

--- KVM ---

Hardware

Linux Kernel + KVM module (ring 0, highest privilege in host)

QEMU / VMM (user mode)

Guest VMs (VMX non-root)

Starting from VM: trigger bug in the linux drivers - you have the root - you have entire control of the machine. No Xen memory protections hinder your attack, there is nothing above you that is the highest level(*).
Starting from external targetting our hardware: trigger bug in network driver - you have the root of machine, highest level. No Xen memory protection hinder your attack.

(*) not taking into account firmware and other things "hidden in silicon" such as intelME and similar, that is other topic and applies to all approaches on given hardware platform/CPU.

Also: everywhere the linux root can be augmented with root limiting SE Linux, Grsecurity and similar MAC/RBAC. Rarely used it seems, and does little to protect from device driver bugs.

Based on this, the isolation levels are in order:
NOVA+Genode and similar micro-hypervisors > Xen (the linux kernel but some mem protections) > KVM (less memory protections to restrict dom0 and the dom0 drivers).

Xen, KVM, this is NOT just about not installing bloatware in dom0. It is about dom0 not being restricted (e.g. the drivers).

Which is why I try Xen, not just KVM.

>>108268671
>I don't think anyone is targeting your hardware
noob mindset.
Also, I want solution for hosting providing.

>>108268690
>Also, I want solution for hosting providing.
tf are you doing asking here then
ask someone who knows their shit

>>108268641
>maybe you should skip virtualization entirely and just use a fleet of thin clients and minipcs for each application you intend to run if you're that worried about hypervisor escapes
Don't have a fleet of 10,000$ machines, and even if I would that it's wasteful.

Of course, for most important tasks, separate physical machine is always good.

>>108268693
>ask someone who knows their shit
So, /g/?

>>108268676
Why not use Gentoo and only compile the modules you actually need?

>>108268695
if every guest's workload needs a 10000 dollar machine how can you run more than one on the single threadripper system at all?

>>108268713
>why are VMs and shared hostings needed?
really?
Because if 10 people need e.g. to compile a large program fast (on 128 thread, 256 gb ram) - but sometimes, e.g. 5 minutes each 1 hour (rest are small recompilations), or they run physical simulation sometimes (but not 100% of the time, e.g. run 1 hour sim, then think about it, plan it, then run another next day)
then instead of buying 10 of 10,000$ machines, we buy 1 10,000$ machine and make the users...
Share the time
you know the time sharing machines
they figured that out in 1960's - 1970's and invented PDP11, Unixes and such
(spent the saved money on hookers and coke)

>>108268789
>you know the time sharing machines
>they figured that out in 1960's - 1970's and invented PDP11, Unixes and such
>(spent the saved money on hookers and coke)
...and if linux would be perfect in isolating users from root, and if users would not need root for anything, then all we need is 1 linux baremetal box.

But since in reality there we get user to root exploits, and since users anyway do need to have the root - therefore we need VMs.
And since you can still break out of VMs (and since the host system can be attacked also from outside such as bugs in network card drivers, network protocol drivers, and more) - we invented stronger isolations, discussed in this thread

>>108268699
>just compile some of the modules
Of course. The real attack surface is not the ~10000 driver, just the like 50 you actually use. I was just thinking about that.
But still
1) this is 50 drivers too many. In microkernels (and microhypervisors) instead you have kinda 10 drivers, like the memory isolation setup, timer, message passing, and few more, that is all that is in ring0 (plus the code to monitor VMs, the VMM, in case of microhypervisors). That is supposedly 10-20 thousand lines of C. All else is ring 3 user space, including your network, gpu, keyboard, etc. drivers (imported from linux usually I think)

2) linux has lots of non-drivers code in there, all running at highest privilege level (ring 0)

3) I was pondering a general solution for other people, "how to do it best", not literally for just me, for just the current box I have right now

>>108268789
how will all 10 vms have access to the full 128 threads and 256gb of ram at once without shutting one down for another to take it's place? it sounds like vms arent suitable for the usecase and lxc containers for each user would be more appropriate

>>108268885
>how will all 10 vms have access to the full 128 threads and 256gb of ram at once without shutting one down for another to take it's place? it sounds like vms arent suitable for the usecase and lxc containers for each user would be more appropriate
Sharing all the CPU is easy. They are automatically shared without any problem.
In KVM (e.g. via just qemu) it simply works by default. It also just works in Xen. It's called vCPU. you can pin them for performance but don't have too.

True, memory is a bigger problem.
Xen needs to have it allocated per running VM. (KVM too I think).

So to host 4 teams doing compilations you might want to have 4 VMs each with 48 GB ram, plus 6 teams doing compulation heavy light ram computation each 16 GB.
Each of them gets 128 cores (the same cores that's ok).

How ever you can reallocate VM sizes using "balloon" drivers, without restarting the VM. So if some teams work in different timezones or time hours, you can shrink their VM size "for the night" while expand the actively working VM as needed (and give them all enough swap, so that they slow down instead of crashing when slowed down).