Language Selection

English French German Italian Portuguese Spanish

Linux Foundation, Linux Kernel, FUD, and LWN Articles (Paywall Lapsed Today)

Filed under
Linux
  • EdgeX Foundry Hits Major Milestone with 5 Million+ Container Downloads and a New Release that Simplifies Deployment for AI, Data Analytics and Digital Transformation

    EdgeX Foundry, a project under the LF Edge umbrella organization within the Linux Foundation that aims to establish an open, interoperable framework for IoT edge computing independent of connectivity protocol, hardware, operating system, applications or cloud, today announced a major milestone of hitting 5 million container downloads and the availability of its “Geneva” release. This release offers more robust security, optimized analytics, and secure connectivity for multiple devices.

    “EdgeX Foundry is committed to developing an open IoT platform for edge-related applications and shows no signs of slowing down the momentum,” said Arpit Joshipura, general manager, Networking, Edge and IoT, the Linux Foundation. “As one of the Stage 3 projects under LF Edge, EdgeX Foundry is a clear example of how member collaboration and diversity are the keys to creating an interoperable open source framework across IoT, Enterprise, Cloud and Telco Edge.”

  • Check Point fixes a 20-year-old Linux security issue

    For around two decades now, hackers have exploited the design of the memory management system used by Linux programs in order to take control of a target's computer.

    Now though researchers at Check Point have introduced a new security mechanism for Linux users called 'safe-linking' which means attackers will need more than one vulnerability in order to take over the program.

  • Check Point released an open-source fix for common Linux memory corruption security hole
  • Intel Volleys New Sandy Bridge CPU Microcode

    For reasons currently unknown, Intel released new CPU microcode on Wednesday for their Sandy Bridge processors.

    Intel released the 20200520 CPU Microcode Update and it only consists of Sandy Bridge family updates. This is a bit strange with Sandy Bridge being nine years old and other Intel CPU families not seeing similar microcode updates this week.

  • Intel Sends Out Patches Bringing Up The "DG1" Graphics Card Under Linux

    For months now Intel's open-source driver developers have been working on the "Gen12" graphics support needed most notably for Tiger Lake and more recently is also confirmed for Rocket Lake. But Gen12 is also needed for the highly anticipated Xe Graphics with the discrete graphics offerings to come in the months ahead by Intel. Building off the existing Gen12 graphics driver code, Intel today published the first DG1 patches for enabling their first discrete graphics card under Linux.

  • Completing and merging core scheduling

    Core scheduling is a proposed modification to the kernel's CPU scheduler that allows system administrators to control which processes can be running simultaneously on the same processor core. It was originally proposed as a security mechanism, but other use cases have shown up over time as well. At the 2020 Power Management and Scheduling in the Linux Kernel summit (OSPM), a group of some 50 developers gathered online to discuss the current state of the core-scheduling patches and what is needed to get them into the mainline kernel.

    [...]

    One open area, Pillai said, was in the area of load balancing, which doesn't currently work well with core scheduling. This could perhaps be improved by selecting a single run queue to hold the shared information needed for core scheduling. When a scheduling event happens, the highest-priority task would be chosen as usual. Then any sibling processors can be populated with matching tasks from across the system, should any exist.

    Core scheduling currently uses CPU control groups for grouping; there is a cpu.tag field that can be set to assign a "cookie" identifying the scheduling group a task belongs to. This was done for a quick and easy implementation, he said, and need not be how things will work in the end. There is a red-black tree in each run queue, ordered by cookie value, that is used to select tasks for sibling processors.

    The patch series is up to version 5, which includes some load-balancing improvements. Earlier versions did not understand load balancing at all, so if a task was migrated to a CPU running (incompatible) tagged tasks, it could end up being starved for CPU time. A sixth revision is coming soon, he said.

    One challenge that has to be dealt with is comparing the priority of tasks across siblings. Within a run queue, a task's vruntime value is used to determine whether it should run next. This value is a sort of virtual run time, indicating how much CPU time the task has received relative to others (though it is scaled by the process priority and adjusted in various other ways), but this value is specific to each run queue. A vruntime in one run queue cannot be directly compared to a vruntime in another queue.

  • O_MAYEXEC — explicitly opening files for execution

    Normally, when a kernel developer shows up with a proposed option that doesn't do anything, a skeptical response can be expected. But there are exceptions. Mickaël Salaün is proposing the addition of a new flag (O_MAYEXEC) for the openat2() system call that, by default, will change nothing. But it does open a path toward tighter security in some situations.

    Executing a file on a Unix-like system requires that said file have an applicable execute-permission bit set. The file must also not reside on a filesystem that has been mounted with the noexec option. These checks can prevent the execution of unwanted code on a tightly controlled system, but there is a significant hole in this protection: interpreters that will happily read and execute code found in a file. If a file contains Perl code, for example, it cannot be executed by typing its name if it fails either of the above two tests. If an attacker is able to pass that file as a parameter to a perl -e command, though, its contents will still be executed.

    The new O_MAYEXEC flag is a way for language interpreters (or other programs, such as dynamic linkers, that execute code) to indicate to the kernel that a file is being opened with the intent of executing its contents. This flag is totally ignored by open() which, because it never checked for invalid flags, is difficult to extend in general. The newer openat2() system call, instead, does fail when unknown flags are passed to it; it has been extended to recognize O_MAYEXEC. But, by default, nothing will change if that flag is present.

  • Blocking userfaultfd() kernel-fault handling

    The userfaultfd() system call is a bit of a strange beast; it allows user space to take responsibility for the handling of page faults, which is normally a quintessential kernel task. It is thus perhaps not surprising that it has turned out to have some utility for those who would attack the kernel's security as well. A recent patch set from Daniel Colascione is small, but it makes a significant change that can help block at least one sort of attack using userfaultfd().
    A call to userfaultfd() returns a file descriptor that can be used for control over memory management. By making a set of ioctl() calls, a user-space process can take responsibility for handling page faults in specific ranges of its address space. Thereafter, a page fault within that range will generate an event that can be read from the file descriptor; the process can read the event and take whatever action is necessary to resolve the fault. It should then write a response describing that resolution to the same file descriptor, after which the faulting code will resume execution.

    This facility is normally intended to be used within a multi-threaded process, where one thread takes on the fault-handling task. There are a number of use cases for userfaultfd(); one of the original cases was handling live migration of a process from one machine to another. The process can be moved and restarted on the new system while leaving most of its memory behind; the pages it needs immediately can then be demand-faulted across the net, driven by userfaultfd() events. The result is less downtime while the process is being moved.

    Since the kernel waits for a response from the user-space handler to resolve a fault, page faults can cause an indefinite delay in the execution of the affected process. That is always the case, of course; for example, a process generating a fault on memory backed by a file somewhere else on the network will come to an immediate halt for an unknown period of time. There is a difference with userfaultfd(), though: the time it takes to resolve the fault is under the process's direct control.

  • Private loop devices with loopfs

    A loop device is a kernel abstraction that allows a file to be presented as if it were a physical block device. The typical use for a loop device is to mount a filesystem image stored in a file. Loop devices are global and shared between users, which causes a number of problems for container workloads where the instances are expected to be isolated from each other. Christian Brauner has been working on this problem; he has posted a patch set solving it by adding a small virtual filesystem called loopfs.

    Loop devices typically appear under /dev with names like /dev/loopN. The special /dev/loop-control file can be used to create and destroy loop devices or to find the first available loop device. Associating a file with a specific device, or setting other parameters like offsets or block sizes, is done with ioctl() calls on the device itself. The loop(4) man page has the details on how it all works.

