Kernel: Control Flow Integrity (CFI) and WireGuard in Linux 5.6

-
experimenting with Clang CFI on upstream Linux
While much of the work on kernel Control Flow Integrity (CFI) is focused on arm64 (since kernel CFI is available on Android), a significant portion is in the core kernel itself (and especially the build system). Recently I got a sane build and boot on x86 with everything enabled, and I’ve been picking through some of the remaining pieces. I figured now would be a good time to document everything I do to get a build working in case other people want to play with it and find stuff that needs fixing.
First, everything is based on Sami Tolvanen’s upstream port of Clang’s forward-edge CFI, which includes his Link Time Optimization (LTO) work, which CFI requires. This tree also includes his backward-edge CFI work on arm64 with Clang’s Shadow Call Stack (SCS).
-
WireGuard secure network tunnel
RFC Note: This is a RFC for folks who want to play with this early, because Herbert's cryptodev-2.6 tree hasn't yet made it into net-next. I'll repost this as a v1 (possibly with feedback incorporated) once the various trees are in the right place. This compiles on top of the Frankenzinc patchset from Ard, though it hasn't yet received suitable testing there for me to call it v1 just yet. Preliminary testing with the usual netns.sh test suite on x86 indicates it's at least mostly functional, but I'll be giving things further scrutiny in the days to come. WireGuard is a layer 3 secure networking tunnel made specifically for the kernel, that aims to be much simpler and easier to audit than IPsec. Extensive documentation and description of the protocol and considerations, along with formal proofs of the cryptography, are available at: * https://www.wireguard.com/ * https://www.wireguard.com/papers/wireguard.pdf This commit implements WireGuard as a simple network device driver, accessible in the usual RTNL way used by virtual network drivers. It makes use of the udp_tunnel APIs, GRO, GSO, NAPI, and the usual set of networking subsystem APIs. It has a somewhat novel multicore queueing system designed for maximum throughput and minimal latency of encryption operations, but it is implemented modestly using workqueues and NAPI. Configuration is done via generic Netlink, and following a review from the Netlink maintainer a year ago, several high profile userspace have already implemented the API. This commit also comes with several different tests, both in-kernel tests and out-of-kernel tests based on network namespaces, taking profit of the fact that sockets used by WireGuard intentionally stay in the namespace the WireGuard interface was originally created, exactly like the semantics of userspace tun devices. See wireguard.com/netns/ for pictures and examples. The source code is fairly short, but rather than combining everything into a single file, WireGuard is developed as cleanly separable files, making auditing and comprehension easier. Things are laid out as follows: * noise.[ch], cookie.[ch], messages.h: These implement the bulk of the cryptographic aspects of the protocol, and are mostly data-only in nature, taking in buffers of bytes and spitting out buffers of bytes. They also handle reference counting for their various shared pieces of data, like keys and key lists. * ratelimiter.[ch]: Used as an integral part of cookie.[ch] for ratelimiting certain types of cryptographic operations in accordance with particular WireGuard semantics. * allowedips.[ch], peerlookup.[ch]: The main lookup structures of WireGuard, the former being trie-like with particular semantics, an integral part of the design of the protocol, and the latter just being nice helper functions around the various hashtables we use. * device.[ch]: Implementation of functions for the netdevice and for rtnl, responsible for maintaining the life of a given interface and wiring it up to the rest of WireGuard. * peer.[ch]: Each interface has a list of peers, with helper functions available here for creation, destruction, and reference counting. * socket.[ch]: Implementation of functions related to udp_socket and the general set of kernel socket APIs, for sending and receiving ciphertext UDP packets, and taking care of WireGuard-specific sticky socket routing semantics for the automatic roaming. * netlink.[ch]: Userspace API entry point for configuring WireGuard peers and devices. The API has been implemented by several userspace tools and network management utility, and the WireGuard project distributes the basic wg(8) tool. * queueing.[ch]: Shared function on the rx and tx path for handling the various queues used in the multicore algorithms. * send.c: Handles encrypting outgoing packets in parallel on multiple cores, before sending them in order on a single core, via workqueues and ring buffers. Also handles sending handshake and cookie messages as part of the protocol, in parallel. * receive.c: Handles decrypting incoming packets in parallel on multiple cores, before passing them off in order to be ingested via the rest of the networking subsystem with GRO via the typical NAPI poll function. Also handles receiving handshake and cookie messages as part of the protocol, in parallel. * timers.[ch]: Uses the timer wheel to implement protocol particular event timeouts, and gives a set of very simple event-driven entry point functions for callers. * main.c, version.h: Initialization and deinitialization of the module. * selftest/*.h: Runtime unit tests for some of the most security sensitive functions. * tools/testing/selftests/wireguard/netns.sh: Aforementioned testing script using network namespaces. This commit aims to be as self-contained as possible, implementing WireGuard as a standalone module not needing much special handling or coordination from the network subsystem. I expect for future optimizations to the network stack to positively improve WireGuard, and vice-versa, but for the time being, this exists as intentionally standalone. We introduce a menu option for CONFIG_WIREGUARD, as well as providing a verbose debug log and self-tests via CONFIG_WIREGUARD_DEBUG.
-
Latest WireGuard Patch Out For Review With It Looking Like It Will Land For Linux 5.6
The long-awaited WireGuard secure VPN tunnel functionality looks like it will land with the Linux 5.6 kernel cycle happening in early 2020. Linux 5.5 is kicking off next week but the necessary crypto subsystem changes have yet to take place as well as a final sign-off on the new WireGuard code.
The blocker for the past long while on getting WireGuard merged into the Linux kernel was over its Zync cryptography code and needing to get that mainlined, which was proving difficult. While WireGuard was ready to fold and adopt to Linux's existing crypto API, in the interim crypto subsystem improvements making use of some Zinc design improvements materialized. It's those crypto improvements now expected to land soon in the Crypto development tree that in turn open the door for the WireGuard networking code itself to merge.
-
- Login or register to post comments
Printer-friendly version
- 1115 reads
PDF version
More in Tux Machines
- Highlights
- Front Page
- Latest Headlines
- Archive
- Recent comments
- All-Time Popular Stories
- Hot Topics
- New Members
Meet The New Linux Desktop That Offers A Unique Twist On Ubuntu 19.10
Are you a fan of the Cinnamon Desktop used in Linux Mint, but prefer more recent software and the familiarity of the Ubuntu ecosystem? If so, there’s a brand new spin of Ubuntu 19.10 that may interest you. Say hello to Ubuntu Cinnamon (or, as Michael Tunnell from This Week in Linux cleverly dubbed it, “CinnaBuntu”).
Ubuntu Cinnamon is a brand new “remix” project that incorporates the Cinnamon Desktop Environment into Ubuntu. It’s not an official “flavor” of Ubuntu, but the developers are hoping that — like Ubuntu Budgie and Ubuntu MATE before it — it’s welcomed by both the community and Canonical to eventually join the ranks of the official Ubuntu family.
| Google Releases Chrome 79 for Linux, Windows, and Mac with 51 Security Fixes
Chrome 79 has been in development since earlier this fall and entered beta testing at the end of October, when Google gave us a glimpse of the new features and improvements to come. And now, users can now enjoy all of them if they update their Chrome web browser to version 79.0.3945.79, which is rolling out now to Linux, Windows, and Mac desktop platforms.
With Chrome 79, Google brings VR (Virtual Reality) support to the Web with a new API called WebXR Device API, which allows developers to create immersive experiences for smartphones, as well as head-mounted displays. This also paves the way for the development of many other similar emerging technologies, among which we can mention AR (Augmented Reality).
|
The latest Linux kernel is headed to Chromebooks in the very near future and that’s a big deal
For those of you who may not be familiar with the subject, Google’s Chrome OS that powers millions of Chromebooks is built on the Linux kernel. I’ll save you the long-winded explanation of what the Linux kernel is and how it works for two reasons. One, it would take all day. Two, I’m not a developer and I would likely confuse myself and you in the process. Apart from numerous Linux distributions and Chrome OS, the Linux kernel is at the heart of the Android operating system as well as various embedded devices and products such as smart TVs and webcams.
| Qt for MCUs 1.0 is now available
Qt for MCUs enables creation of fluid graphical user interfaces (GUI) with a low memory footprint on displays powered by microcontrollers (MCU). It is a complete graphics toolkit with everything needed to design, develop, and deploy GUIs on MCUs. It enables a unified technology approach for an entire product line to create a consistent and branded end user experience. Watch the Qt for MCUs video showcasing different use cases.
Qt for MCUs 1.0 has already been adopted by lead customers in Japan, Europe and the US, who have started developing their next generation product. This release has been tested on microcontrollers from NXP, Renesas and STMicroelectronics. The software release contains Platform Adaptations for NXP i.MX RT1050 and STM32F769i as the default Deployment Platforms. Platform Adaptations for several other NXP and STM32 microcontrollers as well as the Renesas RH850 microcontroller are available as separate Deployment Platform Packages. On request, Qt Professional Services can provide new Platform Adaptions for additional microcontrollers.
|
Recent comments
5 hours 4 min ago
6 hours 1 min ago
6 hours 8 min ago
6 hours 11 min ago
6 hours 13 min ago
6 hours 34 min ago
6 hours 49 min ago
6 hours 55 min ago
6 hours 57 min ago
13 hours 52 min ago