LWN.net's Journal
[Most Recent Entries]
[Calendar View]
Friday, April 26th, 2019
| Time |
Event |
| 1:01p |
Security updates for Friday
Security updates have been issued by Debian (gpac and mercurial), Fedora (kernel-headers and kernel-tools), openSUSE (GraphicsMagick, kauth, lxc, lxcfs, python, qemu, and xmltooling), SUSE (freeradius-server, ImageMagick, libvirt, samba, and wireshark), and Ubuntu (bind9). | | 3:26p |
[$] Bounce buffers for untrusted devices The recently discovered vulnerability in
Thunderbolt has restarted discussions about protecting the kernel against untrusted, hotpluggable hardware. That vulnerability, known as Thunderclap, allows a hostile external device to exploit Input-Output
Memory Management Unit (IOMMU) mapping limitations and access system memory it was not intended to. Thunderclap can be exploited by USB-C-connected devices; while we have seen USB attacks in the past, this vulnerability is different in that PCI devices, often considered as trusted, can be a source of attacks too. One way of stopping those attacks would be to make sure that the IOMMU is used correctly and restricts the device to accessing the memory that was allocated for it. Lu Baolu has posted
an implementation of that approach in the form of bounce buffers for untrusted devices. | | 8:33p |
An eBPF overview, part 3: Walking up the software stack (Collabora blog) Adrian Ratiu continues his series on eBPF with part 3, which looks at various ways to write and build eBPF programs. It starts by looking at using "restricted C" with the LLVM eBPF compiler, moves into looking at the BPF Compiler Collection (BCC), then bpftrace, and finally the IOVisor cloud-based eBPF tools. " Not everyone has kernel sources at hand, especially in production, and it's also a bad idea in general to tie eBPF-based tools to a specific kernel source revision. Designing and implementing the interactions between eBPF program's backends, frontends, loaders and data structures can be very complex, error-prone and time consuming, especially in C which is considered a dangerous low-level [language]. In addition to these risks developers are also in a constant danger of re-inventing the wheel for common problems, with endless design variations and implementations. To alleviate all these pains is why the BCC project exists: it provides an easy-to-use framework for writing, loading and running eBPF programs, by writing simple python or lua scripts in addition to the 'restricted C' as exemplified above." |
|