A new BSDCan video has posted:

Improvements to FreeBSD KASAN By Zhuo Ying Jiang Li

https://youtu.be/pwwSdQi0NUI

KASAN is a kernel sanitizer commonly combined with fuzzing techniques to detect memory corruption bugs, some of which could lead to security compromise. Currently, FreeBSD's KASAN can only detect a subset of temporal safety vulnerabilities due to the lack of a delayed freeing mechanism of freed items. Furthermore, the effectiveness of detecting spatial safety vulnerabilities is also limited because FreeBSD's KASAN does not add redzone padding around UMA allocations.

In this talk, I will present my current work on improving the effectiveness of KASAN by extending it with a quarantining mechanism and injecting redzones around UMA allocations. The development was done on CheriBSD, a fork of FreeBSD with CHERI support, to explore the synergy between CHERI and KASAN. I plan to upstream the relevant improvements to FreeBSD.

#runbsd #freebsd #bsdcan

A new BSDCan video has been posted:

Sleep on FreeBSD: A bedtime story about S0ix By Aymeric Wibo

https://youtu.be/RCjPc4X2Edc

One of the main things still missing in FreeBSD for it to be usable on modern laptops is the ability to go to sleep. In the past, this was done using ACPI S3, but newer laptops have removed this in favour of S0ix, leaving FreeBSD without support for suspend on those machines.

This talk aims to get the casual user familiar enough with the terms and concepts behind power management, such that they can understand what's going on, what's already possible, what can be done, and be able to narrow down power management issues they might encounter.
Full description

This talk will cover:

The background and history of power management on FreeBSD, from APM, to ACPI S3, and finally to s2idle/S0ix, and how to know whether or not a given laptop supports S3 or S0ix or both.

What the full suspend process looks like with modern standby, going into details like ACPI D-states & power resources, SPMC DSMs (acpi_spmc), the AMD SMU (system management unit, amdsmu), etc. and some of the challenges encountered.

Specifics about sleep on AMD, such as USB4 power management in the HCM (host connection manager) and GPIO controller interrupt servicing.

Cover debugging with residency counters, with the SMU on AMD, _LPI objects, and LPIT on Intel.

Niceties and potential future work, such as idleness determination, a powertop equivalent, a built in amd_s2idle.py equivalent (for debugging sleep issues), etc.

#runbsd #freebsd #bsdcan

A new BSDCan Video has been posted:

porch(1): it's not what you expect(1) By Kyle Evans

https://youtu.be/Drbk4rEH1sk

In a world ruled by expect(1) and TCL, we discuss an alternative that was developed based on scripting with lua instead. porch(1) was developed with a language already available and used in FreeBSD base in mind, with the aim of TTY testing via pts(4).

The overall aim of this project is to provide a simple subset of expect(1) functionality specifically aimed at developer and sysadmin automation in another popular language with many niceties for scripted interaction.

In this talk, we'll specifically discuss:

The motivation for writing porch

The underlying design/philosophy (with diagrams to describe the model)

Bundled-in functionality beyond script execution

Practical samples used in FreeBSD today

--

The author has been a FreeBSD src committer since 2017, working on many parts of the tree and gradually introducing lua into the base system. His most recent exploits include improving base system boot environment management with bectl(8) and excursions into the tty layer.

#runbsd #freebsd #bsdcan

A new BSDCan video has posted:

Improvements to FreeBSD KASAN By Zhuo Ying Jiang Li

https://youtu.be/pwwSdQi0NUI

KASAN is a kernel sanitizer commonly combined with fuzzing techniques to detect memory corruption bugs, some of which could lead to security compromise. Currently, FreeBSD's KASAN can only detect a subset of temporal safety vulnerabilities due to the lack of a delayed freeing mechanism of freed items. Furthermore, the effectiveness of detecting spatial safety vulnerabilities is also limited because FreeBSD's KASAN does not add redzone padding around UMA allocations.

In this talk, I will present my current work on improving the effectiveness of KASAN by extending it with a quarantining mechanism and injecting redzones around UMA allocations. The development was done on CheriBSD, a fork of FreeBSD with CHERI support, to explore the synergy between CHERI and KASAN. I plan to upstream the relevant improvements to FreeBSD.

#runbsd #freebsd #bsdcan

A new BSDCan video has been posted:

Sleep on FreeBSD: A bedtime story about S0ix By Aymeric Wibo

https://youtu.be/RCjPc4X2Edc

One of the main things still missing in FreeBSD for it to be usable on modern laptops is the ability to go to sleep. In the past, this was done using ACPI S3, but newer laptops have removed this in favour of S0ix, leaving FreeBSD without support for suspend on those machines.

This talk aims to get the casual user familiar enough with the terms and concepts behind power management, such that they can understand what's going on, what's already possible, what can be done, and be able to narrow down power management issues they might encounter.
Full description

This talk will cover:

The background and history of power management on FreeBSD, from APM, to ACPI S3, and finally to s2idle/S0ix, and how to know whether or not a given laptop supports S3 or S0ix or both.

What the full suspend process looks like with modern standby, going into details like ACPI D-states & power resources, SPMC DSMs (acpi_spmc), the AMD SMU (system management unit, amdsmu), etc. and some of the challenges encountered.

Specifics about sleep on AMD, such as USB4 power management in the HCM (host connection manager) and GPIO controller interrupt servicing.

Cover debugging with residency counters, with the SMU on AMD, _LPI objects, and LPIT on Intel.

Niceties and potential future work, such as idleness determination, a powertop equivalent, a built in amd_s2idle.py equivalent (for debugging sleep issues), etc.

#runbsd #freebsd #bsdcan

A new BSDCan Video has been posted:

porch(1): it's not what you expect(1) By Kyle Evans

https://youtu.be/Drbk4rEH1sk

In a world ruled by expect(1) and TCL, we discuss an alternative that was developed based on scripting with lua instead. porch(1) was developed with a language already available and used in FreeBSD base in mind, with the aim of TTY testing via pts(4).

The overall aim of this project is to provide a simple subset of expect(1) functionality specifically aimed at developer and sysadmin automation in another popular language with many niceties for scripted interaction.

In this talk, we'll specifically discuss:

The motivation for writing porch

The underlying design/philosophy (with diagrams to describe the model)

Bundled-in functionality beyond script execution

Practical samples used in FreeBSD today

--

The author has been a FreeBSD src committer since 2017, working on many parts of the tree and gradually introducing lua into the base system. His most recent exploits include improving base system boot environment management with bectl(8) and excursions into the tty layer.

#runbsd #freebsd #bsdcan

New @bsdcan Video Posted:

ABI stability in FreeBSD By ShengYi Hung

https://youtu.be/vzU6vKd1OFM

The FreeBSD project doesn't guarantee the ABI stability in major version. However, for the minor version, we also not fully guarantee. This cause maintaining a out-of-tree module (at least for Kernel module like VirtualBox) a big problem because module compiles from 14.0 may not able to use at 14.1. This also cause some problem when distributing modules with freshpkg in our base because our pkg system only support build for all major version.

A wiki page distribute the workflow of CTF diff and script:

https://wiki.freebsd.org/ShengYiHong/ABIStability?highlight=%28ABI%29

The outline of my slides will be as following:

What is ABI and why we needs to stablize ABI?

How to maintain ABI stability (a tool to check and ABI tag in binary)?

ABI information (CTF and dwarf) in elf and why we use CTF?

New tools CTFDiff: Why implement new CTFDiff and don't use the illumos one? (we port libctf and other command line tools like ctfdump to FreeBSD from illumos)

CTFDiff script: scripts download tarball from web (kernel tarball) so that we can compare abi between local compile one and web.

Short demo (maybe) for ctfdiff ?

Current status of CTFDiff (needs reviewers, licenses issue (CDDL))

Future works: regulize a stable function/obj ABI/API in kernel.

#runbsd #bsdcan

New @bsdcan Video Posted:

ABI stability in FreeBSD By ShengYi Hung

https://youtu.be/vzU6vKd1OFM

The FreeBSD project doesn't guarantee the ABI stability in major version. However, for the minor version, we also not fully guarantee. This cause maintaining a out-of-tree module (at least for Kernel module like VirtualBox) a big problem because module compiles from 14.0 may not able to use at 14.1. This also cause some problem when distributing modules with freshpkg in our base because our pkg system only support build for all major version.

A wiki page distribute the workflow of CTF diff and script:

https://wiki.freebsd.org/ShengYiHong/ABIStability?highlight=%28ABI%29

The outline of my slides will be as following:

What is ABI and why we needs to stablize ABI?

How to maintain ABI stability (a tool to check and ABI tag in binary)?

ABI information (CTF and dwarf) in elf and why we use CTF?

New tools CTFDiff: Why implement new CTFDiff and don't use the illumos one? (we port libctf and other command line tools like ctfdump to FreeBSD from illumos)

CTFDiff script: scripts download tarball from web (kernel tarball) so that we can compare abi between local compile one and web.

Short demo (maybe) for ctfdiff ?

Current status of CTFDiff (needs reviewers, licenses issue (CDDL))

Future works: regulize a stable function/obj ABI/API in kernel.

#runbsd #bsdcan

New @bsdcan video posted:

Controlled credentials transitions without privileges: mac_do(4), mdo(1) and setcred(2) by Olivier Certner

https://youtu.be/Wl2hewfxcKM

In this talk, we will present a project that aims at allowing controlled process credentials transitions without using setuid executables but instead leveraging FreeBSD's MAC framework.

Traditional credentials-changing programs, such as sudo(8), have a non-negligible attack surface as they often include a lot of infrequently used features and mechanisms that can be dangerous from a security standpoint (e.g., loadable modules). As these programs have to run as 'root', compromising them can have catastrophic consequences.

The mac_do(4) kernel module has been introduced to allow unprivileged processes to change credentials, provided the requested changes are explicitly allowed by rules set by an administrator. It has recently undergone major changes. First, thanks to a redesign of rules, it is now possible to specify full sets of user and group IDs that must be present or absent in the final credentials for a transition to be accepted. Second, each jail can be configured with a different set of rules, allowing different transitions to be allowed as needed, or to inherit from the parent jail.

We will describe how mac_do(4)'s credentials rules work, what the role of the mdo(1) companion program is, and what you can do with them in practice.

We will also touch on some aspects of the implementation, notably why we needed to introduce the new setcred(2) system call, which allows to change all process credentials in a single call, and possibly those that are related to the use of some FreeBSD's kernel sub-systems (notably, sysctl, jails and OSD).

While the current implementation is of production quality and immediately useful, there are lots of possible ways to extend it to cover more scenarios and to progress towards our ideal of having all credentials-changing programs work without the setuid bit. We will present them in the hope to get feedbacks.

#runbsd #bsdcan

New @bsdcan video posted:

Controlled credentials transitions without privileges: mac_do(4), mdo(1) and setcred(2) by Olivier Certner

https://youtu.be/Wl2hewfxcKM

In this talk, we will present a project that aims at allowing controlled process credentials transitions without using setuid executables but instead leveraging FreeBSD's MAC framework.

Traditional credentials-changing programs, such as sudo(8), have a non-negligible attack surface as they often include a lot of infrequently used features and mechanisms that can be dangerous from a security standpoint (e.g., loadable modules). As these programs have to run as 'root', compromising them can have catastrophic consequences.

The mac_do(4) kernel module has been introduced to allow unprivileged processes to change credentials, provided the requested changes are explicitly allowed by rules set by an administrator. It has recently undergone major changes. First, thanks to a redesign of rules, it is now possible to specify full sets of user and group IDs that must be present or absent in the final credentials for a transition to be accepted. Second, each jail can be configured with a different set of rules, allowing different transitions to be allowed as needed, or to inherit from the parent jail.

We will describe how mac_do(4)'s credentials rules work, what the role of the mdo(1) companion program is, and what you can do with them in practice.

We will also touch on some aspects of the implementation, notably why we needed to introduce the new setcred(2) system call, which allows to change all process credentials in a single call, and possibly those that are related to the use of some FreeBSD's kernel sub-systems (notably, sysctl, jails and OSD).

While the current implementation is of production quality and immediately useful, there are lots of possible ways to extend it to cover more scenarios and to progress towards our ideal of having all credentials-changing programs work without the setuid bit. We will present them in the hope to get feedbacks.

#runbsd #bsdcan

BSDCan 2025 Keynote: Hardware Support for Memory Hungry Applications by Margo Seltzer

https://youtu.be/OCWaGRcPO8E?feature=shared

For nearly 60 years, we lived in a CPU-centric universe. Today, we are on the brink of a transition -- GPUs are the new golden child and those children demand unprecedented amounts of DRAM to satisfy modern data-hungry applications. I'm going to talk about these hardware trends and what they mean for those of us who build systems.
Speaker bio: Margo Seltzer is Canada 150 Research Chair in Computer Systems and the Cheriton Family chair in Computer Science at the University of British Columbia. Her research interests are in systems, construed quite broadly: systems for capturing and accessing data provenance, file systems, databases, transaction processing systems, storage and analysis of graph-structured data, and systems for constructing optimal and interpretable machine learning models.
She is the author of several widely-used software packages including database and transaction libraries and the 4.4BSD log-structured file system. Dr. Seltzer was a co-founder and CTO of Sleepycat Software, the makers of Berkeley DB, the recipient of the 2021 ACM Software Sytems award and the 2020 ACM SIGMOD Systems Award. She is a past President of the USENIX Assocation and served as the USENIX representative to the Computing Research Association Board of Directors. In 2019 recipient of the USENIX Lifetime Achievement Award.
For more information, please visit:
https://www.bsdcan.org/2025/

#bsdcan

BSDCan 2025 Keynote: Hardware Support for Memory Hungry Applications by Margo Seltzer

https://youtu.be/OCWaGRcPO8E?feature=shared

For nearly 60 years, we lived in a CPU-centric universe. Today, we are on the brink of a transition -- GPUs are the new golden child and those children demand unprecedented amounts of DRAM to satisfy modern data-hungry applications. I'm going to talk about these hardware trends and what they mean for those of us who build systems.
Speaker bio: Margo Seltzer is Canada 150 Research Chair in Computer Systems and the Cheriton Family chair in Computer Science at the University of British Columbia. Her research interests are in systems, construed quite broadly: systems for capturing and accessing data provenance, file systems, databases, transaction processing systems, storage and analysis of graph-structured data, and systems for constructing optimal and interpretable machine learning models.
She is the author of several widely-used software packages including database and transaction libraries and the 4.4BSD log-structured file system. Dr. Seltzer was a co-founder and CTO of Sleepycat Software, the makers of Berkeley DB, the recipient of the 2021 ACM Software Sytems award and the 2020 ACM SIGMOD Systems Award. She is a past President of the USENIX Assocation and served as the USENIX representative to the Computing Research Association Board of Directors. In 2019 recipient of the USENIX Lifetime Achievement Award.
For more information, please visit:
https://www.bsdcan.org/2025/

#bsdcan

Here’s a little writeup about fun times at BSDCan 2025

https://blog.zia.io/2025/07/02/a-first-look-at-bsdcan-2025/

Yes, I’m using Stefano’sBSSG :)

#NetBSD#OpenBSD#FreeBSD#BSDCan

Here’s a little writeup about fun times at BSDCan 2025

https://blog.zia.io/2025/07/02/a-first-look-at-bsdcan-2025/

Yes, I’m using Stefano’sBSSG :)

#NetBSD#OpenBSD#FreeBSD#BSDCan

YOU!

The @bsdtv BSD A/V Team in conjunction with @bsdcan and @EuroBSDCon could use YOUR HELP with:

1. Locating official project slide templates
2. Validating them for readability on a projector and for the visually limited (I hear there are fonts that are dyslexia-friendy)
3. Integrating best practices into semi-official event slides for those presenters who simply want "insert content here"
No, I did not say required.

Thank you!

#FreeBSD#NetBSD#OpenBSD#BSDCan#EuroBSDcon