X.Org Server Hit By New Local Privilege Escalation, Remote Code Execution Vulnerabilities

[c117152]

I used tuigreet https://github.com/apognu/tuigreet as a login manager for sway, it was extremely lightweight (might be even more than lightdm in terms of resource usage at runtime).

Looks good. But, per usual, debian is slightly behind: https://bugs.debian.org/cgi-bin/bugr...gi?bug=1010247

Might be fine on one of my other boxes but I have storage to spare on those so that's a pass.

[NobodyXu]

Looks good. But, per usual, debian is slightly behind: https://bugs.debian.org/cgi-bin/bugr...gi?bug=1010247

Might be fine on one of my other boxes but I have storage to spare on those so that's a pass.

Their release provides prebuilt binaries https://github.com/apognu/tuigreet/releases , perhaps you can use these prebuilt binaries.

[c117152]

Their release provides prebuilt binaries https://github.com/apognu/tuigreet/releases , perhaps you can use these prebuilt binaries.

Like the debian bug I've linked earlier explained, the issue is the missing greetd daemon. Once that makes it into debian (systemd units included...) I'll pick up the greeter.

[NobodyXu]

Like the debian bug I've linked earlier explained, the issue is the missing greetd daemon. Once that makes it into debian (systemd units included...) I'll pick up the greeter.

Thanks for pointing it out!

I should definitely check the link next time.

[ayumu]

Or opposite. Microkernels are struggling so far and they're joke when comes to performance. Wake me up when microkernel becomes something more than a layer.

I'm sick of that myth.

https://blog.darknedgy.net/technology/2016/01/01/0/

[oiaohm]

I'm sick of that myth.

https://blog.darknedgy.net/technology/2016/01/01/0/

https://blogs.windriver.com/wind_river_blog/2021/05/monolithic-kernel-or-microkernel-for-rtos/

Problem is the difference is not myth. Parties in embedded space that use a lot of microkernels will tell you that the performance difference is there. Does this performance difference end up being deciding choice in all cases no. Sometimes you take the performance hit to have drivers and so on more isolated from each other. Some cases it a performance hit so that you can in fact have third party drivers without the headaches.

Monolithic design is not without it problems. Fuse come into existence for developing file systems with linux because it was simpler to test out file system theory in user space than kernel space. Microkernels design at times can make particular issues simpler to debug than pure monolithic. There are ways that Microkernels can make your life worse as well.

Monolithic is a lot harder to do security due to more parts sharing the the same memory space. Lot harder to audit for security.

ayumu the reality here is what Volta stated is not myth. Its a over statement because its not as bad as people make out. They make out that the Microkernel performance is that bad compared to monolithic that you would have no reason to choose Microkernel that is not the case.

Is Microkernel performance generally poor vs monolithic the answer is yes. Is this performance cost of the Microkernel able to be offset by its advantages in many use cases the answer is again yes.

Lot of people think of windows as hybrid when it core is really Microkernel and why it has stablish kernel driver ABI is the effect of the Microkernel design. In history the operating systems with stable third party driver support are at core all Microkernel designs.

There is upsides to the Microkernel design and down sides was well as upsides to the monolithic design and downsides. Like it or not Monolithic design generally have the performance advantage. Also like it or not Microkernel generally have the security and third party driver advantage.

Why I say generally its always possible to make a OS badly that it does not perform up to expectations. The reality is the advantages and disadvantages of Monolithic and Microkernel have not changed in decades.

Reality I am sick of both sides trying to claim the problems either Monolithic or Microkernel have from the core design is a myth because they find pair of Monolithic and Microkernel OS that seam to show something counting to the core design features.

Its really simple to forget a OS Monolithic can be code poorly in particular areas so perform badly so compared to a Microkernel OS then use this error to claim Microkernel has good performance when in reality the design design does not.

Its also really simple to claim like a monolithic kernel can have third party driver support until notice now much of the monolithic kernel design you have to give to have it and the performance cost. The reality is a lot fo the Microkernel performance cost is equal to the cost to have third party driver support.

