Monthly Archives: June 2019

The Linux Kernel Getting Fixed Up For Booting On Some Intel Systems – No “8254”


There have been Linux reports of problems pertaining to “8254 Clock Gating” going back a while but more so recently. This problem is some newer Intel Skylake~Apollolake derived systems particularly with Intel SoCs where certain systems ship with the 8254 PIT to be gated via a special register and up until now that has caused Linux to fail to boot.

With the PIT gating by default, Linux would fail to boot with a kernel panic over “IO-APIC + timer doesn’t work!” But as this panic would happen before the frame-buffer is even setup, it would be hard for users to diagnose and workaround. There has been a workaround often of toggling the “8254 Clock Gating” option within the affected systems’ BIOS. But now there’s a kernel patch pending to make Linux happy in the no-8254 configuration.

The patch contains additional details for those interested. That fix is currently queuing in the x86/apic tree. Given an uptick in recent reports around “8254 clock gating” woes appearing in Google search results, good to see Linux getting fixed for these Intel systems.

Guarding Against DevOps’ Achilles Heel | IT Infrastructure Advice, Discussion, Community

In many respects, the rise and (potential) fall of DevOps resembles that of Achilles, the mythological Greek hero of Trojan War and Iliad fame. Think back to your high school years, what do you remember about Achilles? Undoubtedly, your memory recalls the lore of his success as a warrior and the transformational impact it had on the Trojan War. You probably also remember him for his one fatal weakness – his Achilles heel. I believe DevOps, as we know it today, has the same transformational strength in enterprises of all sizes, and its own singular point of weakness, which if left unaddressed, can expose businesses to significant security, compliance, and governance issues, if not their own peril.

Why DevOps today?

Before we go any further, let’s take a step back and briefly discuss why more and more businesses are choosing the DevOps path. Anyone working in IT knows that the cloud has fundamentally changed things. Over the last decade, businesses pursuing their cloud journey have reaped the benefits including streamlined application development and deployment; increased visibility, management and optimization of cloud resources; and cost reductions. However, cloud journeys also presented a host of new challenges along the way, many of which teams were not prepared to tackle. That’s because IT practices and remedies hadn’t kept up and were misaligned with the new reality, which saw the traditional security perimeter vanish and an increase in both the types of threats and points of vulnerability due to further BYOD adoption. Fast forward to today, and nothing’s changed. The speed of innovation and exponentially increasing complexity in the cloud have created challenges that can no longer be solved by humans alone or addressed by hardware. They now require a software solution. Enter DevOps and a host of cloud management solutions working to bring order to the chaos of the cloud.

Does DevOps have an Achilles heel?

There’s no doubt that the emergence of DevOps has been transformative for IT teams working in the many flavors of cloud, and the businesses they serve. Application development and deployments in the cloud have been streamlined to make teams more efficient than ever before, in turn enabling businesses to meet the real-time needs of the on-demand world better. A truly positive outcome all the way around, right?

If you answered “yes,” you’re likely still early in your organization’s digital transformation and focused on the critical first step of adopting a DevOps approach. If you answered “no,” then you are starting to realize a potential DevOps and cloud Achilles heel exists despite perfecting the integration and coordination of your development and operations teams – the critical security, compliance and governance gaps that still persist.

With this in mind, we’re faced with a central question: How do we improve DevOps so businesses adopting the approach can better navigate this new reality and ensure it doesn’t get hit by the metaphorical arrow in its heel? The answer is by adding a third leg to the stool by tightly integrating security, compliance, and governance practices to DevOps processes and planning, or more succinctly defined: DevSecOps.

Instituting DevSecOps guardrails with automation and analytics

The reality today is that developers deep into the cloud journey running automated CI/CD won’t put up with a bunch of artificial barriers. Rather, they will bypass brokered cloud access and continue to perpetuate shadow IT problems across the IT landscape. In response, IT leaders have debated whether to provide direct cloud access with no security or brokered access over the last few years, because better options didn’t exist. Unsurprisingly, no one has benefited from either path.

While IT practices and remedies haven’t kept up and have been largely misaligned with DevOps’ needs to date, the gap has closed in recent months. Most notably, advances in automation and analytics, largely delivered via a new generation of cloud management platforms, are giving IT teams the ability to establish and enforce security guardrails in the cloud, while allowing direct access to cloud resources for developers. They also address critical needs for the developer to have context for any issues that violate security or IT policy within their own toolchain (CI/CD tools, ticketing systems), while allowing security and IT teams to have visibility and push changes in an organizationally scalable way. These capabilities have made DevSecOps possible and couldn’t have come a moment too soon. The reality is that the pace of changes in the environment (both the cloud and threat landscape) means we can’t wait for alerts to get people’s attention. DevSecOps must be ongoing, contextual, and proactive in order to address the persistent threats businesses face today properly.

