Posts by ilpr 12 publicly visible posts • joined 13 Oct 2023
Protecting from timing attacks is not about instructions, it is about timing: if you have a constant length wait after unsuccesful guess you don't need to mess around with any of these.
And proper hashing is meant to prevent guessing the original password since changing one bit will change the whole hash thus making it unguessable.
Problem isn't the compiler here - it is allowed to do these kind of optimizations. The problem is what kind of value you are comparing: if you are using plaintext password sure, attacker might guess something, but one-way cryptographic hashes like SHA are supposed to unpredicatable and secure - precisely for this kind of purpose. So if you are properly hashing (and salting) the password it should not matter what the timing is as you cannot predict the password from the hash.
This all sounds like someone has not understood the meaning and purpose of hashing and has decided to blame to compiler on their iffy code.
Typically these cases happen when there are real problems to solve and the question is should it be fixed or will the can be kicked along the road.
According to blog posts and discussion there are situations with different login types that are hard to solve in a traditional login screen. That is where the system daemon comes in. Combining fingerprints and smartcards was one if I remember correctly, getting that right is not easy for some reasons. It is not something everyone would care about, but there certainly are people who do need that kind of situation handled correctly.
So while some people complain, the goals are clear and beneficial to many people, not just "shiny new things".
Your data scientist may have taken 2+2 and gotten 5 as a result. Your CPU will use addresses and values regardless of what the higher-level language uses, C makes addresses visible to programmer while some languages don't. Whichever language you use, it will eventually be turned into machine code and that is what matters: how the idea expressed in languge is transformed.
Pointers are designed to avoid data copying such as when sorting data: you don't need data copies when you just shuffle around pointers, so that can make certain algorithms very fast.
The main reason why something like Fortran might be fast is because it has implementation of various algorithms that have been tuned over decades of use into most efficient they can be. Not due to "indirection" since in majority of cases the cost would negligble: there are many registers and large caches in CPUs these days, pre-fetch logic to access information and other ways to make them very fast.
It's not entire impossible, recall that various people have taken to task of reducing buffering in network stack due to latency issues.
All you would need is a way to tell the pointy-haired boss how much the RAM usage costs and how much can be saved. That is the only way to make them sign off on the work, put a clear price on the waste.
As always, solution is not in overworking the few, but distributing the work to many. The wealthy try to squeeze most out the few people they have to maximize their own margins, they are not truly talking about benefit to others.
Of course distributing work to more people needs investments in education and such. Guess who don't like that idea either..
Frankly, what did you think patents are for? Their only purpose is to collect money - either by licensing to others or preventing competition to use it.
Earlier it would not have been worth it to start a case if there was no money to be had so it is possible they have been monitoring the situation.
That said, software patents are ridiculous, patents are not meant to prevent ideas to be shared but implementation, yet they are too vague and too broad and used in all the wrong ways. Software is mainly an application of mathematics and shares many concepts with it, one being that there are only so many ways to implement algorithm to get a correct result. So software patents should not be given as easily as they are currently being given. Copyright legislation already has sufficient rights protection for software.
Yes, Xwayland has been used for a long time. It is a "proxy" translating between X11 clients and Wayland compositor.
Note that they are planning to drop Xserver-based session, Xwayland will still be available for compatibility in a Wayland-session.
GLX has been replaced by EGL is various applications like Firefox. Even better, many application use DRI which bypasses the need for GLX entirely.
VNC is a working solution for remote desktops. X11 hasn't been network transparent for ages since DRI uses shared memory: it has been "network aware" but the transparency has been in the minds of the users for a long time. This isn't the 1980's X11 any more..
The Bergamo performance might have improved thanks to other changes in the kernel (less migrations from near-idle cores on EPYC-CPUs). EEVDF mainly helps with task latencies and not specifically any CPU specific things. EEVDF is there to replace CFS scheduler and reduces the amount of heuristics that has accumulated.
XWayland does support the X11 clients. The difference is that it isn't interfacing with the hardware, but it is simply Wayland-client.
So, you can use all the testing you use otherwise.
X11 was always a message-based protocol over sockets. So you can use the Xlib-library that sends the commands to Xwayland.
You never called X-server directly since it was supposed to be "network transparent" (in practice that required a lot of low-level code to do that but that was what user saw).
Wayland does the same thing: it is message-based but the protocol is different.
Why is the protocol different? Imagine you are switching to a modern locomotive (a train) from a coal-powered one: what can you re-use? Not a lot.
More efficient than one set of "drawing commands" is to have no drawing commands at all. This is what practically every implementation uses these days - including X. The drawing commands for X11 were designed in the 1980s and seemed like a good idea at the time. Soon afterwards people started sending bitmaps instead of commands for performance reasons. And then there are all the various needs that software like electronic design tools and word processing want different commands. These days with DRI-interface all of the old X11 drawing is bypassed but it is still carried along to be able to say that the protocol is supported.
Another example are the fonts. Back when X emerged (with all the terminals and thin clients) it was though of as a good idea to have a font server. When personal computers were used the fonts were on the same computer so that wasn't needed. Instead, fontconfig appeared and clients choose what fonts they want to use directly. There's of course all kinds of fonts these days like OpenType, TrueType, PostScript etc. in addition to the X fonts and some use bitmaps and some use vectors and so on. So clients can pick the library they want to use and render the fonts with that instead of expection X server to have support for every case.
Having a single place to do everything (like a server) sounds good until people start to come with ideas of how they want to do things differently. And there are tons of different GUI toolkits that all want to draw in different ways.
XWayland is basically lightened X-server without the things that Wayland does, namely rendering.
Wayland itself is much lighter than X since it has no "drawing" commands and such - these are explicitly in the client toolkits.
Here's the thing: most X-clients already use client-side drawing in their toolkits, but X carries a lot of legacy baggage to keep backwards compatibility with ancient applications. Not that they are ever used these days..
Wayland is designed so that applications can't see each other: something that X never enforced but trusted that application developers "play nice" with it. X11 was rather horrid thing that is often misunderstood these days..