The core issues with Monolithic kernels and Microkernels is true. Every time you attempt to work around one of those core issues with Monolithic it comes with a performance cost. Every time you attempt to work around Micro-kernel design issue you end up costing security with the extreme case being windows NT hybrid kernel.

The reality here there is no free lunch and the faults are not Myths. Yes the list of issues with Micro-kernel and Monolithic end up being a list of trade offs. More performance equals less security and more security equals less performance is what it basically comes down to with the differences in design choice. There extra item you remember quality of implementation. A poor quality implementation you cannot get the best performance or best security.

[ayumu]

ayumu the reality here is what Volta stated is not myth. Its a over statement because its not as bad as people make out. They make out that the Microkernel performance is that bad compared to monolithic that you would have no reason to choose Microkernel that is not the case.

Is Microkernel performance generally poor vs monolithic the answer is yes. Is this performance cost of the Microkernel able to be offset by its advantages in many use cases the answer is again yes.

With a multi-server, microkernel design, the so-called performance issue has always been the fact that, due to the multi-server, it needs a lot of context switches to pass messages around. In short, it's been down to IPC cost.

And thus Liedtke's shown us, in the early 90s, that it is very much possible to design a microkernel to minimize IPC cost, thus effectively mitigating this. That's what L3 and then L4 were.

The current state of the art (seL4) has IPC cost that's down to a few hundred cycles, or a few hundred nanoseconds with contemporary microarchitectures and clock speeds. This is in stark contrast with popular, widely deployed monolithic kernels such as Linux, to the point where, even with the architecturally imposed increase on IPC, Linux ends up actually spending more time doing IPC anyway; Any potential performance advantage derived from Linux architecture is thus not realized.

But even this is ignoring the new SMP reality, where relatively common monolithic architectures such as Linux and FreeBSD do require the band-aid which are fine-grained SMP locks, in order to let more than one processor run the kernel at once, which you need to do when your kernel is huge (otherwise your performance tanks). Monoliths are thus ill-suited to the hardware they run on, whereas multi-server architectures naturally map well to SMP, and microkernels such as seL4 have such short supervisor mode paths that adding locks would do more harm than good (complete with a published paper on exactly this).

There extra item you remember quality of implementation. A poor quality implementation you cannot get the best performance or best security.

And this is an excellent place at which to throw a reminder Linux's code quality is extremely low, and this is an unavoidable consequence of its non-tractable complexity; Millions of LoCs with no compartmentalization; Any code can call any code. Linux call graphs are a thing, so are kernel maps; I have a poster on my wall, it looks like spaghetti. And it's a pretty old poster (2.4). It got much, much worse since.

In the present, the overhead derived from this mess is such that trivial changes to Linux aren't even trivial anymore, and non-trivial changes require humongous effort.

Thus, Linux is ripe for replacement. A well-architected system with actual effort put in compartmentalization (implying solid APIs), microkernel or not, is going to leapfrog it; this is an inevitability. It's a question of when. But, for now, I'll keep using Linux for most tasks as I have for over 20 years now, as it's presently, still, the least painful system to use most of the time.

[oiaohm]

With a multi-server, microkernel design, the so-called performance issue has always been the fact that, due to the multi-server, it needs a lot of context switches to pass messages around. In short, it's been down to IPC cost.

And thus Liedtke's shown us, in the early 90s, that it is very much possible to design a microkernel to minimize IPC cost, thus effectively mitigating this. That's what L3 and then L4 were.

So far so good.

The current state of the art (seL4) has IPC cost that's down to a few hundred cycles, or a few hundred nanoseconds with contemporary microarchitectures and clock speeds. This is in stark contrast with popular, widely deployed monolithic kernels such as Linux, to the point where, even with the architecturally imposed increase on IPC, Linux ends up actually spending more time doing IPC anyway; Any potential performance advantage derived from Linux architecture is thus not realized..

