Language Selection

English French German Italian Portuguese Spanish


Enter your Tux Machines username.
Enter the password that accompanies your username.

More in Tux Machines

Input for the BEREC's guidelines on Router Freedom in Europe

Router Freedom is the right of customers of any Internet Service Provider (ISP) to choose and use a private modem and router instead of a router that the ISP forces them to use. The Body of European Regulators for Electronic Communications (BEREC) drafted guidelines for national agencies how to deal with Router Freedom in their countries. The Free Software Foundation Europe (FSFE) provided mixed feedback to an ongoing public consultation. The status of Router Freedom in Europe differs from country to country as the monitoring by the FSFE shows. The core of the debate is the question of where the Network Termination Point (NTP) is located. This defines where the network of the ISP ends and where the network of the user begins. If the modem and router are considered part of the ISP's infrastructure, a user cannot claim sovereignty of their communication and security. The patchwork rug of different rules may change soon as BEREC, the Body of European Regulators for Electronic Communications, has been commissioned to create guidelines for the National Regulatory Agencies (NRAs) and help them with implementing European regulation in a harmonised way. BEREC's current draft of the guidelines is up for public consultation until 21 November 2019. We analysed this draft and the EU Directives and Regulations it references, and provided our conclusion in a brief document. Read more

Audiocasts/Shows: BSD Now and The Linux Link Tech Show (TLLTS)

Security-Oriented Container Linux Gets Patched Against Latest Intel CPU Flaws

The security-oriented Container Linux by CoreOS GNU/Linux distribution has been updated this week with all the necessary patches to mitigate the latest Intel CPU microarchitecture vulnerabilities. CoreOS Container Linux 2247.7.0 is here as the latest stable version of the security-oriented, minimal operating system for running containerized workloads securely and at scale, which was acquired by Red Hat last year and will soon become Fedora CoreOS. This release includes fixes for the CVE-2019-11135 and CVE-2018-12207 security vulnerabilities affecting Intel CPUs. According to the release notes, CoreOS Container Linux 2247.7.0 fixes Intel CPU disclosure of memory to user process, but the complete mitigation requires manually disabling TSX or SMT on affected processors. Additionally, is also fixes Intel CPU denial of service by a malicious guest VM, and a CFS scheduler bug throttling highly-threaded I/O-bound applications. Read more

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