What security risk exists in blitting together memory buffers and doing some alpha blending? Because that's all compositing is. And Linux, Windows and all the other popular OSes all use memory regions that are shared between the kernel and userspace in ways that are far worse than for putting together an image to display.Your supposed security concern is a total non-issue.
There's no possible way that data which will only ever be read as raw pixel data, Z tested, alpha blended, and then copied to a framebuffer can compromise security or allow any unauthorized code to run at kernel privilege level. It's impossible. These memory regions are never mapped as executable and we use CPU features to prevent the kernel from ever executing or even being able to access pages that are mapped as userspace pages and not explicitly mapped as shared memory with the kernel i.e. double mapped into the higher half. So there's literally an MMU preventing in kernel compositing from even possibly being a security issue.
Why? It can be fully automated just like dynamic module download and loading are.
Incremental compilation means you don't have to recompile everything just compile the new driver as a library and relink the kernel and you're done. Keep the prior n number of working ones around in case the new one doesn't work.
That's going to tentatively be handled in kernel unless there good reason to do otherwise. The idea is to expose low level hardware interfaces across the board and this seemed to be the best way to multiplex actual hardware framebuffers while still keeping things low level.
From there each application can draw its own GUI and respond to events that happen in its panes like a mouse button down event while the cursor is at some coordinates and so forth using event capabilities. What any event or the contents of a pane mean to the application doesn't matter to the OS and the application has full control over all of its resources and its execution environment with the exception of not being allowed to do anything that could harm any other part of the system outside its own process abstraction. That's my rationale for why the display system and input events should work that way. Plus it helps latency to keep all of that in the kernel especially since we're doing all the rendering on the CPU and are thus bottlenecked by the CPU's memory bus having way lower throughput compared to that of a discrete GPU. But that's the way it has to be since there are basically no GPUs out there with full publicly available hardware documentation as far as I know and believe me I've looked far and wide and asked around. Eventually I'll want to port Mesa because redoing all the work develop something that complex and huge just isn't pragmatic.
Even a fully loaded kernel with loads of drivers isn't that big. And not all of it has to be resident in memory at all times. Code in general is miniscule compared to data. And most of a kernel's data isn't baked into the executable. And this kernel in particular has very thin drivers that only abstract real devices to generic device class interfaces that userspace has to deal with directly. That's the part that's inspired by exokernels and hypervisor paravirtualization. That means that drivers for this kernel will be even smaller than those for other ones like Linux.
Thanks. And there isn't much of a permanent team so far so if anyone wants to help then I'd be happy to hear from them on our Discord, Matrix or by email at [email protected].
Thanks and that was one of my main motivators for starting this. There just arent any options out there that aren't POSIX or Windows. I guess there's Haiku but even that's based on an older OS.
Plan 9 is novel compared to Unix which almost every OS in common use mimics. But the reference to Plan 9 was more as a nod to its namespace and suitability for distributed computing which partially inspired my design.
They shouldn't have to. OS interfaces including commandline ones should be user oriented not bogged down by Unix dogma that was created wwhencomputerss used physical text terminals as their primary I/O device. It's not the 60s anymore and modern PC, servers, and embedded devices aren't ancient mainframes with physical terminal hardware where making everything appear to be a file and using convoluted scripting interfaces like the Unix shell made at least some sense.
If there's enough demand for dynamic kernel modules they can be added later. That's not a feature that you have to build ypur whole kernel around from that start. Linux definitely didn't but it has it now so it's definitely that can revisited or even made an opt-in feature.
Incremental compilation makes that a lot less heavyweight than you would think and the idea is to automate the process so the average non-technical user doesn't need to know or care how it works.
The plan is to hand out panes which are just memory buffers to which applications write pixel data as they would on a framebuffer then when the kernel goes to actually refresh the display it composites any visible panes onto the back buffer and then swaps buffers. There is nothing unsafe about that any more so than any other use of shared memory regions between the kernel and userspace and those are quite prolific in existing popular OSes.
If anything the Unix display server nonsense is overly convoluted and far worse security wise.
There's a note in the repo that clarifies the meaning of the GPLv3 regarding the use of combining covered works with proprietary libraries when the resulting combined work is never conveyed. It doesn't modify the license, it just explains what it means in that specific case as we interpret it.
Also to be clear I am not a lawyer and nothing I say constitutes any form of legal advice.
The only thing political about this project so far is that I insist on it being free software and also free from tivoization. Well that and not going to insane lengths to support hardware whose vendors are clearly hostile to third party operating systems and free software in general like Apple and Qualcomm.
There's no possible way that data which will only ever be read as raw pixel data, Z tested, alpha blended, and then copied to a framebuffer can compromise security or allow any unauthorized code to run at kernel privilege level. It's impossible. These memory regions are never mapped as executable and we use CPU features to prevent the kernel from ever executing or even being able to access pages that are mapped as userspace pages and not explicitly mapped as shared memory with the kernel i.e. double mapped into the higher half. So there's literally an MMU preventing in kernel compositing from even possibly being a security issue.