Language Selection

English French German Italian Portuguese Spanish

Security: Meltdown and Spectre, Apple and More

Filed under
  • Meltdown and Spectre Linux Kernel Status

    By now, everyone knows that something “big” just got announced regarding computer security. Heck, when the Daily Mail does a report on it , you know something is bad…

    Anyway, I’m not going to go into the details about the problems being reported, other than to point you at the wonderfully written Project Zero paper on the issues involved here. They should just give out the 2018 Pwnie award right now, it’s that amazingly good.

  • Linux Kernels 4.14.13, 4.9.76, and 4.4.111 Bring More Security Fixes, Update Now

    As promised, Linux kernel maintainer Greg Kroah-Hartman released today new versions of the Linux 4.14, 4.9, and 4.4 kernel series to address some of the regressions from previous builds and fix more bugs.

    Linux kernels 4.14.13, 4.9.76 LTS, and 4.4.111 LTS are now available for download from, and they include more fixes against the Spectre security vulnerability, as well as some regressions from the Linux 4.14.12, 4.9.75 LTS, and 4.4.110 LTS kernels released last week, as some reported minor issues.

  • Red Hat Researchers: Spectre Chip Vulnerability Likely Worse For VMs Than Containers
  • Watching the meltdown.

    I have been watching Meltdown and Spectre unfold from the sidelines. Other than applying available updates, I'm just watching and absorbing the process of the disclosure. This one appears mid way along a long road.

    I teach mostly administrators. I teach some developers. I teach those in, or desiring to be in, infosec. I like teaching security topics. I think securing systems requires more people thinking about security from the beginning of design and as an everyday, no big deal part of life. A question I ask with these newsworthy issues is what normal practices can mitigate even part of the problems?  There are two big basics - least privilege and patch management - to always keep in mind. Issues like ShellShock and Venom were mostly mitigated from the beginning with SElinux enabled (least privilege) and WannaCry had little impact on those systems patched long ago when the SMB bug was first found and fixed.

    However, in some cases, both exploits and accidents come from doing something that no one else thought of trying. This is why I like open source. There is the option (not always used) for more people trying different things and finding better uses as well as potential flaws. Any type of cooperation and collaboration can be the source of some of these findings including pull requests, conference talks, or corporations working with academic research projects.

  • macOS High Sierra's App Store System Preferences Can Be Unlocked With Any Password

    A bug report submitted on Open Radar this week reveals a security vulnerability in the current version of macOS High Sierra that allows the App Store menu in System Preferences to be unlocked with any password.

  • Open Source Security Podcast: Episode 77 - npm and the supply chain

    Josh and Kurt talk about the recent npm happenings. What it means for the supply chain, and we end with some thoughts on how maybe none of this matters.

More in Tux Machines

Licensing With GPL: Greater Certainty

  • A Movement Builds as a Diverse Group of 14 Additional Leaders Seek Greater Predictability in Open Source Licensing
    Today’s announcement demonstrates the expanded breadth and depth of support for the GPL Cooperation Commitment. Companies adopting the commitment now span geographic regions, include eight Fortune 100 companies, and represent a wide range of industries from enterprise software and hardware to consumer electronics, chip manufacturing to cloud computing, and social networking to automotive. The companies making the commitment represent more than 39 percent of corporate contributions to the Linux kernel, including six of the top 10 corporate contributors.1
  • ARM: Arm joins industry leaders in commitment to fair enforcement of open source licenses
    Today, Red Hat announced that several leading technology companies, including Arm, are joining a diverse coalition of organizations that have come together to promote greater predictability in open source license enforcement. Alongside Amazon, Canonical, Linaro, Toyota, VMware and many others we have committed to ensure fair opportunity for our licensees to correct errors in compliance with their GPL and LGPL licensed software before taking action to terminate the licenses.
  • Debian "stretch" 9.5 Update Now Available, Red Hat Announces New Adopters of the GPL Cooperation Commitment, Linux Audio Conference 2018 Videos Now Available, Latte Dock v0.8 Released and More
    Red Hat announced that 14 additional companies have adopted the GPL Cooperation Commitment, which means that "more than 39 percent of corporate contributions to the Linux kernel, including six of the top 10 contributors" are now represented. According to the Red Hat press release, these commitments "reflect the belief that responsible compliance in open source licensing is important and that license enforcement in the open source ecosystem operates by different norms." Companies joining the growing movement include Amazon, Arm, Canonical, GitLab, Intel Corporation, Liferay, Linaro, MariaDB, NEC, Pivotal, Royal Philips, SAS, Toyota and VMware.

Opinion: GitHub vs GitLab

So, Microsoft bought GitHub, and many people are confused or worried. It's not a new phenomenon when any large company buys any smaller company, and people are right to be worried, although I argue that their timing is wrong. Like Microsoft, GitHub has made some useful contributions to free and open-source software, but let's not forget that GitHub's main product is proprietary software. And, it's not just some innocuous web service either; GitHub makes and sells a proprietary software package you can download and run on your own server called GitHub Enterprise (GHE). Let's remember how we got here. BitMover made a tool called BitKeeper, a proprietary version control system that allowed free-of-charge licenses to free software projects. In 2002, the Linux kernel switched to using BitKeeper for its version control, although some notable developers made the noble choice to refuse to use the proprietary program. Many others did not, and for a number of years, kernel development was hampered by BitKeeper's restrictive noncommercial licenses. In 2005, Andrew Tridgell, working at OSDL, developed a client that bypassed this restriction, and as a result, BitMover removed licenses to BitKeeper from all OSDL employees—including Linus Torvalds. Eventually, all non-commercial licenses were stopped, and new licenses included clauses preventing the development of alternative version control systems. As a result of this, two new projects were born: Mercurial and Git. Created in a few short weeks in 2005, Git quickly became the version control system for Linux development. Proprietary version control tools aren't common in free software development, but proprietary collaboration websites have been around for some time. One of the earliest collaboration websites still around today is Sourceforge. Sourceforge was created in the late 1990s by VA Software, and the code behind the project was released in 2000. Read more

Comparing Latencies and Power consumption with various CPU schedulers

The low-latency kernel offering with Ubuntu provides a kernel tuned for low-latency environments using low-latency kernel configuration options. The x86 kernels by default run with the Intel-Pstate CPU scheduler set to run with the powersave scaling governor biased towards power efficiency. While power efficiency is fine for most use-cases, it can introduce latencies due to the fact that the CPU can be running at a low frequency to save power and also switching from a deep C state when idle to a higher C state when servicing an event can also increase on latencies. Read more

csplit: A Better Way to Split File in Linux Based on its Content

Learn some practical examples of the GNU coreutils csplit command for splitting files in Linux. It’s more useful than the popular split command. Read more