The Keykos kernel delivers the raw function of RAM, CPU, I/O devices as best it can and this means that filters that legacy kernels established can be replicated. There were hardware features of the IBM 370 that were unavailable in user mode in IBM’s principle operating systems, such as “Program Event Recording”. Keykos delivered them, and our user mode debugger used them. For hardware that does not use the Reserved Address Plan the program can use the entire address space provided by the hardware. In general this helps to provide the function of legacy kernels.
Today’s hardware includes PCIe and such. I have heard that virtual machine software virtualizes PCIe but I have not found an accurate enough description of PCIe to make my own judgement. As ever one must exclude “extra features” that the bad guys know about. The principle reply to this query would exclude most current platforms of interest. I try here to learn more about PCIe and perhaps propose improvements.
The same goes for GPU’s. Some system diagrams hint that the system RAM that a GPU can access is mediated by PCIe. At some additional kernel complexity such hardware can be used in the new world, assuming a rational PCIe design.
The first version would disable GPU’s for lack of specification. I know no reason why GPU’s are inherently insecure, except in their current state of public documentation. The definition of PCIe is proprietary and I find no even bald claims about what members of a PCIe network can send what sorts of messages to other parts. This is not suitable for a secure platform if you are to convince skeptics. I suspect that design review following wide disclosure of these protocols may support security requirements. But is it in the engineering culture of the PCIe architects to even say “no back doors”? In particular we need to be assured that there are no extra bonus features such as the Foxconn backdoors.