51–60 of 82 posts
Couldn't this entire class of bug be solved by annotating signal handlers in the source code and checking at compile time that anything called from a signal handler is async-signal-safe?
Earlier quoted context omitted.
Well, the compiler has no way of knowing if a function will later be a signal handler after linking, or even dynamic loading. There is no portable way to annotate all functions ever written or ever will be written as being async signal safe. Which functions are async signal safe varies with the operating system and runtime (eg. an unsafe function in linux-gnu might be safe in linux-musl or linux-bionic). Other than t…
> Well, the compiler has no way of knowing if a function will later be a signal handler after linking, or even dynamic loading. That's why GP suggested annotating them. Typically this would be done via a function attribute. > There is no portable way to annotate all functions ever written or ever will be written as being async signal safe. This is not a requirement for such an annotation to exist and to be used by pr…
That won't help when you link external functions or worse, dynamically load them. Those are things done long after the compiler has run.
> And libc implementations already annotate many of their functions to tell the compiler how they work. Compilers are also more than happy to assume behavior of standard function matches the C/C++ standards in non-freestanding environmnets.
We're not talking about standard functions here, we're talking about any function any developer could ever call in a signal context. Ever. Like, for example, a libssh shutdown function that invokes a callback that calls a syslog function that does some socket operation on a buffer that some other thread has already freed. Which of those functions needs the annotation, and how does dlsym() deal with it?
Earlier quoted context omitted.
The whole point of naming vulnerabilities is to establish a vernacular about them, so it's not surprising that academic papers name them. The literature about hardware microarchitectural attacks, for instance, would be fucking inscrutable (even more than it is now) without the names.
I'd be happy to file all of them under Spectre/MDS, except for the ones that aren't Spectre/MDS, of course. They don't all need unique names. Most of them are all instances of the same pattern: some value is not present in a register when it's needed, and an Intel CPU design continues to execute speculatively with the previous contents of that register instead of inserting a pipeline bubble, leaking the previous cont…
Name them all.
You see the same weird discussions about CVEs, and people wanting to squash CVEs down (or not issue them at all) because the research work is deemed insufficient to merit the recognition. As if recognition for work was ever even ostensibly what the CVE program was about.
Earlier quoted context omitted.
Libc isn't the language runtime. The runtime is '/use/lib/crt*.o', which has no concept at all of signal handling. Libc isn't particularly intrinsic to the language, and outside of some assembly to make syscalls, you can implement an alternative with a completely different interface, purely in C.
I am fairly certain that glibc uses SA_RESTORER in its sigaction wrapper and implements a suitable sigreturn() function which is provided as the sa_restorer argument.
Earlier quoted context omitted.
Enterprises don't go for RHEL because it's free software, yay freedom! They go for it because it gives a very stable, solid foundation. They don't want a fragile base layer prone to breaking every day of the week. This involves backporting a lot of stuff (primarily security fixes) because you can't just upgrade any package to its latest version, it will have entirely new dependencies, potentially breaking changes etc…
Compagnies I've worked for that uses redhat do so because they think paying will prevent them from working. As if, sudenly, running a nearly 10y-old code was no longer stupid, because you paid for it.
If you think about it, all maintained projects of old code has this same mechanism, just has more frequent updates.
How does the age metric now work once you know this ?
Earlier quoted context omitted.
> Well, the compiler has no way of knowing if a function will later be a signal handler after linking, or even dynamic loading. That's why GP suggested annotating them. Typically this would be done via a function attribute. > There is no portable way to annotate all functions ever written or ever will be written as being async signal safe. This is not a requirement for such an annotation to exist and to be used by pr…
> That's why GP suggested annotating them. Typically this would be done via a function attribute. That won't help when you link external functions or worse, dynamically load them. Those are things done long after the compiler has run. > And libc implementations already annotate many of their functions to tell the compiler how they work. Compilers are also more than happy to assume behavior of standard function matche…
No vulnerability name, no website, concise description, neutral tone, precise list of affected distros (RHEL + derivatives and some EOL Fedoras) and even mention of unaffected distros (current Fedoras), plain admission that no attempt was made to exploit. What a breath of fresh air! (I am only joking of course. As a recovering academic, I understand that researchers need recognition, and I have no right to throw ston…
Earlier quoted context omitted.
To be fair, if they couldn't make the decision to use a non-paid distro, would you trust them to be able to manage the updates, the ABI compatibility breakages, and so on once every year or two?
Of course not But again, paying for the distribution does not free you from the sysadmin duties Even worse: because of the long "supported" duration, the common mindset is "fire and forget". After all, why would we care ? That stuff will be "supported" for 10 years, we'll be long gone by then. And when you have high turn-over rate, you hit the champion's title : every thing is legacy, nothing is managed, every thing…
Earlier quoted context omitted.
> the language layer has no knowledge of signal handlers or what that means Despite the fact that there is explicit runtime support for signal handlers in the language runtime (i.e. libc).
Libc isn't the language runtime. The runtime is '/use/lib/crt*.o', which has no concept at all of signal handling. Libc isn't particularly intrinsic to the language, and outside of some assembly to make syscalls, you can implement an alternative with a completely different interface, purely in C.
Couldn't this entire class of bug be solved by annotating signal handlers in the source code and checking at compile time that anything called from a signal handler is async-signal-safe?
Static analysis tools would go a long way here, yes, and it should be a relatively straightforward analysis. You probably don't even need to explicitly annotate signal handlers, just examine arguments to calls to signal() and sigaction().