Why Locking Down the Kernel Won’t Stall Linux Improvements

By

-

August 15, 2018

The Linux Kernel Hardening Project is making significant strides in reducing vulnerabilities and increasing the effort required to exploit vulnerabilities that remain. Much of what has been implemented is obviously valuable, but sometimes the benefit is more subtle. In some cases, changes with clear merit face opposition because of performance issues. In other instances, the amount of code change required can be prohibitive. Sometimes the cost of additional security development overwhelms the value expected from it.

The Linux Kernel Hardening Project is not about adding new access controls or scouring the system for backdoors. It’s about making the kernel harder to abuse and less likely for any abuse to result in actual harm. The former is important because the kernel is the ultimate protector of system resources. The latter is important because with 5,000 developers working on 25 million lines of code, there are going to be mistakes in both how code is written and in judgment about how vulnerable a mechanism might be. Also, the raw amount of ingenuity being applied to the process of getting the kernel to do things it oughtn’t continues to grow in lockstep with the financial possibilities of doing so.

Top Linux Developers’ Recommended Programming Books

By

HPE Blog

-

August 15, 2018

Without question, Linux was created by brilliant programmers who employed good computer science knowledge. Let the Linux programmers whose names you know share the books that got them started and the technology references they recommend for today’s developers. How many of them have you read?

Linux is, arguably, the operating system of the 21st century. While Linus Torvalds made a lot of good business and community decisions in building the open source community, the primary reason networking professionals and developers adopted Linux is the quality of its code and its usefulness. While Torvalds is a programming genius, he has been assisted by many other brilliant developers.

I asked Torvalds and other top Linux developers which books helped them on their road to programming excellence. This is what they told me.

By shining C

Linux was developed in the 1990s, as were other fundamental open source applications. As a result, the tools and languages the developers used reflected the times, which meant a lot of C programming language.

Diversity Empowerment Summit Highlights Importance of Allies

By

The Linux Foundation

-

August 14, 2018

Diversity and inclusion are hot topics as projects compete to attract more talent to power development efforts now as well as build their ranks to carry the projects into the future. The Diversity Empowerment Summit co-located with Open Source Summit coming up in Vancouver August 29-31, will offer key insights to help your project succeed in these endeavors.

Although adoption of diversity and inclusion policies is generally seen as simply the right thing to do, finding good paths to building and implementing such policies within existing community cultures continues to be challenging. The Diversity Empowerment Summit, however, provides hard insights, new ideas, and proven examples to help open source professionals navigate this journey.

Nithya Ruff, Senior Director, Open Source Practice at Comcast, and member of the Board of Directors for The Linux Foundation, says “the mission of open source communities to attract and retain diverse contributors with unique talent and perspectives has gathered momentum, but we cannot tackle these issues without the support of allies and advocates.” Ruff will be moderating a panel discussion at the conference examining the role of allies in diversity and inclusion and exploring solid strategies for success.

A Quick Reminder on HTTPS Everywhere

By

O'Reilly

-

August 14, 2018

HTTPS Everywhere! So the plugin says, and now browsers are warning users that sites not implementing https:// are security risks. Using HTTPS everywhere is good advice. And this really means “everywhere”: the home page, everything. Not just the login page, or the page where you accept donations. Everything.

Implementing HTTPS everywhere has some downsides, as Eric Meyer points out. It breaks caching, which makes the web much slower for people limited to satellite connections (and that’s much of the third world); it’s a problem for people who, for various reasons, have to use older browsers… The real problem isn’t HTTPS’s downsides; it’s that I see and hear more and more complaints from people who run simple non-commercial sites asking why this affects them. Do you need cryptographic security if your site is a simple read-only, text-only site with nothing controversial? Unfortunately, you do. Here’s why. Since the ISPs’ theft of the web (it’s not limited to the loss of Network Neutrality, and not just an issue in the U.S.), the ISPs themselves can legally execute man-in-the-middle attacks…

Julia 1.0 Release Opens the Doors for a Connected World

By

insideHPC

-

August 14, 2018

Today Julia Computing announced the Julia 1.0 programming language release, “the most important Julia milestone since Julia was introduced in February 2012.” As the first complete, reliable, stable and forward-compatible Julia release, version 1.0 is the fastest, simplest and most productive open-source programming language for scientific, numeric and mathematical computing.

“During the last six and a half years, Julia has reached more than 2 million downloads and early adopters have already put Julia into production to power self-driving cars, robots, 3D printers and applications in precision medicine, augmented reality, genomics, energy trading, machine learning, financial risk management and space mission planning,” said Julia co-creators Jeff Bezanson, Stefan Karpinski, Viral Shah and Alan Edelman. “With today’s Julia 1.0 release, Julia now provides the language stability that commercial customers require together with the unique combination of lightning speed and high productivity that gives Julia its competitive advantage compared with Python, R, C++ and Java.”

4 Tips for Successful Remote 1-1s

By

Codeship Blog

-

August 14, 2018

Team dynamics are complicated enough even when everyone can grab lunch together. It’s often the “relationship” side of your team that will need some different techniques in a remote setting. If you’re a manager, building strong relationships with your direct reports is paramount for both their success and yours.

At Codeship, I manage a fully remote team, and our employees are scattered across Europe and North America. I found that much of the usual advice for 1-1s — hold them biweekly or monthly, make it a walk-and-talk, keep it tech-free — just doesn’t work for remote teams. Our set of constraints necessarily leads to some interesting solutions.

So don’t let the limitations of wifi bandwidth, your video camera, and your laptop screen get you down. Here are four tips for leading successful 1-1s with your remote teams.

Linux Kernel 4.18 Keeps Things Solid and Secure

