Language Selection

English French German Italian Portuguese Spanish

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

Filed under
  • 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 test suite on x86 indicates it's at least mostly
      functional, but I'll be giving things further scrutiny in the days to
    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:
    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 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
      * 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/ 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
    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.

More in Tux Machines

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. Read more

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). Read more Direct:Stable Channel Update for Desktop

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. Read more

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. Read more