> Now, is it exploitable that `find` also reads the uninitialized auto variable `status` (UB) from a `waitpid(&status)` before checking if `waitpid()` returned error? (not reported) I can't imagine an architecture or compiler where it would be, no.
The only signal handler find installs is for SIGINFO, and it uses the SA_RESTART flag, so EINTR can be ruled out. The pid argument is definitely valid as you can't reach the above if it wasn't, and there's no other way for the child process to be reaped[1], so no ECHILD.
A check should probably be added in case the situation changes in the future, triggering spooky action at a distance, or were that code to be copy+pasted somewhere where the invariants didn't hold. But I think the current code in its current context is, strictly speaking, correct as-is.
[1] OpenBSD lacks the kernel features for such surprises that might theoretically be possible on Linux.
Indeed. That's why I didn't deem it worth reporting.
But in my code, I would have fixed for the reasons you mention. Sprinkle enough of these around, and some low percentage will in the future have its assumption invalidated.
No. You only get EINTR when a signal handler fires and you didn't use the SA_RESTART flag with sigaction. If you don't install any signal handlers, or you use SA_RESTART on all handlers, or you've blocked/masked all signals (or at least the ones with handlers), you won't get EINTR.
When writing library code, it's important to consider EINTR because you can't know about signal dispositions. Though, the common practice of looping on EINTR kind of defeats the purpose.
unveil was designed and intended to effectively sandbox root when combined with sufficiently strict pledge permissions. I don't think this exploit would have effected any existing OpenBSD services, but sometimes services need to keep around processes with higher privileges than the network-facing process, yet you still want to sandbox them as much as possible. For example, sshd uses a special auth process, and that process needs higher privileges to be able to access the password database. On OpenBSD this auth process doesn't need root, but there may be similar cases where you want to use unveil with a root process for defense-in-depth. Suffice it to say, it would be foolish to only use unveil with such processes.
The bug here actually involved the intersection of unveil and pledge. IIUC, it was more a pledge bug that accidentally allowed bypassing unveil checks.
All OpenBSD services, including HTTP (httpd), SMTP (smtpd), and DNS (nsd, unbound, unwind), use privilege separation and sandbox themselves with pledge and either unveil or chroot. There's no extra configuration. And the developers dog-food these services; it's why they're in the base system.
How many Linux services use seccomp? Or chroot, mount namespaces, or landlock? If they do at all, it's usually imposed externally by systemd or docker, in which case they usually run with overly broad permissions because there's no integration with the specific application code, thus the AF_ALG exploits in containers. On OpenBSD services continue to narrow their privileges after starting up so by the time an external request is serviced they have only minimal access to syscalls and the filesystem, often only read/write/send/recv syscalls, and if open is allowed only the specific files and directories needed to service requests. Typically even the network-facing daemon accepting TLS connections doesn't have access to the private key--you simply can't do that by running a vanilla service application in docker.
Does OpenBSD have bugs? Of course. The question is, which environment has more trustworthy backstops? The Linux kernel provides all the facilities, but they're not used effectively, for many reasons.
Mencken's cynicism and mockery were arguably the type of thing Kierkegaard lamented, and perhaps in a sense were more a cause of social breakdown more than a consequence.
From reading his journals the editor of the Corsair publicly mocked him and used the paper to hide behind (in the name of journalism). His lamentations on journalism are very much due to this personal attack and he does name the perpetrator in his writings.
Kierkegaard himself had his targets for cynicism, primarily the state church (Danish Lutheran) that he attacked endlessly in his writings.
Russia also does this, with both drones and missiles. It also sends cheap decoys mixed in with the Shaheds, because it turns out they're not as cheap and plentiful as people think, especially when you're trying to hit hard targets.
The concept of fundamental human rights is certainly new, but our notion of intrinsic human value (and intrinsic value of other life and things) arises from our empathy, which at least in its degree is perhaps our most important defining trait as a species. (Our empathy may have been a prerequisite for the emergence of our intelligence.)
Conflating the two is why some people have trouble understanding why religions like Buddhism and Christianity seemed to tolerate so much inequality and violence; or more generally just assumed people writ large were historically more callous and uncaring than today.
Arguably one of the downsides, though, to a focus on rights vs intrinsic value is that rights are typically couched in materialist terms. Most of the time that's probably for the better, but sometimes maybe not.
Dogs show empathy towards not only dogs and humans, but even baby birds and rabbits - animals which one would expect to be viewed as pure caloric units, sans empathy.
Whales show empathy towards their young, and towards humans.
Male "loner" lions have been known to show empathic protection toward human and antelope young in the bush.
It's increasingly hard to define a clear difference between Humans and "mere Animals"; empathy is emphatically not a clear difference.
To date, fear of vacuum cleaners may well be the only known difference.
Sure, just like many other animals exhibit analytical intelligence and complex communication. The seeds are there. The distinction is by degree, but the gap is pretty wide in all three cases.
No other species has been shown to systematically display non-kin, non-mating-system altruism (for which empathy is probably an integral component). It seems likely you need systematic non-kin altruism to achieve the ubiquitous, complex cooperation humans exhibit. And that complex cooperation is probably a prerequisite to make our degree of intelligence evolutionarily profitable. Otherwise human-level intelligence should be more common than our immediate lineage. (Some cousin species may very well have been smarter or more cooperative than us; relatively speaking it could be homo sapiens found a more effective equilibrium. Nonetheless our immediate lineage seems to be the only one to break through the selfish gene bottleneck that restricts other species along these axes.)
Lasers obey the inverse square law as perfect collimation isn't possible. But I guess as a practical matter it does make it easier to achieve a particular energy level at a target. You still apparently need megawatt scale lasers just to discern a signal from Alpha Centauri, though: https://academic.oup.com/mnras/article/516/2/2938/6668809 (I dunno how to calculate the other way around--from here to there--as it's partly a function of the origin star's luminosity.)
Those type attributes are also used for the x86 intrinsics API, and they override default C behaviors like promotions and presumptions around aliasing (ironically they make type punning easier, though maybe it was just the few use cases I explored, and this isn't an area where I have alot of experience). C23 also gained the _BitInt type, which discards all the old promotion rules, which should help autovectorization.
I think ISPC is still the proper way to go. But these days everybody wants One Language to Rule Them All along with standard libraries for doing everything out-of-the-box. And while in principle ISPC's approach could be stitched into C or C++ in a fairly clean manner (perhaps with well-defined and enforced segregation of constructs to minimize complexity), it's just not gonna happen: C++ is too enamored with constructing libraries through deeply complex templated types (hammer, nail, yada yada), and C is just too conservative (though if GCC or clang went the distance with a full implementation, there's a good chance the C committee would adopt it).
https://arxiv.org/pdf/2011.07966.pdf
Most law generally is non-monotonic. (See https://en.wikipedia.org/wiki/Non-monotonic_logic) The French tax code is one of the few exceptions.
reply