New user-mode concept I thought of.

[Sourcer]

The usual and common implementation of 'user-land' in today's kernels is(Maybe this is to- o x86 specific?):
- Create new page tables for the process.
- Load the process's memory(data, code, etc)
- Notify the CPU about the usage of these page tables.
- Change CPU ring, and jump to the entry point.

Page tables has regions that distinguish between 'supervisor' and 'user', i.e. you can't use 'supervisor' addresses in the page table,
if you're in a low-privileged ring. This whole concept is used for like what? 40 years?( )

A new concept i'm proposing is based on Intel''s virtualization technology, and the world's progression regarding virtualization
and virtual machines. Intel introduced a brand new CPU modes, called:
- VMX-ROOT: which is basically the 'regular' CPU mode you're all familiar with. No changes.
- VMX-NON-ROOT: a new CPU mode, which has the exact same privileges VMX-ROOT has, i mean, it can do ANYTHING. But wheres the catch?
You can actually trap this CPU with a whole lots of methods(trap with specific instructions, trap with interrupts...). By 'trapping', i mean when a certain
event occurs, you're code will begin to run. Just like interrupts.

So, why the heck shouldn't we use this concept and improve the current 'user-land' known concept?
The kernel will be loaded into 'VMX-ROOT' mode, and switch to 'VMX-NON-ROOT' whenever it chooses to. But how is memory seen by a code that is running in
'VMX-NON-ROOT' mode you're asking? Before Intel's new EPT technology, managing the memory for Virtual Machines was a living nightmare(Shadow page tables, i won't extend)

Intel introduced 'Extended page tables', which is basically a page-table that maps every linear address that is used in 'VMX-NON-ROOT' to an actual linear address;
much like the usual virtual-address to linear-address page tables.

This is a very basic introduction to the concept. Any thoughts?(This won't work, This will work...)

[Love4Boobies]

I'm not sure what problem you're trying to solve. As far as I can tell, you're not arguing that the current solution should be replaced because it's outdated, you're arguing that it should be replaced because it's old. Do you want applications to embed their own drivers or something? Or are you trying to implement an exokernel, perhaps?

[Brendan]

Hi,

So, why the heck shouldn't we use this concept and improve the current 'user-land' known concept?

Because you still end up with the exact same "user-space and kernel space", except that instead of using something that's actually designed to do this efficiently (normal paging) you're using something that is designed for a completely different purpose (and is slower, more complex and less portable), without having any benefits to justify all the disadvantages (other than "you can trap things that processes have never wanted to do and should never have been able to do, so that you can make sure they can't be done").


Cheers,

Brendan

[OSwhatever]

- VMX-NON-ROOT: a new CPU mode, which has the exact same privileges VMX-ROOT has, i mean, it can do ANYTHING. But wheres the catch?
You can actually trap this CPU with a whole lots of methods(trap with specific instructions, trap with interrupts...). By 'trapping', i mean when a certain
event occurs, you're code will begin to run. Just like interrupts.

Isn't VMX-NON-ROOT supposed to be run by a kernel under the hypervisor or whatever. I haven't looked into this Intel virtualization very much but I have a feeling there are loopholes in VMX-NON-ROOT mode that makes it unsuitable for user space applications. I'm not sure what kind of functionality you are after but let's take an example as you mentioned page tables in the beginning. Perhaps you want the user program to control its own page tables.

I think you can trap writing to CR0 but a user program can't trap writes to the page table itself. You can trap the writes to a page table page but that has to be setup by the kernel in that case. A user program cannot write whatever it wants to a page table as that could compromise the system (or the virtual system). Hence you need a kernel to ensure that the user program behaves correctly regardless whatever solution you choose.

[dchapiesky]

The usual and common implementation of 'user-land' in today's kernels is(Maybe this is to- o x86 specific?):
- Create new page tables for the process.
- Load the process's memory(data, code, etc)
- Notify the CPU about the usage of these page tables.
- Change CPU ring, and jump to the entry point.

Page tables has regions that distinguish between 'supervisor' and 'user', i.e. you can't use 'supervisor' addresses in the page table,
if you're in a low-privileged ring. This whole concept is used for like what? 40 years?( )

A new concept i'm proposing is based on Intel''s virtualization technology, and the world's progression regarding virtualization
and virtual machines. Intel introduced a brand new CPU modes, called:
- VMX-ROOT: which is basically the 'regular' CPU mode you're all familiar with. No changes.
- VMX-NON-ROOT: a new CPU mode, which has the exact same privileges VMX-ROOT has, i mean, it can do ANYTHING. But wheres the catch?
You can actually trap this CPU with a whole lots of methods(trap with specific instructions, trap with interrupts...). By 'trapping', i mean when a certain
event occurs, you're code will begin to run. Just like interrupts.

So, why the heck shouldn't we use this concept and improve the current 'user-land' known concept?
The kernel will be loaded into 'VMX-ROOT' mode, and switch to 'VMX-NON-ROOT' whenever it chooses to. But how is memory seen by a code that is running in
'VMX-NON-ROOT' mode you're asking? Before Intel's new EPT technology, managing the memory for Virtual Machines was a living nightmare(Shadow page tables, i won't extend)

Intel introduced 'Extended page tables', which is basically a page-table that maps every linear address that is used in 'VMX-NON-ROOT' to an actual linear address;
much like the usual virtual-address to linear-address page tables.

This is a very basic introduction to the concept. Any thoughts?(This won't work, This will work...)

I am pretty sure this is called ring -1 and an example of trapping and monitoring calls is Intel's Kernel Guard Technology --- see here for Apache Licensed UEFI compatible hypervisor which can trap all the stuff your describe --- https://github.com/01org/ikgt-core

[OSwhatever]

Not really sure what TS wants but aren't there loopholes in the VMX-NON-ROOT mode that makes it unsuitable for user space programs?

Let's take an example, I'm not sure what TS wants but as he mentioned the page table let's assume user program should manage their own page tables. We know that we can trap writes to CR0 but we can't trap writes to page table entries themselves unless we set those pages to be write protected but who is going to do that, the user program itself? Who ensures that those pages gets trapped and ensure that the entries are valid? If they are invalid it can compromise the host system (or the virtual system it runs under). In practice we need some kind of kernel under virtualized system that ensures the functionality that the user space programs behave.

I haven't studied the Intel virtualization in detail so I haven't really a solution to this. Do you know how the example above could be solved?

Also, I see not much benefit to transfer much of the system control to user space programs. The kernel would basically be replaced by a runtime and you have "kernel" again. What are the benefits here?

[dchapiesky]

Not really sure what TS wants but aren't there loopholes in the VMX-NON-ROOT mode that makes it unsuitable for user space programs?

Let's take an example, I'm not sure what TS wants but as he mentioned the page table let's assume user program should manage their own page tables. We know that we can trap writes to CR0 but we can't trap writes to page table entries themselves unless we set those pages to be write protected but who is going to do that, the user program itself? Who ensures that those pages gets trapped and ensure that the entries are valid? If they are invalid it can compromise the host system (or the virtual system it runs under). In practice we need some kind of kernel under virtualized system that ensures the functionality that the user space programs behave.

I haven't studied the Intel virtualization in detail so I haven't really a solution to this. Do you know how the example above could be solved?

Also, I see not much benefit to transfer much of the system control to user space programs. The kernel would basically be replaced by a runtime and you have "kernel" again. What are the benefits here?

ikgt mentioned above has an interface for writing filters which should be able to catch all of said examples.

however - this would imply a microkernel acting as a trusted root sending events it catches back to the virtualized user space... so really the question is not inter-vm security but microkernel api security and that sure worked out nice for android's secure storage didn't it...

[dozniak]

so really the question is not inter-vm security but microkernel api security and that sure worked out nice for android's secure storage didn't it...

How is that even related? Android has no microkernel (except the OKL4/Android version), and no hypervisor.