Now you just jumped off cliff. There is something very interesting how many IPC solutions does the Linux kernel have? Lots in fact. There are IPC in the Linux kernel that are only a few hundred cycles.

But even this is ignoring the new SMP reality, where relatively common monolithic architectures such as Linux and FreeBSD do require the band-aid which are fine-grained SMP locks, in order to let more than one processor run the kernel at once, which you need to do when your kernel is huge (otherwise your performance tanks). Monoliths are thus ill-suited to the hardware they run on, whereas multi-server architectures naturally map well to SMP, and microkernels such as seL4 have such short supervisor mode paths that adding locks would do more harm than good (complete with a published paper on exactly this).

Linus torvald in 1992 tells you that microkernels don't magically fix the SMP or NUMA problems this is true today. Being a monolithic does mean you majority of the locks in the one project so you can run systems simply looking for lock errors. One of the nightmares that have harmed hurd and minix development have been locking issues.

And this is an excellent place at which to throw a reminder Linux's code quality is extremely low, and this is an unavoidable consequence of its non-tractable complexity; Millions of LoCs with no compartmentalization; Any code can call any code. Linux call graphs are a thing, so are kernel maps; I have a poster on my wall, it looks like spaghetti. And it's a pretty old poster (2.4). It got much, much worse since.

In the present, the overhead derived from this mess is such that trivial changes to Linux aren't even trivial anymore, and non-trivial changes require humongous effort.

Thus, Linux is ripe for replacement. A well-architected system with actual effort put in compartmentalization (implying solid APIs), microkernel or not, is going to leapfrog it; this is an inevitability. It's a question of when. But, for now, I'll keep using Linux for most tasks as I have for over 20 years now, as it's presently, still, the least painful system to use most of the time.

https://www.usenix.org/system/files/atc20-gu.pdf

There is a problem please note the charts where they say monolithic in this white paper is the Linux kernel. The result is Linux kernel kicked the ass of all the existing microkernels in 2020 with real workloads.

Any code can call any code is where a lot of different performance advantages that the Linux kernel over existing Microkernels come from. Compartmentalisation is not a free. Yes higher performance of monolithic come with more complex code and when locking is done right more fine grained locking. Microkernel IPC happens to get in the way of being able do the case of not IPC. You are holding the lock of X already so you can go off and do Y task with a monolithic that is in a different subsystem that would require X lock Now Microkernel you have to IPC in that case.

So your idea that the Linux kernel is ripe for replacement nicely skips over that existing microkernels including sel4 have trouble keeping up in performance with the Linux kernel. Yes the Linux kernel is not the best possible monolithic kernel.

Also note that you said looks like spaghetti. Perfectly code spaghetti code is faster than OOP code in many cases. The issue why we use OOP so much is that spaghetti has a horrible maintenance cost. To the point that the overhead maintaining spaghetti code can get worse than completely rewriting the thing again.

Maybe in future we value security/maintainability more. Linux kernel has developed a lot of tools to make the speghetti mess of the Linux kernel more maintainable than it would be other wise. This is the other side of this. With the Linux kernel getting better tools for testing it code base and possible moving to rust will microkernel compartmentalisation be as important.

There is the serous possibility for us in future to look back and go Monolithic design was the right choice just it required the right compiler tools to make sure humans could not do stupid coding errors.

ayumu like it or not microkernel is not yet a proven clear cut winner. There are enough examples that say monolithic designs should not be underestimated. Yes monolithic designs to be as secure as microkernel designs will need improvement in programming languages and tools and compilers.

ayumu so it is a serous question what are you measuring. Performance or "security/maintainability". Yes maintainability decreases as performance goes up in OS design same with the reverse with the history tools. Will this rule apply into the future? This is a never say never problem. Like it or not the winner is not decided.

