'Slashdot reader Mononymous writes:
The latest release of OpenBSD, the FOSS Unix-like operating system
focused on correctness and security over features and performance, has
been released. This version includes newer driver support, performance
improvements, stability fixes, and lots of package updates. One
highlight is a complete port of KDE Plasma 5.
You can view the announcement and get the bits at OpenBSD.org.
Phoronix reports that with OpenBSD 7.5 "there is a number of
improvements for ARM (AArch64) hardware, never-ending kernel
optimizations and other tuning work, countless package updates, and
other adjustments to this popular BSD platform."'
-- source: https://tech.slashdot.org/story/24/04/06/0519207
Cheers, Peter
--
Peter Reutemann
Dept. of Computer Science
University of Waikato, Hamilton, NZ
Mobile +64 22 190 2375
https://www.cs.waikato.ac.nz/~fracpete/http://www.data-mining.co.nz/
Here’s the scenario: there is a malfunctioning server running a really
ancient Linux installation (e.g. 2.6.x-series kernel). You boot up with
a reasonably recent copy of SystemRescue, mount the machine’s
filesystem, try to chroot into it and run a shell ... and it segfaults.
Seems there has been a subtle incompatible change in Linux kernel
behaviour since those times, to do with the disabling of something
called the “vsyscall” mechanism (which is specific to 64-bit x86-based
machines, I understand). This was supposed to be a way to speed up
certain commonly-executed system calls (I think getting the system time
was one of them) by allowing direct transfers to certain entry points
with fixed memory addresses for invoking them.
It was later decided this was a bad idea (I think for security reasons).
The mechanism has not been completely removed (yet), but nowadays it is
disabled by default.
To get around this, you need to boot SystemRescue with a change to the
kernel command-line parameters, adding this item
vsyscall=emulate
After you get to a shell, you can confirm that this setting is in
effect by checking the /proc/self/maps file (the memory mappings for
your own process). At the bottom, there should be an entry with
“[vdso]” in it, and below that another line with “[vsyscall]”. The
presence of the latter line indicates that vsyscall emulation is in
effect. This is not present when I check a process on my own machine,
for example.
Linus is legendary for being a stickler for never, ever breaking
backward compatibility for userland. So the reasons for turning this
off must have been pretty compelling, for him to agree to it. But the
compromise is, it’s still there to be enabled if you really, really
need it.
There’s a bit more technical info here
<https://0xax.gitbooks.io/linux-insides/content/SysCall/linux-syscall-3.html>,
if you are interested.
By the way, the above page is part of a book beginning here
<https://0xax.gitbooks.io/linux-insides/content/>, about the insides of
the Linux kernel. The whole book seems to be accessible from that link,
but if you step up a level, the site doesn’t seem to have any idea
about the existence of that book.