EdgeX Foundry Hits 5 Million+ Container Downloads

  • EdgeX Foundry Hits 5 Million+ Container Downloads

    EdgeX Foundry, a project under the LF Edge umbrella organization within the Linux Foundation, has announced a major milestone of hitting 5 million container downloads and the availability of its “Geneva” release.

    [...]

    Keith Steele, EdgeX Foundry Chair of the Technical Steering Committee, added: “With at least 50% of data being stored, processed and analyzed at the edge we need an open, cloud-native edge ecosystem enabled by EdgeX to minimize reinvention and facilitate building and deploying distributed, interoperable applications from the edge to the cloud. In 3 short years, EdgeX has achieved incredible global momentum and is now being designed into IOT systems and product roadmaps.”

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Devices: Librem/Purism, Rockchip, and Axiomtek

  • Reflashing the Librem 5

    Reflashing the Librem 5 is the best way to remove your personal data and put the phone back into factory defaults. Warning, this procedure will completely erase everything on the device! Make a backup beforehand! The Librem 5 gets reflashed from a separate 64-bit x86 computer running PureOS (or booted from the live PureOS disk).

  • Getting Purism News – Purism

    We have a lot of irons in the fire at Purism whether it’s hardware development like the Librem 5, Librem 5 USA, or Librem 14, new products like the Librem Mini v2, or the wide range of software projects we maintain at https://source.puri.sm/. As a result, each week there is news on at least one of these fronts. We often get questions about the status of various projects, in particular from customers who are part of a crowdfunding campaign who want to know the answer to the all-important question: when will I get my device? In this post we will cover all the different ways you can stay up to date on Purism news.

  • Rockchip RV1126 AI Camera SoC features 2.0 TOPS NPU, promises 250ms fast boot

    Rockchip RV1126 EVB V13 can help with evaluation and early development, but I could not find limited information includes a boot log showing it running Linux 4.9.111.

  • PoE-enabled Apollo Lake system triggers machine vision

    Axiomtek’s compact “MVS100-323-FL” machine vision computer combines Apollo Lake with 3x GbE ports — 2x with PoE — plus lighting controls, trigger I/O, isolated DIO, and mini-PCIe. Axiomtek has previously launched vision I/O computers based on Intel’s 7th Gen Kaby Lake with products like the MVS900-511-FL, IPS962-512-PoE, and IPS960-511-PoE. The new MVS100-323-FL is a far more compact system with a slower, but more energy efficient Apollo Lake processor. [...] The MVS100-323-FL is powered by Intel’s quad-core x5-E3940, clocked at 1.6GHz. No OS support was listed, but Linux and Windows are almost certainly supported. Axiomtek’s AMS.AXView software is also available.

