TUD-OS / NRE

NOVA runtime environment (official branch)
GNU General Public License v2.0
34 stars 12 forks source link

A Question About Ports and Addresses #62

Open lonnietc opened 3 years ago

lonnietc commented 3 years ago

Hello Nils,

In reviewing NRE more, I see that the "services" are the central point for accessing ports and addresses within the system, but I was a bit confused as to what would happen if a port or address were directly access within the VM space.

This would seem like it could cause a conflict with the HV and could potentially crash the system, correct?

I would have thought that this type of thing would have been protected from within the HV but am a little confused on this part.

I want to write up some new services for NRE but need to get clarification as to what is being protected and what is not from within the address space if you would like to comment on it more for me.

Thanks,

lonnietc commented 3 years ago

Actually, in that same vein, I am wondering about PCI pass-through stuff from one, or more, VM's which is what I am thinking about although I would think that running things through a "service" that manages a virtual PCI pass-through approach would be better if set up correct.

Nils-TUD commented 3 years ago

In reviewing NRE more, I see that the "services" are the central point for accessing ports and addresses within the system, but I was a bit confused as to what would happen if a port or address were directly access within the VM space.

This would seem like it could cause a conflict with the HV and could potentially crash the system, correct?

I would have thought that this type of thing would have been protected from within the HV but am a little confused on this part.

It is protected by the HV and nothing crashes if a VM tries to access a port or address. As everything else in NOVA, physical memory and I/O ports are protected via capabilities. If an application does not have the capability for a specific range of memory or a specific I/O port, the access fails and the application dies. Thus, before doing that the application needs to get the corresponding capabilities. The model is that the root PD gets capabilities for all physical memory (except the memory used by NOVA itself) and all I/O ports. The root PD can then delegate these capabilities to other PDs to provide them access.

The services in NRE might also need access to some memory, ports or other resources and ask their parent PD (e.g., root) to get access to that. For example, the disk service needs access to the MMIO region for the disk device or to I/O ports used by the disk device. However, NRE does not implement any policy on top of these mechanisms yet. That is, everybody who asks gets access to any resource. So, for a real system that would need to be extended by, for example, specifying in the boot scripts which resources can be accessed by a particular application and only in this case, access should be granted.

For VMs it currently depends on the configuration of Seoul as specified in the boot script, which will create the corresponding device models, which in turn connect to the corresponding NRE services. For example, if you say something like "ide:0x1f0,0x3f6,14,0x38,0" in the boot script, Seoul will create the IDE disk model, which connects to the disk service of NRE.

Actually, in that same vein, I am wondering about PCI pass-through stuff from one, or more, VM's which is what I am thinking about although I would think that running things through a "service" that manages a virtual PCI pass-through approach would be better if set up correct.

Sorry, I don't remember how that works or if that is already working. NOVA has some support for that with assign_pci, but I'm not sure whether PCI pass-through is fully supported in user space.