-current paravirtualized kernel on bare hardware
 

It is message I found running installer. So installer kernel is paravirtualized - does it mean it was build to work in virtual environment and kernel warns that it is not good idea to run such kernel on bare hardware?

The Slackware kernel is not built/optimized for virtualized environments. You will probably have to build the correct modules for the correct bare metal hypervisor (Xen or ESXi).

My point is why to use paravirtualized - whatever that means - kernel as kernel used during installation. Final installed kernel comes from package. Does paravirtualized is the same as vanilla? What is purpose of this? Why not to use just common vanilla kernel? I emphasize: it is all about installer kernel. Just there is something I don't understand.*And no one warned us that kernel has something peculiar inside.

To put it simply, Paravirtualization allows for better performance over Full Virtualization.

https://en.wikipedia.org/wiki/Paravirtualization

Are you sure about that?
To me, it looks like everything that should be there is there already, but I might be wrong.
I haven't ever used Xen, but on ESXi I always install the VMware Tools, which includes the services and (I think) kernel modules needed on the Guest OS. One thing I can be sure about, and that is that I've got VMs running the stock generic Slackware kernels that have been running without issues for years. I've never had to recompile a kernel to get anything working in a VM.

Its not a warning at all: its informational in fact, as this means this kernel can run unmodified on both bare metal and on VMs. Contrast with say, booting the same under a hypervisor, it'll tell this instead:

It is more detailed in the liked Wikipedia article above: paravirt-ops was mainlined since 2.6.23, which for Slackware means that since at least Slackware-12.1 (and probably more stable on 13.37 upwards,) it can run unmodified under baremetal, KVM, Xen, and other hypervisors.

Huge and generic kernels run unmodified under both ESXi and Xen.

Under Xen you will not get the benefit of PV unless the PV drivers are loaded. If you don't load PV drivers (because they're absent from the kernel) Xen will switch to pure HVM mode, and present you with a Xen SCSI controller much like any real hardware. You're stuck with this 'hardware' until you reboot. You can either have one or the other. For the newcomer this is a bit strange. I expected a configuration option to determine the functionality presented to the guest but it's all done through the behaviour of the guest on boot.

Under ESXi it seems to work slightly differently. You get to choose in VM config whether you want PV or SCSI-this or SCSI-that (there are a few choices), however VMWare seems to have done a lot more work on optimising the non-PV case, so without PV it seems to perform rather better than HVM Xen.

I think a lot of confusion may persist about PV vs HVM modes because a lot of Slackware-related stuff talks about pure PV booting (which will require a special kernel, more akin to user-mode linux) instead of the latterly introduced HVM booting. For some time PV out-performed HVM, but this is no longer the case see: https://cloudacademy.com/blog/aws-am...irtual-amazon/

BUT, is not a security liability having a virtualized kernel on bare hardware? There is no performance impact?

In the Linux reunions where I have been, I heard discussions about about the possibility to have rogue virtual machines at EFI level, planted for industrial espionage in the boot or ESP partition.

After all, that's WHY they insists on having signed EFI binaries and the motherboards offers the ability to the disable hardware virtualization.

How Slackware looks intending to look to Enterprise, as probably only there matters that PAM and Kerberos, does not introduce those virtualization ready kernels a security flaw?

After all, I believe that those virtualized kernels should be stand-alone, and eventually aware chosen by user, instead of having them by default.

I for one, I do not need virtualization, but a maximum performance, also.

No.

OK, BUT how about the security impact?

A virtualized kernel doesn't simplify the life of a rogue virtual machine put in a computer for whatever rogue reasons?

I believe strictly there will be a performance impact, because the code for the driver will remain in memory, consuming some. I think the kernel has a way of reclaiming the memory occupied by driver init code, not so sure it can reclaim memory from drivers that are loaded but inactive. If you worry about this, then you need to hand-craft every kernel you use. You can have fun going through all the networking options and remove the ones that you don't want active, probably you're not using half of them :-).

In terms of security, of course there is potential increase in attack surface if including something you don't need, but normal kernels are surely going to be susceptible to blue pill concepts as well, if that's what you mean?

If the Slackware installation disk had Linux guest support off (CONFIG_HYPERVISOR_GUEST=n), the perpetrator could always build another kernel on their own first, and use it to do the evil act of running Slackware in a virtual machine?

I tested it in Slackware64-14.2, kernel 5.7.7, on a Pentium 4. Removing CONFIG_HYPERVISOR_GUEST gave 2064 kilobytes more available memory, but a benchmark of building a defconfig kernel became 0.05 % SLOWER (which is just noise, of course).

I thought CONFIG_HYPERVISOR_GUEST just enabled other options. Do you know what that actually does?

Yes, so if you disable CONFIG_HYPERVISOR_GUEST from a -current64 .config, it switches off a lot: