James Bottomley

Over the pandemic years, conference organizers have had a crash course in running online events, but now that the world is returning to normality, they're under pressure to keep the on-line portion of the conference for a hybrid remote/local event. Linux Plumbers Conference is a usually in-person event that specializes in direct in-person interactions as well as more traditional presentations. This year was the first time we tried to take our on-line infrastructure and repurpose it for hybrid in Dublin in September. One of the big factors in running a hybrid conference is that it's no longer just the committee and a server farm, you have a venue, a local audio team, an external A/V handler and the technology all to plumb into a seamless experience.

Plumbers online was based on BigBlue Button and Matrix, which is what we also used for hybrid. This presentation will be the story of how it was put together, how the in-person and local components were designed to interact, how it worked in the field and, although plumbers received universal acclaim for being one of the most successful hybrid conferences, the many things that went wrong during the conference and how we surmounted, or at least worked around, them.

Our technology infrastructure was set up identically to virtual: BigBlue Button (BBB) handling the audio/video but with the in BBB chat element replaced by matrix. The reason we have an external A/V company in the mix above is because we've always done streaming from the in-person conference, and this was planned to be our free tier of the conference; view the stream and be able to interact with the room chat over matrix. We've discussed before [1] the scaling problems of this setup (and so won't go over scaling in this presentation), but we'd fixed this in virtual and had no scaling issues in hybrid. Of great importance to getting the interaction to function was audience training. We used the same methodology for virtual (essentially only unmute your video if you want to interject) and hybrid, so we already had the on-line training ready to go.

Part of the on=site issues were caused by the steep learning curve the external A/V company had to go through to manage the room BBB console as well as getting the in room sound setup correct (onsite audio isn't used to having a remote feed, but they can be persuaded to treat it like an audio feed from the presenter). Our biggest problem actually turned out to be the size of our onsite committee tech team (2 people) which was insufficient to the number of live rooms (six) we were running.

[1] https://blog.hansenpartnership.com/linux-plumbers-conference-matrix-and-bbb-integration/

Security is a big problem especially in the cloud of container workloads. This presentation investigates improving security in the Linux kernel itself. The first target is securing sensitive application data, for instance, private keys.

Address space isolation has been used to protect the kernel and userspace programs from each other since the invention of the virtual memory.

Assuming that kernel bugs and therefore exploits are inevitable it might be worth isolating parts of the kernel to minimize damage that these exploits can cause. Moreover, restricted mappings in the kernel mode may improve mitigation of hardware speculation vulnerabilities.

There are several ongoing efforts to use restricted address spaces in Linux kernel for various use cases: * speculation vulnerabilities mitigation in KVM * support for memory areas visible only in a single owning context * hardening of the Linux containers

We are going to present the approach for the implementation of restricted mappings in the Linux kernel and how this implementation would be used with various use-cases.

We are also going to take a closer look at possibility to assign an address space to the Linux namespaces, so that tasks running in namespace A have different view of kernel memory mappings than the tasks running in namespace B. For instance, by keeping all the objects in a network namespace private, we can achieve levels of isolation equivalent to running a separated network stack.

It has become very popular in the last several years to think of free and open source as a community forward activity, indeed the modern approach is to try and form a community or foundation first and do code second. There is also much talk about maintainer burn out and community exploitation. However, the same people who talk about this still paraphrase the most famous quote from the Cathedral and the Bazaar "Scratching your own itch". They forget this is your own itch not everyone else's because Open Source begins as a selfish activity. The fact that communities do form around a load of selfish competing individuals is actually a testament to the unacknowledged power of open source to co-opt the selfish instinct and make it synergistic to some communal good.

This talk will explore the selfish origins of free and open source and dissect the co-option power it has to form broad and deep communities from what are apparently simple transactional engagements. We'll also explain how some of the more recent community failures have been engendered by the concentration on long term community to the detriment of enabling purely transactional mechanics by which initially selfish contributors come to the project.

The origins of selfish contributions, while called out in the founding canons of the open source and free software movements, were initially not very well recognized until the first open source projects (and here the author will use the example he's familiar with: the Linux Kernel) tried to engage successfully with companies trying to utilize the projects for their own ends. We became adept at explaining why forking is bad and how your cost structure will rise exponentially if you do it and how the cheapest method of achieving your business goals is in fact to work with the existing community on whatever feature the company was trying to add as part of its business plan. In fact, those of use who did company engagement because transactional sales people offering a corporation the achievements of business goals in exchange for some unexpected community engagement.

Nowadays, all companies have drunk the open source coolaid and all pledge their loyalty to further the interests of the community and this previous learning is all but forgotten in the third and fourth waves of open source. However, at their hearts, corporations are still the same business goal focussed transactional entities we had to deal with in the early days of open source and an understanding of how to co-opt their transactional nature would go a long way to assisting new open source developers in their quest to form communities.

This talk will begin with some history of the Linux kernel's corporate engagement, explore and explain some of the processes within open source development that lead to the conversion of transactionalism into long term community synergy (the truly astounding ability of open source to co-opt selfishness) and then give a few examples of how serving the community rather than enabling transactionalism can give rise to burn out and apparent exploitation. In conclusion we'll give some simple rules to enable this co-opting and suggest how some of the competing interests of the ethical source and social justice movements might likewise be co-opted.

For decades, all laptops have come with a TPM. Now with Microsoft forcing the transition to the next generation, Linux faces a challenge in that all the previous TPM 1.2 tools don't work with 2.0. Having to create new tools for TPM 2.0 also provides the opportunity to integrate the TPM more closely into our current crypto systems and thus give Linux the advantage of TPM resident and therefore secure private keys. This talks will provide the current state of play in using TPM 2.0 in place of crypto sticks and USB keys for secure key handling; including the algorithm agility of TPM 2.0 which finally provides a support for Elliptic Curve keys which have become the default recently.

This talk will provide an overview of current TSS (Trusted computing group Software Stack) for TPM 2.0 implementation on Linux, including a discussion of the two distinct Intel and IBM stacks with their relative strengths and weaknesses. We will then move on to integration of the TSS into existing crypto system implementations that allow using TPM resident keys to be used with common tools like openssl, gnutls, gpg, openssh and gnome-keyring. We will report on the current state of that integration including demonstrations of how it works and future plans. The ultimate goal is to enable the seamless use of TPM resident keys in all places where encrypted private keys are currently used, thus increasing greatly the security posture of a standard Linux desktop.

As an alternative to Contributor Licence Agreements, the DCO has proven to be very popular and, when coupled to a strong source control system like git, solves all of the issues of tracking and provenance that plague legacy CLA systems. This talk will examine the basis and mechanisms for the DCO, using the Linux kernel (the earliest DCO adopter) as an example and finally explore issues which have arisen in using the DCO for strong patent licences like Apache-2 and GPLv3

Now that the DCO is free from the kernel (http://developercertificate.org/) it can be used in any project. This talk begins with why you need a Contributor Agreement (CA) in the first place, explores some of the history and reasons for the various CAs and why Linux was forced to adopt the DCO nearly ten years ago. We will contrast the ten years of DCO experience against some other projects which use more specific CAs and explain the benefits and pitfalls. We will also give advice on best practices around using the DCO, what else is required to make the DCO work correctly and what problems still remain. The final hurdle in using the DCO for every licence seems to be the question of patents and strong patent licences (Apache-2 and GPLv3). We will examine the current status of the DCO as it pertains to patents and investigate new mechanisms to strengthen the agency aspect of corporate DCO contributions

A hands on demo of the types of containers that can be brought up in Linux using only the existing distribution tools

This talk will cover the theory of what containers are and how they work in Linux, including why they differ from hypervisors and what specific properties they have. In the demo section we will get into how you actually create and attach individual namespaces and cgroups (with simple demonstrations of the user namespace and the freezer cgroup using the unshare command and /sys/fs/cgroup/freezer). Finally we'll end up with a demonstration of how to bridge two network namespaces with a veth pair and how the ip netns command works