Linux Weekly News on kernel and documentation
-
When ELF notes reveal too much
The Linux kernel uses a number of hardening techniques to try to protect itself against compromise; one of those is kernel address-space layout randomization (KASLR). But randomization is of little benefit if the kernel spills the beans on where its code has ended up. As it happens, the kernel has been doing exactly that — since 2007, in a behavior that predates the addition of KASLR. Some changes are in the works to close that hole, but it is illustrative of just how hard some secrets are to keep.
Exploits of the kernel (as with any other program) often rely on jumping into specific code in unexpected ways. Numerous techniques have been developed to prevent this from happening; control-flow integrity mechanisms, for example, exist to prevent execution from being diverted from the intended paths. Other techniques, though, try to make it difficult for an attacker to know where to redirect the control flow to, even if they find a bug that would allow that sort of compromise. KASLR is one of those techniques, built on the observation that, if an attacker does not know where the kernel has been placed in its address space, they cannot redirect control flow to a known location.
The idea behind KASLR is simple enough: at boot time, the actual location for the kernel in memory is chosen randomly. The offset chosen for each boot is different, so an attacker does not know, at the outset, where the kernel lives on any given target machine. If the kernel takes pains not to tell the attacker about its location, it creates an added barrier to successfully exploiting any vulnerability that might exist.
-
A RDRAND followup
In a recent episode, "Pitchforks for RDSEED", we learned that there was some uncertainty around whether hardware-based random-number generators on x86 CPUs could fail. Since the consequences of failure in some situations (confidential-computing applications in particular) can be catastrophic, there was some concern about this prospect and what to do about it. Since then, the situation has come a bit more into focus, and there would appear to be an agreed-upon plan for changes to be made to the kernel.
At the end of the last article, it was noted that there were ongoing discussions within the CPU vendors about whether the RDRAND and RDSEED instructions could fail to generate a properly random number. Proceeding wi
-
Treating documentation as code
At FOSDEM 2024, the "Tool the docs" devroom hosted several talks about free and open-source tools for writing, managing, testing, and rendering documentation. The central concept was to treat documentation as code, which makes it possible to incorporate various tools into documentation workflows in order to maintain high quality.
One software-development best practice is to have a continuous-integration (CI) setup for a project. By automatically running a formatter, linter, and tests on every code change committed to the project's repository, developers can maintain uniform code quality. In her talk "Open Source DocOps", Lorna Jane Mitchell made an argument for applying the same approach to documentation projects.
This DocOps approach, short for "documentation operations", derives from a well-known definition of DevOps, which calls it ""a set of practices, tools, and a cultural philosophy that automate and integrate the processes between software development and IT teams"". Instead of applying these things to software development, DocOps applies them to documentation. Mitchell characterized DocOps as "allowing documentation to be created, maintained, and published collaboratively and in an efficient manner."