The question really is can microkernel or monolithic kernel design in fact over come their limitations. Microkernel development improvements has been slowing so not showing sign of catch up to the monolithic designs this comes clear in the 2020 papers on the topic to current day. The tools to over come the limitations of monolithic design are still improving at almost the same speed they were for the past 2 decades. So its not possible to project how far the improvements on the monolithic side will go.

[ayumu]

There is something very interesting how many IPC solutions does the Linux kernel have? Lots in fact. There are IPC in the Linux kernel that are only a few hundred cycles.

That's news to me. Linux has a shitton of IPC "solutions", but *none* are good or efficient, and most certainly none of them are anywhere near "a few hundred cycles".

In fact, Linux doesn't have any fast paths with guaranteed maximum latency. Everything is Best Effort.

Linus torvald in 1992 tells you that microkernels don't magically fix the SMP or NUMA problems this is true today. Being a monolithic does mean you majority of the locks in the one project so you can run systems simply looking for lock errors. One of the nightmares that have harmed hurd and minix development have been locking issues.

Linus in 1992 predates Liedtke's work. His knowledge of microkernels is extremely out of date, and continues to be.

https://www.cosy.sbg.ac.at/~clausen/...-rebuttal.html

There is a problem please note the charts where they say monolithic in this white paper is the Linux kernel. The result is Linux kernel kicked the ass of all the existing microkernels in 2020 with real workloads.

Uh no, you seem to have misunderstood the paper. It isn't about Linux at all. Linux isn't even a system discussed (past a few passing mentions) or benchmarked in there. Linux is basically a potato, performance-wise, relative to everything talked about in there. This paper talks about actual state of the art OS research which has nothing to do with Linux.

The question really is can microkernel or monolithic kernel design in fact over come their limitations. Microkernel development improvements has been slowing so not showing sign of catch up to the monolithic designs this comes clear in the 2020 papers on the topic to current day. The tools to over come the limitations of monolithic design are still improving at almost the same speed they were for the past 2 decades. So its not possible to project how far the improvements on the monolithic side will go.

If you believe this, it means you have missed some 30 years of operating system architecture research (and commercial deployment).

This should be enough to get you started, should you have an actual interest in the subject.

https://docs.sel4.systems/projects/s...mentation.html

https://microkerneldude.org/

Understand I don't hate Linux; I use it everyday, for most tasks, and have for over two decades. I just recognize it for what it is: A really messy implementation of an obsolete architecture and something to eventually get completely replaced.

[oiaohm]

That's news to me. Linux has a shitton of IPC "solutions", but *none* are good or efficient, and most certainly none of them are anywhere near "a few hundred cycles".

The fast IPC in the Linux kernel is not a few hundred cycles its 24 cycles. https://www.usenix.org/system/files/atc20-gu.pdf Yes this 24 cycles in figure 5 page 409. The fasted Microkernel Cross-server IPC is 109 and that not sel4. sel4 is 1450 cycles. The reality when it comes to Cross-server IPC Linux kernel is insanely fast.

Remember everywhere in that 2020 paper where they write monolithic is the Linux kernel. Is 24 cycle IPC as fast as a monolithic kernel in theory could go the answer is no. Wind river monolithic kernel gets it down to 16. So yes for a monolithic kernel IPC Linux kernel best IPC is horrible inefficient. But compared to microkernel IPC they are not in the same ball park. Microkernel IPC even the most effective for is still horrible in performance. Yes best micro-kernel IPC is fact of 4 worse than the best Linux kernel monolithic IPC.

Remember that 2020 paper is written by a pro Microkernel person. They are not trying to prove that Monolithic kernel designs are good. They were validating a Microkernel ideas and decided to properly bench it.

In fact, Linux doesn't have any fast paths with guaranteed maximum latency. Everything is Best Effort..

https://wiki.linuxfoundation.org/realtime/rtl/blog

Totally not true. What you just describe is what the real time patch set to the Linux kernel provided and has been progressive merged.

Linus in 1992 predates Liedtke's work. His knowledge of microkernels is extremely out of date, and continues to be.