The net-net

As we look ahead, DevSecOps will be the dominant trend and transformational agent for IT teams and businesses working in the cloud. Those that don’t adopt DevSecOps will be presented with increased risk and left powerless in guarding against the threats of tomorrow. Your DevSecOps processes and cloud management solution should have tight integration with security and compliance solutions baked-in, as well as include a comprehensive rules-engine for anomaly detection, alerting, and automated remediation. Only then will you be able to realize the full power of the advanced automation and analytics available today and required to properly establish the guardrails required to close gaps in your DevSecOps practices.

Source link

A Look At What’s On The Table For Linux 5.3 Features


With the Linux 5.2 kernel due to be released in a few weeks and that marking the opening of the Linux 5.3 merge window, here is a look at some of the likely features coming to this next version of the Linux kernel.

Based upon our close monitoring of the different “-next” Git branches of the Linux kernel and mailing lists, here is a look at what you’re likely to see merged with Linux 5.3 in July. Linux 5.3 will then debut as stable in September.

– AMD Radeon RX 5700 “Navi” support is coming!

– Continued HMM work for AMDGPU as well as PowerPlay improvements.

– Adreno 540 support within MSM DRM.

– The Ingenic KMS driver is new in the DRM-Next tree.

– Nouveau Turing TU116 support.

– HDR support for the Intel graphics driver for use with Icelake and Geminilake hardware and newer.

– Better Intel performance with FSGSBASE.

– Icelake NNPI support as the Nervana Neural Network Processor for Inference.

– Official Zhaoxin x86 CPU processor support.

– Intel UMWAIT support.

– LZ4 in-place decompression for the EROFS read-only file-system.

– Better performance for case-insensitive EXT4 lookups.

– Possibly SMR/zoned device support for Btrfs and also for Btrfs there’s been reworked locking code..

– Other Icelake bits.

– Wacom MobileStudio Pro support and Wacom Intuos Pro Small.

– There might be the long work-in-progress LOCKDOWN patches.

– /proc/pid/arch_status support for showing AVX-512 usage currently.

– ACRN guest hypervisor support.

– FEC support for Intel’s ICE network driver.

– Preparations for EFI special purpose memory might be ready.

– 100GbE networking driver improvements.

Of course, there will be a lot more too, so stay tuned for our Linux 5.3 merge window coverage in July. What are you hoping to see or looking forward to the most with the Linux 5.3?

Systemd Now Allows Custom BPF Programs To Be Loaded On Cgroups


Systemd now allows loading of custom BPF programs for network traffic filtering that are applied to all sockets created by processes of a given systemd unit.

The motivation for this stems from a feature plan drawn up last year for having systemd install BPF (Berkeley Packet Filter) programs into cgroups. The benefit of this is associating a BPF program for IP filtering with a unit file so systemd can install them once a cgroup is setup.

With the systemd code as of this week, there are now the IPIngressFilterPath and IPEgressFilterPath options so that systemd units can specify a BPF pinned program as an argument. Multiple BPF programs can be specified and apply to all IP packets sent/received under the INET/INET6 sockets created by processes of the unit, in addition to any other filters of the system.

More details in this commit. This change will be in the upcoming systemd 243 release.

Raspbian Based On Debian 10 Offering Up Some Performance Improvements For Raspberry Pi

Alongside this week’s announcement of the Raspberry Pi 4, the Raspberry Pi Foundation also released a new Raspbian operating system release that is re-based from Debian 9 Stretch to the soon-to-be-released Debian 10 Buster. In benchmarking of these new and old Raspbian releases on a Raspberry Pi 3 Model B Plus, there are performance gains to find even if not jumping to the Raspberry Pi 4.

With the newly-released Raspbian 10, they have pulled in all of the latest Debian Buster package updates, which are quite meaningful compared to the rather stale state in the Debian 9 archive. Raspbian had already been offering a Linux 4.19 based kernel for the Raspberry Pi boards, so there isn’t much of a kernel difference (just a slight 4.19.23 to 4.19.42 bump) but there are prominent upgrades like moving from the GCC 6.3 to GCC 8.3 compilers and various user-space application upgrades.

Curious about the Raspbian performance difference, I ran some Raspbian 9.6 vs. Raspbian 10 benchmarks on a Raspberry Pi 3 Model B Plus Rev 1.3 board using the Phoronix Test Suite.

In addition to better performance, there are also other evolutionary improvements made to Raspbian 10 as outlined on the Raspberry Pi Blog.