New in LWN About Linux (Now Outside Paywall)
-
LinuxBoot: Linux as firmware
Both the free-software and security communities have recently been focusing on the elements of our computers that run below the operating system. These proprietary firmware components are usually difficult or impossible to extend and it has long been suspected (and proven in several cases) that there are significant security concerns with them. The LinuxBoot Project is working to replace this complex, proprietary, and largely unknown firmware with a Linux kernel. That has the added benefit of replacing the existing drivers in the firmware with well-tested drivers from Linux.
To understand LinuxBoot and the problem it's working to solve, we first have to discuss how computers actually boot. We usually think of a running system as including the hardware, operating system (OS), and applications. However, for a number of reasons, there are several layers that run between the hardware and the OS. Most users are aware of UEFI (which replaced the older BIOS); for many systems, it prepares the system to run and loads the bootloader. These necessary functions are just the tip of the iceberg, though. Even after the computer finishes loading the OS, there are multiple embedded systems also running on the system entirely separate from the OS. Most notably, the Intel Management Engine (ME) runs a complete Minix operating system, while System Management Mode (SMM) is used to run code for certain events (e.g. laptop lid gets closed) in a way that is completely invisible to the running OS.
-
Shrinking the kernel with a hammer
This is the fourth article of a series discussing various methods of reducing the size of the Linux kernel to make it suitable for small environments. Reducing the kernel binary has its limits and we have pushed them as far as possible at this point. Still, our goal, which is to be able to run Linux entirely from the on-chip resources of a microcontroller, has not been reached yet. This article will conclude this series by looking at the problem from the perspective of making the kernel and user space fit into a resource-limited system.
A microcontroller is a self-contained system with peripherals, memory, and a CPU. It is typically small, inexpensive, and has low power-consumption characteristics. Microcontrollers are designed to accomplish one task and run one specific program. Therefore, the dynamic memory content of a microcontroller is usually much smaller than its static content. This is why it is common to find microcontrollers equipped with many times more ROM than RAM.
For example, the ATmega328 (a popular Arduino target) comes with 32KB of flash memory and only 2KB of static memory (SRAM). Now for something that can boot Linux, the STM32F767BI comes with 2MB of flash and 512KB of SRAM. So we'll aim for that resource profile and figure out how to move as much content as possible from RAM to ROM.
-
Preventing kernel-stack leaks
The kernel stack is a small, frequently reused region of memory in each thread's address space. That reuse allows for efficient memory use and good performance as a result of cache locality, but it also presents a problem: data left on the stack can also end up being reused in ways that were not intended. The PaX patch set contains a mechanism designed to clear that data from the stack and prevent leaks, but an attempt to merge that code into the kernel has run into a snag.
By design, the C language does not define the contents of automatic variables — those that are created on the stack when the function defining them is called. If the programmer does not initialize automatic variables, they will thus contain garbage values; in particular, they will contain whatever happened to be left on the stack in the location where the variables are allocated. Failure to initialize these variables can, as a result, lead to a number of undesirable behaviors. Writing an uninitialized variable to user space will leak the data on the stack, which may be sensitive in one way or another. If the uninitialized value is used within the function, surprising results may ensue; if an attacker can find a way to control what will be left on the stack, they may be able to exploit this behavior to compromise the kernel. Both types of vulnerability have arisen in the kernel in the past and will certainly continue to pop up in the future.
- Login or register to post comments
- Printer-friendly version
- 3121 reads
- PDF version
More in Tux Machines
- Highlights
- Front Page
- Latest Headlines
- Archive
- Recent comments
- All-Time Popular Stories
- Hot Topics
- New Members
digiKam 7.7.0 is releasedAfter three months of active maintenance and another bug triage, the digiKam team is proud to present version 7.7.0 of its open source digital photo manager. See below the list of most important features coming with this release. |
Dilution and Misuse of the "Linux" Brand
|
Samsung, Red Hat to Work on Linux Drivers for Future TechThe metaverse is expected to uproot system design as we know it, and Samsung is one of many hardware vendors re-imagining data center infrastructure in preparation for a parallel 3D world. Samsung is working on new memory technologies that provide faster bandwidth inside hardware for data to travel between CPUs, storage and other computing resources. The company also announced it was partnering with Red Hat to ensure these technologies have Linux compatibility. |
today's howtos
|
Recent comments
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago