If a physical server is running a particular operating system and a hypervisor on top, do all guest accounts have the same operating system as that server?
The hypervisor guests run their own operating systems.
Depending on how the hypervisor is implemented (you mention in your question that it runs "on top of" a particular host operating system) parts of what that guest sees as "hardware" may actually be emulated/wrapped by the host OS, but software running on the guest will not be aware of that (it only sees its own guest OS).
Related
I have a situation where i need to view memory and disk space used by operating systems (windows2012r2 and centos) and web servers (IIS(windows2012r2) and apache(centos)), both of them made as a virtual servers in hyper v.
I am going through the arm trusted firmware architecture from this link https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/firmware-design.rst and I am confused. I have below queries:-
What is the need of trusted OS ?
How it is different from normal world OS ?
If trusted OS is secure then why not only use trusted OS and remove normal OS ?
from what threats the trusted OS give security and how ?
When is the switch between trusted OS and normal world is required ?
I would suggest you to first read the introductory article on Wikipedia, then the notice about OP-TEE, which is an implementation running on Cortex-A processors, now maintained by Linaro, then the various documentations available here, and finaly look at the OP-TEE code itself.
Now, rather concise answers to your questions could be:
1) What is the need of trusted OS ?
The need is to prevent resources from being directly accessed from the generalist OS it is running concurrently with, for example by a user of the generalist OS having root privileges.
2) How it is different from normal world OS ?
It is small by design, and running with more privileged access to the hardware than the generalist operating system. On an ARMv8-a system, portions of the Trusted OS will run at EL3, when an hypervisor will run at EL2, and Linux at EL1.
3) If trusted OS is secure then why not only use trusted OS and remove normal OS ?
Because of its limited scope: its purpose is not to replace, say, Linux, which has millions of line of working/well tested code, but to secure resources from Linux users at a small cost.
4) From what threats the trusted OS give security and how ?
From attempts from the generalist OS users, either legitimate, or illegitimate (hackers having compromised the generalist OS for example), to access resources/services protected by the Trusted OS.
5) When is the switch between trusted OS and normal world is required ?
It is required at the time some code running in the context of the generalist operating system will need to access a resource managed by the Trusted OS, for example having some encrypted content decrypted using a key which is only accessible by the Trusted OS. This does involve (I think) the use of the SMC instruction.
An other occurence of such a switch is when a hardware interrupt needs to be handled: EL3, EL2 and EL1 have their own interrupt vectors tables, and interrupts happening at EL2 or EL1 can be routed to EL3, so that interrupt handling may be safely handled in the context of the Trusted Execution Environment - thanks to artless noise for reminding me about this.
Question mark
I'm wondering whether it's possible for the VM guest machine to pop up a window to the MS-Windows host machine once a task is done within the VM (not an email). If I'm not dreaming, how to achieve that ?
Why
The VM is a simulator for a production server. Code is written within the host IDE and tested straight into the VM. So files are transferred manually from the IDE to the VM, and then automatically moved, formatted, chmoded, chowned and so on in the VM. This process can take a while, so I want to warn the devleopper once the process is over. The developper have no access to the VM and shall not necessary have one.
Config
Tool: VirtualBox 4.1
host: MS-Windows XP or Windows seven
guest: VM Debian
shared dir: yes
network : bridged connection
If this ability existed, it would be quite a security hole in VirtualBox. Guest VMs gaining access to the host machine's OS is not a good thing! As such, I don't think it's possible to accomplish this in a supported manner.
Instead, think of it as two separate machines. What mechanisms do you have for causing alerts or popups on one machine from another? Is anything like IMs, netsend, etc enabled in your environment?
iam confused over these two concepts. The xen split driver model and paravirtualization. Are these two the same ? Do you get the split driver model when xen is running in full virtualized mode ?
Paravirtualization is the general concept of making modifications to the kernel of a guest Operating System to make it aware that it is running on virtual, rather than physical, hardware, and so exploit this for greater efficiency or performance or security or whatever. A paravirtualized kernel may not function on physical hardware at all, in a similar fashion to attempting to run an Operating System on incompatible hardware.
The Split Driver model is one technique for creating efficient virtual hardware. One device driver runs inside the guest Virtual Machine (aka domU) and communicates with another corresponding device driver inside the control domain Virtual Machine (aka dom0). This pair of codesigned device drivers function together, and so can be considered to be a single "split" driver.
Examples of split device drivers are Xen's traditional block and network device drivers when running paravirtualized guests.
The situation is blurrier when running HVM guests. When you first install a guest Operating System within a HVM guest, it uses the OS's native device drivers that were designed for use with real physical hardware, and Xen and dom0 emulate those devices for the new guest. However, when you then install paravirtual drivers within the guest (these are the "tools" that you install in the guest on XenServer, or XenClient, and likely also on VMware, etc.) - well, then you're in a different configuration again. What you have there is a HVM guest, running a non-paravirtualized OS, but with paravirtual split device drivers.
So, to answer your question, when you're running in fully virtualized mode, you may or may not be using split device drivers -- it depends on whether or not they are actually installed to be used by the guest OS. Recent Linux kernels already include paravirtual drivers that can be active within a HVM domain.
As I understand it, they're closely related, though not exactly the same. Split drivers means that a driver in domU works by communicating with a corresponding driver in dom0. The communication is done via hypercalls that ask the Xen hypervisor to move data between domains. Paravirtualization means that a guest domain knows it's running under a hypervisor and talks to the hypervisor instead of trying to talk to real hardware, so a split driver is a paravirtualized driver, but paravirtualization is a broader concept.
Split drivers aren't used in an HVM domain because the guest OS uses its own normal drivers, which think they're talking to real hardware.
I have a VMWARE ESX server. I have Redhat VMs running on that server. I need a way of programatically testing if I'm running in a VM. Ideally, I'd like to know how to do this from Perl.
See the answer to "Detect virtualized OS from an application?".
You shouldn't 100% depend on any method, as they are undocumented features/bugs - they work on some host OSes and some virtualization solutions, but there is no guarantee that they will continue working; indeed, the whole point of virtualization is to be as undistinguishable from real metal as possible. With this in mind, the blue pill red pill (which is mentioned in the accepted answer to this similar question) seems to work ... for now.
VMWare has a couple of SDK's, including an SDK for Perl.
I think (depending on the version of esx) you can inspect at the MAC address of the NIC. VMs running in VMWare NIC will have a manufacturer string assigned to VMWare, no the physical NIC MAC. (We were trying to spoof the MAC to VM a license server and newer versions won't let you do it.) Also, this won't guarantee you aren't running on a physical box with a NIC spoofed to look like VMWare, but that would be an odd thing to do in most circumstances anyway.
Run the following command:
lspci | grep VMware
It should show something like this:
00:0f.0 VGA compatible controller: VMware SVGA II Adapter
00:11.0 PCI bridge: VMware PCI bridge (rev 02)
00:15.0 PCI bridge: VMware PCI Express Root Port (rev 01)