Category: conferences

Categories
conferences tools

Yocto Project Summit 2023.11

Last week, we participated in the Yocto Project Summit 2023.11, held online from November 28 to 30, with several interesting presentations regarding the Yocto Project itself and various use cases.

Marta Rybczynska led two sessions. The first one explained the procedure for submitting fixes for known security issues to the Yocto Projects, CVE (Common Vulnerability Enumeration) fixes. Developers can learn about them from multiple sources, like the runs of cve-check. In “stable” branches, the fix usually requires the backport of an upstream patch. Most of the submission process is the same as for any other bug, but there are small but significant differences to accommodate the cve-check tool. The developer should name the patch based on the CVE number and add a “CVE:” tag inside with that information. Marta has also shared submission hints like the usage of devtool if the original upstream patch does not apply and requires modifications. Refer to the slides below; the video link will be posted when available.

YPS-2023-11-Rybczynska-How-to-submit-a-CVE-fix-v2Download

The second session concentrated on the changes in the Yocto Project security area in 2023, with the important impact of the founding of the Sovereign Tech Fund.

Do you know that it has a security team now? The project also recommends that all layers have a SECURITY.md file with information for security researchers to contact the right people in case of a security issue.

Marta also explained the work in progress. CVE synchronization work aims to avoid duplication of work when fixing CVE issues. A team is looking into the usage of SRTool for triage. A proof-of-concept implementation of the upcoming SPDX3 standard is in the works, too.

Everyone can participate in all those security initiatives; you can check slides for pointers to wiki pages and discussions.

Slides from this session are available, too.

YPS2023-11-Rybczynska-YP-Security-Now-and-Future-v2Download
Categories
conferences

“From an Idea to a Patch in the Linux Mainline” at Open Source Summit/Embedded Linux Conference 2021

Last updated: September 20, 2021

Do you know that more than one in ten kernel developers in the latest 5.14 Linux kernel is a new developer? It means that they have had their first (ever!) patch accepted into this version. In addition, this is not a single event. In fact, it is happening for every single version in the recent history.

This will be the beginning of one of the two talks from Marta Rybczynska, Syslinbit founder, at the Open Source Summit/Embedded Linux Conference 2021 (schedule available). The conference starts in a week. You can download slides from both talks in advance. Let us start from the first one  – “From an Idea to a Patch in the Linux Mainline”. This is the third edition of the popular tutorial, updated with the recent content. If you are afraid of submitting your first Linux kernel patch, this is a session to follow. Marta takes a practical, step-by-step approach.

Set-up

The first step is to set up everything needed for the work. This starts from finding the right problem. Marta’s suggestion is to start with a bug fix or an improvement. If you are working on a new feature, it is likely you are going to fix bugs found during the development. Or adjust some internal kernel interface. Those also could be a good sources for a first patch. The tutorial suggests to avoid complex new features at the beginning. At least before you feel confident with the process…

When we do have the right problem, the next step will be setting up the development machine. This includes installing dependencies, downloading the kernel source tree (or more kernel source trees), getting familiar with the kernel source code indexing.

Then the tutorial moves on finding the bug source, illustrating it with an example of a real kernel bug. Marta shows how after the initial trace, we analyze the source. With the analysis come possible ideas of the bug source. The audience is then invited to repeat the procedure with a (fixed) bug of their choice.

Source analysis is not always enough. We might need kernel debugging tools. The tutorial covers the techniques for showing debug messages. It mentions printk() (currently rarely used directly), the general-purpose pr_* family with functions like pr_err(), and dev_* functions, like dev_err(), frequently seen in device drivers. Then it covers other techniques like tracing, performance monitoring, in-kernel debugging, and kernel testing framework.

Fix preparation

When the actual fix is done, the part many people fear is preparing and submitting the patch itself. The tutorial gives a gentle overview of the Linux Coding Style summary on one slide. Detailed instructions on checkpatch.pltake more than one, however. When the solution is ready, the time comes for the commit message with all important parts explained. This includes what Signed-off-by means and why it is important. At this point developers need a list of people to send the message to: maintainers and appropriate mailing list… Then the only thing is formatting the email, with the step-by-step commands for setting up git send-email. There are also some things to avoid when sending to the Linux Kernel Mailing List (abbreviated LKML), like sending attachments.

This is common to have a patch accepted in the 2nd (or later!) version. The talk concludes this part with tips on handling the review, like reposting after one week without a reply and checking if the distribution list is appropriate.

Some members of the audience might be working on something different than a bug. There is an additional section for them. This section includes working with low maturity patches called RFC (Request For Comments) and splitting a bigger change into a patch set.

With this set of tips and tools the audience will be equipped enough to send their first patch. The same procedure applies to many other Open Source projects, with slight modification to the tools and procedures to use.

Resources

The slides of the talk are waiting at the conference schedule page https://sched.co/lAS5 and everyone can review them before the event.

If you are interested this talk, you might also have a look at the one about working with unfamiliar code from foss-north.

Categories
conferences kernel

Working with unknown code: a talk at foss-north 2021

During the foss-north conference, Syslinbit founder Marta Rybczynska will be delivering a keynote. The talk entitled “Into the Jungle – How to write a Linux kernel driver for any subsystem” will lead the audience through writing a new module for an unknown code base. It will show tips and techniques useful not only when working with Linux, but any other big software project.

foss-north 2021: Marta Rybczynska, "Into the Jungle - How to write a Linux kernel driver for any subsystem"

During 20 years in Open Source projects, Marta saw many times developers approaching unknown code. Their reactions differ. Some read all the documentation online for days, others develop from scratch without planning. Finally, we can also see people who decide to re-write everything from scratch, or those who stop paralyzed in panic.

In the talk, Marta is going to show a step-by-step way to approach some unknown code. The audience will see how to learn the new subsystem, and how to test if the taken approach is the right one.

She will use an example of writing a new network driver for Linux, from scratch. It will simulate adding support for a new hardware device. During the process, she will guide the audience to look into the extensive kernel documentation, source code of similar drivers, show what the driver should be doing to work correctly… and more.

Even if the example is will be specific to Linux, the method is not. The audience will be able to use it, with minor changes, for any other unfamiliar code base.

The conference takes place on May 31st and June 1st, and will be a virtual event, with a community day on May 30. It is then accessible to everyone. The list of keynotes is already available on the website, and a blog posts gives some more details.