Fixes regression introduced in 599be274c1
Moving the Xen check before the CPUID check, in order to handle the case where
a Xen domain is nested within a hypervisor which can be detected by via the
CPUID check, had an unintended consequence of causing Dom0 to report as a Xen
VM when it is not nested.
This patch stops further checks once it has been determined that Dom0 is not
nested within another hypervisor, meaning that the non-nested case matches its
previous logic (where it does not report as a VM).
Also, tidy the conditionals for the Xen and UML checks by removing handling of
a VIRTUALIZATION_VM_OTHER result, which has no code path.
Fixes#22511
Use product_version instead of product_name in DMI table and the string
"Hyper-V" to avoid misdetection.
Fixes: #21468
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Detection of VirtualBox is accomplished in the existing code by *either* `innotek GmbH`
or `Oracle Corporation` existing in any of:
- /sys/class/dmi/id/product_name
- /sys/class/dmi/id/sys_vendor
- /sys/class/dmi/id/board_vendor
- /sys/class/dmi/id/bios_vendor
With Oracle's physical servers, both `/sys/class/dmi/id/sys_vendor` and
`/sys/class/dmi/id/board_vendor` contain `Oracle Corporation`, so those
servers are detected as `oracle` (VirtualBox).
VirtualBox has the following values in the latest versions:
- /sys/class/dmi/id/product_name: `VirtualBox`
- /sys/class/dmi/id/sys_vendor: `innotek GmbH`
- /sys/class/dmi/id/board_vendor: `Oracle Corporation`
- /sys/class/dmi/id/bios_vendor: `innotek GmbH`
Presumably the existing check for `innotek GmbH` is meant to detect
older versions of VirtualBox, while changing the second checked value
from `Oracle Corporation` to `VirtualBox` will reliably detect later and future
versions.
Currently, when Xen PV domains are nested within a hypervisor which is
detected through CPUID (such as VMware), the detected hypervisor might
not be Xen, because we don't check for Xen until after the CPUID check.
This change moves the Xen check before CPUID checks to fix the issue,
and moves Dom0 checking to detect_vm_xen so that we keep ignoring Xen
when we are in Dom0.
The current detection code relies on /sys/firmware/dmi/entries/0-0/raw
to disambiguate Amazon EC2 virtualized from metal instances.
Unfortunately this file is root only. Thus on a c6g.metal instance
(aarch64), we observe something like this:
$ systemd-detect-virt
amazon
$ sudo systemd-detect-virt
none
Only the latter is correct.
The right long term fix is to extend the kernel to expose the SMBIOS BIOS
Characteristics properly via /sys/class/dmi, but until this happens (and
for backwards compatibility when it does), we need a plan B.
This change implements such a workaround by falling back to using the
instance type from DMI and looking at the ".metal" string present on
metal instances.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
DMI vendor information fields do not provide enough information for us to
distinguish between Amazon EC2 virtual machines and bare-metal instances.
SMBIOS provides a BIOS Information
table (https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf
Ch. 7) that provides a field to indicate that the current machine is a virtual
machine. On EC2 virtual machine instances, this field is set, while bare-metal
instances leave this unset, so we inspect the field via the kernel's
/sys/firemware/dmi/entries interface.
Fixes#18929
Taking a stab at implementing #14479.
Add {Condition,Assert}CPUFeature to `systemd-analyze` & friends. Implement it
by executing the CPUID instruction. Add tables for common x86/i386
features.
Tested via unit tests + checked that commands such as:
```bash
systemd-analyze condition 'AssertCPUFeature = rdrand'
```
Succeed as expected and that commands such as
```bash
systemd-analyze condition 'AssertCPUFeature = foobar'
```
Fail as expected. Finally, I have amended the `systemd.unit` manual page
with the new condition and the list of all currently supported flags.
Docker doesn't set $container, so it cannot be detected that way. Instead, we
check for presence of /.dockerinit, which it creates. Podman does set
$container, but some Red Hat images (in particular, Fedora images) override
$container to equal "oci". So to correctly detect Podman containers, we check
for presence of /run/.containerenv, which is created by Podman and is now the
official way to get information about the container from within the container.
Fixes https://github.com/systemd/systemd/issues/15393
On really old kernels (< 4.14+) a bug in /proc/1/sched handling in the
kernel could be used to determine whether we are running in a PID
namespace. This hasn't worked for a long time, and there's little point
in making things work on old kernels we can't make work on current
kernels, hence let's drop that old cruft.
See: #8153
UML runs as a user-process so it can quite easily be ran inside of
another hypervisor, for instance inside a KVM instance. UML passes
through the CPUID from the host machine so in this case detect_vm
incorrectly identifies as running under KVM. So check we are running
a UML kernel first, before we check any other hypervisors.
Resolves: #17754
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>
Currently systemd-detect-virt fails to detect running under PowerVM.
Add code to detect PowerVM based on code in util-linux.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
This has the major benefit that the entire payload of the container can
access these files there. Previously, we'd set them only as env vars,
but that meant only PID 1 could read them directly or other privileged
payload code with access to /run/1/environ.
WSL2 will soon (TM) include the "WSL2" string in /proc/sys/kernel/osrelease
so the workaround will no longer be necessary.
We have several different cloud images which do include the "microsoft"
string already, which would break this detection. They are for internal
usage at the moment, but the userspace side can come from all over the
place so it would be quite hard to track and downstream-patch to avoid
breakages.
This reverts commit a2f838d590.
proot provides userspace-powered emulation of chroot and mount --bind,
lending it to be used on environments without unprivileged user
namespaces, or in otherwise restricted environments like Android.
In order to achieve this, proot makes use of the kernel's ptrace()
facility, which we can use in order to detect its presence. Since it
doesn't use any kind of namespacing, including PID namespacing, we don't
need to do any tricks when trying to get the tracer's metadata.
For our purposes, proot is listed as a "container", since we mostly use
this also as the bucket for non-container-but-container-like
technologies like WSL. As such, it seems like a good fit for this
section as well.
From https://github.com/microsoft/WSL/issues/423#issuecomment-221627364:
> it's unlikely we'll change it to something that doesn't contain "Microsoft"
> or "WSL".
... but well, it happened. If they change it incompatibly w/o adding an stable
detection mechanism, I think we should not add yet another detection method.
But adding a different casing of "microsoft" is not a very big step, so let's
do that.
Follow-up for #11932.
In a current VirtualBox installation the board_vendor is set to "Oracle
Corporation". So we need to add this to the dmi_vendor_table for a
relieable detection.
This fixes#13429
Signed-off-by: Jan Losinski <losinski@wh2.tu-dresden.de>
If a container manager does not set $container, we could end up
in a strange situation when detect-virt returns container-other when
run as non-pid-1 and none when run as pid-1.
All users of the macro (except for one, in serialize.c), use the macro in
connection with read_line(), so they must include fileio.h. Let's not play
libc games and require multiple header file to be included for the most common
use of a function.
The removal of def.h includes is not exact. I mostly went over the commits that
switch over to use read_line() and add def.h at the same time and reverted the
addition of def.h in those files.
Quoting https://github.com/systemd/systemd/issues/10074:
> detect_vm_uml() reads /proc/cpuinfo with read_full_file()
> read_full_file() has a file max limit size of READ_FULL_BYTES_MAX=(4U*1024U*1024U)
> Unfortunately, the size of my /proc/cpuinfo is bigger, approximately:
> echo $(( 4* $(cat /proc/cpuinfo | wc -c)))
> 9918072
> This causes read_full_file() to fail and the Condition test fallout.
Let's just read line by line until we find an intersting line. This also
helps if not running under UML, because we avoid reading as much data.
These lines are generally out-of-date, incomplete and unnecessary. With
SPDX and git repository much more accurate and fine grained information
about licensing and authorship is available, hence let's drop the
per-file copyright notice. Of course, removing copyright lines of others
is problematic, hence this commit only removes my own lines and leaves
all others untouched. It might be nicer if sooner or later those could
go away too, making git the only and accurate source of authorship
information.