By

Paul Brown

-

August 13, 2018

Linus Torvalds published the 4.18 kernel on Sunday, one week later than expected. This has a been a rocky release… and it’s all Android’s fault (more or less).

You see, Android systems lack tmpfs, the temporary file systems you usually see hanging off your /tmp directory. In regular Linux systems, a tmpfs is stored in memory and holds data that applications may need to retrieve at short notice or share with other programs. Instead, Android allocates a chunk of memory (called ashmem) that does the same thing. However, a change introduced to ashmem in 4.18-rc7 made the open source version of Android crash. Unfortunately, all this came to light the week before the final release of 4.18 was due. Nine patches later and the problem was still not totally resolved, so Linus decided to roll back the whole thing and wait another week for the things to calm down.

In other news, the kernel is becoming slimmer and more toned. 4.18 is actually 100 thousand lines lighter over its predecessor, 4.17. It is worth remembering that 4.17 had already shed over half a million lines of code and was the lightest in the 4.x series. As more obsolete code gets ditched, the kernel should take up less memory, run more efficiently and be less vulnerable to attacks that takes advantage of crufty old code.

Forward-thinking developers have also been working on a new __kernel_timespec structure. This will help avoid the 2038 problem hitting 32-bit systems. If you haven’t heard of this, it is similar to the year 2000 bug in that, at 03:14:07 UTC on 19 January 2038, unpatched machines will think we are back in the 1900s. Airplanes will fall from the sky, power stations will explode, and in a surprise snap referendum that nobody called for, the UK will rejoin the EU. Nonetheless, work continues apace.

Other things to look forward to in kernel 4.18:

The 32-bit ARM architecture has gained fixes for Spectre variants 1 and 2, thus protecting a wider variety of devices from being attacked.
The Steam Controller HID driver was merged into the kernel. This allows using Valve’s Steam Controller as a HID input device without needing to rely upon Steam or the user-space SC-Controller.
Finally, something that Linus himself is looking forward to is seeing WireGuard included in the kernel. “Can I just state my love for it and hope it gets merged soon?” gushed Linus, while talking to David Miller, main maintainer of the networking subsystem. WireGuard is a VPN, similar to OpenVPN or IPSec, but much more efficient, according to Linus. In his words, WireGuard is “a work of art,” but, unfortunately, it has not made it into the main trunk of this time around. It does remain available as a module, notwithstanding.

You can find out more about kernel 4.18 by reading the release notes themselves, visiting Phoronix or checking the Kernel Newbies report when it becomes available.

Learn more about Linux through the free “Introduction to Linux” course from The Linux Foundation and edX.

Compiler Fuzzing, Part 1

By

Vegard

-

August 13, 2018

Much has been written about fuzzing compilers already, but there is not a lot that I could find about fuzzing compilers using more modern fuzzing techniques where coverage information is fed back into the fuzzer to find more bugs.

If you know me at all, you know I’ll throw anything I can get my hands on at AFL. So I tried gcc. (And clang, and rustc — but more about Rust in a later post.)

Levels of fuzzing

First let me summarise a post by John Regehr called Levels of Fuzzing, which my approach builds heavily on. Regehr presents a very important idea (which stems from earlier research/papers by others), namely that fuzzing can operate at different “levels”. These levels correspond somewhat loosely to the different stages of compilation, i.e. lexing, parsing, type checking, code generation, and optimisation. In terms of fuzzing, the source code that you pass to the compiler has to “pass” one stage before it can enter the next; if you give the compiler a completely random binary file, it is unlikely to even get past the lexing stage, never mind to the point where the compiler is actually generating code. So it is in our interest (assuming we want to fuzz more than just the lexer) to generate test cases more intelligently than just using random binary data.

…In a “naïve” approach, we simply compile gcc with AFL instrumentation and run afl-fuzz on it as usual. If we give a reasonable corpus of existing C code, it is possible that the fuzzer will find something interesting by randomly mutating the test cases. But more likely than not, it is mostly going to end up with random garbage like what we see above, and never actually progress to more interesting stages of compilation. I did try this — and the results were as expected. It takes a long time before the fuzzer hits anything interesting at all.

GLB: GitHub’s Open Source Load Balancer

By

GitHub Engineering

-

August 13, 2018

At GitHub, we serve tens of thousands of requests every second out of our network edge, operating on GitHub’s metal cloud. We’ve previously introduced GLB, our scalable load balancing solution for bare metal datacenters, which powers the majority of GitHub’s public web and git traffic, as well as fronting some of our most critical internal systems such as highly available MySQL clusters. Today we’re excited to share more details about our load balancer’s design, as well as release the GLB Director as open source.

GLB Director is a Layer 4 load balancer which scales a single IP address across a large number of physical machines while attempting to minimise connection disruption during any change in servers. GLB Director does not replace services like haproxy and nginx, but rather is a layer in front of these services (or any TCP service) that allows them to scale across multiple physical machines without requiring each machine to have unique IP addresses.

IEEE Survey Ranks Programming Languages

By

EE Times

-

August 13, 2018

It’s been said that programming languages are akin to religion. Engineers and developers will go out of their way to defend the use of their favorite language. (Perhaps it’s more the pain of learning a new language that keeps us using the old). Surely you’ve seen many surveys on programming language preferences. As with all surveys, the results depend on who was asked.

IEEE recently surveyed its members, asking which languages they use. Given that IEEE represents electrical engineers, we naturally expect the results to differ from surveys taken in the software community. To EEs, software is usually a tool to make hardware work as opposed to being the product itself.

IEEE has published its 2018 list of top programming languages. Python came out on top overall. Other surveys showed different results.