Open Hardware: Raspberry Pi and Arduino

  • Introducing the Raspberry Pi Pico Microcontroller - IoT Tech Trends

    The Raspberry Pi Foundation comes through again with another innovative device. Already well-known for its series of single-board computers, the company has announced the Raspberry Pi Pico, a microcontroller that costs a shockingly low $4. Adding to the interest, the company is using its own RP2040 chip for it, meaning it’s making its own silicon, just like Apple with its M1.

  •  
  • Kernel 5.10.9 compiled for Pi4

    EasyOS for the Raspberry Pi4, version 2.6, has the 5.10.4 Linux kernel. I have now compiled the 5.10.9 kernel, that will be used in the next release of Easy.

  •  
  • Fixed compile of Samba without krb5 in OE

    EasyOS on the Pi4 does not have samba, as compile failed in OE. Yes, I could compile it in a running EasyOS on the Pi4, but would rather fix it in OE. I have a 'samba_%.bbappend' file, the main objective being to remove the 'pam' and 'krb5' dependencies. I worked on this recipe this morning. The problem is that instead of 'krb5', the internal 'heimdahl' is used, and this compiles two binaries, that are then executed during compile. The problem is that the binaries are compiled for the target system, in this case aarch64, whereas the build system is x86_64, so the binaries cannot run. OE does have a mechanism to handle this. It is possible to compile 'samba-native', that is, samba compiled to run on the build-system, and then use the two binaries from that when compile 'samba'. Fine, except that exactly how to do this is very poorly documented. The official documentation is very vague. A couple of years ago, I bought a book, "Embedded Linux Systems with the Yocto Project", but found that it also said hardly anything about this. I consider this to be an important topic, yet it seems that many OE experts don't know much about it either.

  •     
  • Arduino Blog » Turn your staircase into a flaircase with this LED system

    If you live in a house with stairs and have to traipse up and down at night, it’s best to have some sort of light that guides you. Although a cell phone can work just fine, or you could likely activate bright overhead lighting, creator MagicManu devised an automatic and progressive solution to illuminate his path instead. MagicManu’s system knows when someone is there using PIR sensors arranged at both ends, and only activates if it’s dark enough thanks to a photoresistor. The entire setup is controlled by an Arduino Nano, while two potentiometers adjust light sensitivity and duration of ignition.

Red Hat’s Disruption of CentOS Unleashes Storm of Dissent

Five weeks after angering much of the CentOS Linux developer community by unveiling controversial changes to the no-cost CentOS operating system, Red Hat has unveiled alternatives for affected users that give them several options for using existing Red Hat products. But for many users of CentOS Linux, the Red Hat options won’t solve the huge problems that were created for them when Red Hat announced Dec. 8 that CentOS would no longer include a stable version with a long, steady future. Instead, CentOS will now only be offered as a free CentOS Stream operating system which will be a rolling release with frequent updates, essentially turning it into a beta OS that is no longer suitable for reliable production workloads. For users who have deployed CentOS throughout the internet, data centers, corporate and business uses and more, this is a potentially major blow. Read more Also: Fedora program update: 2021-03

The Demise of Chromium as Free Software

  • This is why Leading Linux Distros going to remove Chromium from their Official Repositories

    Jochen Eisinger from Google team mentioned in a discussion thread that they will be banning sync support system of Chromium. This lead to lot of frustration in the Linux Dev community & rage against googles sudden decision. This Decision can kill small browser projects & lead the web to single browser monopoly i.e. Google Chrome! As a result of the googles decision multiple distros are strictly considering removal of Chromium from their official repositories. Leading distros like Arch Linux, Fedora, Debian, Slackware & OpenSUSE have stated that if the sync support goes down from google they will definitely remove chromium from their official repositories.

  • Chromium 88 removes Flash support [Ed: But DRM added]

    I uploaded a set of chromium packages to my repository today. Chromium 88.0.4324.96 sources were released two days ago. The release notes on the Google Chrome Releases Blog mention 36 security fixes with at least one being tagged as “critical” but the article does not mention that Flash support has been entirely removed from Chromium now. Adobe’s Flash was already actively being blocked for a long time and you had to consciously enable Flash content on web pages, but after Adobe discontinued Flash on 1st of January 2021 it was only a matter of time before support in web browsers would be removed as well. Let’s also briefly revisit the topic of my previous post – Google will remove access to Chrome Sync for all community builds of the open source variant of their Chrome browser: Chromium… thereby crippling it as far as I am concerned.

  • Chrome 89 Preparing To Ship With AV1 Encoder For WebRTC Usage [Ed: Massive patent trap]

    Now that Chrome 88 released, attention is turning to Chrome 89 of which an interesting technical change is the enabling of AV1 encode support within the web browser. Going back to 2018 there's been AV1 decode support within the browser when wanting to enjoy content encoded in this royalty-free, modern codec. But now for Chrome 89 is coming AV1 encode support. AV1 encode support is being added for the WebRTC use-case for real-time conferencing. Web applications like WebEx, Meet, and Duo (among others) already support using AV1 for better compression efficiency, improved low-bandwidth handling, and greater screen sharing efficiency. While hardware-based AV1 encoding isn't yet common, Chrome Linux/macOS/Windows desktop builds are adding the ability to use CPU-based AV1 encoding.