No you just quoted some incorrect personal option you did not read that 2020 research paper did you. The reality is when parties in fact when and did proper checks in 2020 Linus 1992 statements turn out to be correct,

Uh no, you seem to have misunderstood the paper. It isn't about Linux at all. Linux isn't even a system discussed (past a few passing mentions) or benchmarked in there. Linux is basically a potato, performance-wise, relative to everything talked about in there. This paper talks about actual state of the art OS research which has nothing to do with Linux.

No you need to have read the paper 2020. The paper tells you that monolithic is the Linux kernel and then goes and references it as monolithic for the remainder of that 2020 paper. Yes that 2020 paper I pointed to had the real cost of the Linux kernel IPC.

If you believe this, it means you have missed some 30 years of operating system architecture research (and commercial deployment).

No you have missed something. Lot of papers are written either Microkernel theory or Monolithic theory. Very few paper over 30+ years properly start comparing the two.

The 2020 paper I pointed to is one of the rare ones that do compare. Other problems also all these papers are incorrectly biased. Notice how the 2020 hides that Linux is monolithic reference. Then uses Linux kernel valves all call monolithic on every chart and all the Microkernels get individually named every chart. So yes you have old paper cooking the results the same way pick a really bad monolithic call it monolithic then write that as monolithic on every chart so hiding their deceptive choice. This leads to the false presume that Microkernels have really good IPC when in reality compared to a Linux kernel or wind river or many other high performance monolithic kernels the IPC is insanely slow on Microkernels.

ayumu; like it or not you are writing a huge stack of stuff not based in fact. The fact Microkernel IPC is slow compared to equal item frame monolithic kernels. Not a little slow Yes L4 work reduced Microkernel IPC overhead. But you you think that the Linux kernel and other monolithic kernels has not improved IPC over the years? This is the catch Linux kernel IPC cost has decreased faster than the Microkernel IPC cost.

Really that 2020 paper the way it written should show you how you were tricked ayumu. Yes they write up the compare data that shows that Microkernels have serous problems a so called state of OS research and try to hide the Monolithic kernel they are really comparing to.

However, compared with a monolithic OS like Linux

Yes that 2020 paper also like being ultra vague what the monolithic on their charts really is. So you have statements like this instead of saying our monolithic reference is the Linux kernel,

Yes 24 cycles figure 5 page 409 is in fact Linux unique value. Freebsd comes in at 28. Wind river is 16 and so on. 24 is not where the average lands either.

Lot of parties are not going to invest in Microkernel research if they are clearly seeing that its poorly performing. The Microkernel world is very guilty of attempt to sweep their issues under the rug and hope nobody notices. Sorry a party like me notices.

The reality Linus 1992 statement on Microkernel IPC being horrible slow is still just as true today. Yes even those doing the old L4 compares to monolithic also end up cooking the books by hiding what monolithic kernel they are really comparing to. Linux kernel with big kernel lock was not good performance.

The Microkernel camp is really serous-ally guilty of doing deceptive papers. At least most the time they don't publish totally fake values. But they do publish all the time not correctly labelled values. Yes every chart in that 2020 paper that has monolithic written on it should have the monolithic replaced with the word Linux because those values are only a representative of Linux not Monolithic kernels in general or the best performance monolithic kernels..

Yes ayumu it about time people start giving these people writing these microkernel papers a slap on the back of head and say you will write what you are comparing to properly. Yes some of the reason why work to improve microkernel IPC has been so slow because there is paper after paper written in such way that attempts to hide the fact that Microkernel IPC is slow.

Yes sel4 claim about being the fastest Microkernel that is also disproved in that 2020 paper I have referenced.

Yes ayumu you have kept on claiming that Linux kernel is poor performance even when I dropped a 2020 paper in front of you that showed the exact other way because the people doing these papers are writing them in ways to hide this truth. Yes it not well hidden when you know what you are looking at.