Address Space Isolation For The Linux Kernel Is Still A Big Challenge In 2020

[phoronix]

Phoronix: Address Space Isolation For The Linux Kernel Is Still A Big Challenge In 2020

While there are many new features in the forthcoming Linux 5.6 kernel, the ongoing Address Space Isolation support is not one of them...

http://www.phoronix.com/scan.php?page=news_item&px=Kernel-Address-Space-2020

[pabloski]

Humm, isolating memory areas used by kernel subsystems. How was it called in the past? Oh yes, microkernel!

Maybe Tanenbaum was right from the start.

[Volta]

Humm, isolating memory areas used by kernel subsystems. How was it called in the past? Oh yes, microkernel!

Maybe Tanenbaum was right from the start.

How did you get to such stupid conclusions?

[oiaohm]

Humm, isolating memory areas used by kernel subsystems. How was it called in the past? Oh yes, microkernel!

Maybe Tanenbaum was right from the start.

Would have paid to watch the video. Yes this sounds kind of microkernel like but there is a key different.

As you said Microkernel isolating memory areas used by kernel sub systems this is right and does not match what being done here.

The address space isolation is talking about isolating memory on a per process or group of process level. This will also extend up to kernel sub systems. So if X application is not allowed to access X memory. When X application does a kernel syscall/subsystem call and when the kernel is processing that request X memory is still not accessible. Also application can declare memory that is only accessible to X application userspace mode so when syscall that memory is hidden as well. This is a different behaviour to Tanenbaum Microkernel.

pabloski Tanenbaun has a functional example of what he calls a microkernel its Minix it does not have this feature either. This is a new idea.

This gives item like ZFS on Linux another headache running a file system cache not align with Linux kernel memory management will in time come a feature of adding security flaws.

[NotMine999]

Don't worry. It's just a filesystem.

it's a file system module, wtf is there to "play with others", you either use it or you don't.

[starshipeleven]

Don't worry. It's just a filesystem.

what does this have to do with anything else in the thread and the article?

[pabloski]

How did you get to such stupid conclusions?

Ok genius, then explain to us what is this "address space isolation" thing about.

[pabloski]

The address space isolation is talking about isolating memory on a per process or group of process level.

User processes or kernel processes? I admit I don't know what they are doing in detail. Are they trying to start a process for each "group of kernel functionalities". Something like "the DRM subsystem runs in this process, the memory manager in that process, etc..."?

So if X application is not allowed to access X memory. When X application does a kernel syscall/subsystem call and when the kernel is processing that request X memory is still not accessible.

I see. A sort of virtualization of the kernel address space, so applications can be jailed and forced to access ONLY pre-approved kernel memory areas. I wonder how this thing can be implemented. CPUs don't have this sort of granular control over virtual memory. Kernel enforced? Better then the current state of affairs, but vulnerable to vulnerabilities in the code that enforces this "software virtual memory" kind of thing.

Also application can declare memory that is only accessible to X application userspace mode so when syscall that memory is hidden as well.

If I understand correctly, a userspace application declares what memory regions it is interested it when it starts. Then the kernel enforces this "promise".

This gives item like ZFS on Linux another headache running a file system cache not align with Linux kernel memory management will in time come a feature of adding security flaws.

This thins is a big change in memory management. There will be every sort of problems for drivers, filesystems, and so on. But I think this must be done, because there is no other way to protect the kernel from the recent CPUs vulnerabilities. The hardware guys have made a mess.

[oiaohm]

User processes or kernel processes?

This is a horrible all of the above if you had watched the video. This is a major rework.

I see. A sort of virtualization of the kernel address space, so applications can be jailed and forced to access ONLY pre-approved kernel memory areas. I wonder how this thing can be implemented. CPUs don't have this sort of granular control over virtual memory. Kernel enforced? Better then the current state of affairs, but vulnerable to vulnerabilities in the code that enforces this "software virtual memory" kind of thing.

CPU do have this level of granular control with page tables just not something operating systems have taken major advantage of. It starts Kernel page-table isolation idea then developers went hang on CPU don't have a limit on how many page table sets you create. If we just create a few more we can do a little more isolation than we currently do.

If I understand correctly, a userspace application declares what memory regions it is interested it when it starts. Then the kernel enforces this "promise".

Not quite process private memory can be requested at any time in the applications run-time. So application request private memory its only listed in the page table that is displayed when the application is running not listed in the page table the kernel when in syscall will be using to access the application. This can be done in time for in kernel processes as well.

Declared at start will be like isolated Sl*b and page cache.

This level of granular control no micro-kernel I know of attempted to go after.

[Volta]

Ok genius, then explain to us what is this "address space isolation" thing about.

Are you blind or something? Oiaohm already explained.