On 26 March 2018 at 15:45, Michael MacIsaac <[email protected]> wrote: > Dan, > > Thanks, that's helpful too. > > So I try "systemd-detect-virt" on a zLinux and get only get "zvm", which is > a start but not too helpful. > > What I'm learning is that /proc/sysinfo (and thus STSI) is arguably a > treasure trove of information, because (along with vmcp) can determine the > hierarchy of hardware and hipervisors as such: > > └── systems > ├── CEC:0FF28 > │ ├── LPAR:VM23 > │ │ └── zVM:VM23 > │ │ ├── SSIcluster:none > │ │ ├── devices > │ │ ├── virtualMachine:LNXADM32 > > I'm hoping dmidecode will provide the equivalent on Lintel. >
Let me put this in a different perspective, as a millennial using a z system for the first time less than 3 years ago... I was shocked when I discovered /proc/sysinfo on a z system, and that even inside KVM machine it exposes the LPAR, z/VM, KVM information. And that this information is stored, is nested, and is passed through to inner layers. I found it extremely insecure, as typically I expect privilege separation after each layer of virtualization - as in a public cloud guest user, should not be able to introspect the underlying virtualisation middle layers (e.g. xen) or the bare metal. I expect a typical bare-metal -> virtualization -> containerization deployment will not have the same sysadmin managing / supervising each of those layers. I expect datacentre remote-hands sysadmin; devops; developers to have segregated access to these things. However, after working with z systems a bit more, I realized that the physical security and access modeling is very different. In effect, one typically has a very limited number of people accessing the mainframe, whilst sharing many hats. Hence the mindset that this is sensitive information to expose from one context to a nested one is simply not there. I do agree that /proc/sysinfo is useful and nice. But also something to _not_ be extended, and to _not_ be ported to other architectures. Can't really be removed, or change output, cause it is ABI effectively. (There are inverse examples too, for better or worse, e.g. UEFI access is more open and API accessible from userspace than HMC is from LPAR) Regards, Dimitri. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
