Language Selection

English French German Italian Portuguese Spanish

Manjaro Linux 18.1.0 Juhraya Cinnamon - Spicy but sweet

Filed under

You know how the popular saying goes. When it rains ... people drive slowly just to annoy you. But as it happens, I received a bunch of emails from people asking me two things: 1) Why have I not recently done any more Cinnamon reviews (other than Mint)? 2) When am I going to review the latest version of Manjaro 18.1 Juhraya?

The answer to these question is: yes. At the same time! I decided to try Manjaro Cinnamon, not something I've done before, so it should be an interesting, refreshing and hopefully worthwhile exercise. The test box will be the same one I used for the Illyria Xfce test, so we can compare things in earnest - and accurately. This is an eight-book mixed Windows & Linux box, and it comes with UEFI, Intel graphics, 16 sweet partitions, and another instance of Manjaro that we won't touch in this review. Begin to start.

Read more

More in Tux Machines

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.

Graphics: AMD, Mesa and "IGC" Graphics Compiler

  • AMD Promotes Navi 14 Linux Support Out Of "Experimental" + Fixes For Raven Ridge

    With the initial Navi 14 support to be found in the Linux 5.4 kernel releasing this weekend the GPU ASIC (along with Navi 12) have been marked as experimental and thus not enabled by default unless passing a special module parameter to the kernel. But now at the last minute this support has been deemed non-experimental for Navi 14. After the original Navi 12/14 open-source driver support was published, it was then marked as experimental. Under that experimental state, the hardware initialization only happens if amdgpu.exp_hw_support=1 is set as a parameter for the AMDGPU kernel driver.

  • mesa 19.3.0-rc4
    Hi list,
    I'd like to announce mesa 19.3.0-rc4 is now available. We're starting to slow
    down a bit in terms of the number of patches being backported, but there's still
    a fair number of opened bugs in the release tracker:
    As such I'm predicting at least one more -rc will be required before the 19.3
    release, I'll update the calendar accordingly.
    Among the changes in this release aco dominates, with anv and freedreno no far
    behind. We've reverted an underspeced egl extension that was causing
    regressions, as well as stopped modifying Khronos headers. There's also so fixes
    to i965, core mesa, llvmpipe and st/mesa.
  • Mesa 19.3.0 Not Expected Until December - RC4 Released With ACO Fixes

    Mesa 19.3 had been expected for release next week per their original release calendar, but as we are used to seeing for these quarterly feature releases, at least one if not more weekly release candidates tend to be needed for ironing out bugs. As such, Mesa 19.3.0 is now solidly looking like at least an early December release while Mesa 19.3-RC4 shipped on Wednesday.

  • Intel Graphics Compiler Update Adds 16-Bit Atomics For Tiger Lake, Other New Features

    Wednesday marked the v1.0.2878 update to Intel's "IGC" Graphics Compiler that is used by their graphics hardware compute stack.