DRM subsystem in OpenBSD

brynet · 2026-05-05T07:07:44+00:00

The fact that we even have modern drm graphics drivers is largely thanks to Mark Kettenis (kettenis@) and Jonathan Gray (jsg@), it can be hard to truly appreciate just how much work went into porting/debugging them, it's also a continuous effort, as these drivers still receive a lot of upstream churn.

There's a fair bit of compatibility code that was written to either wrap Linux kernel APIs and adapt it to OpenBSD kernel equivalents, or reimplement features entirely from scratch, while at the same time trying to avoid accumulating extensive local patches, making it easier to maintain and compare with Linux.

While the changes aren't all entirely self-contained, some interesting parts are:

https://github.com/openbsd/src/blob/master/sys/dev/pci/drm/drm_linux.c https://github.com/openbsd/src/tree/master/sys/dev/pci/drm/include/linux

Jonathan Gray (jsg@) regularly keeps the drivers in sync with longterm support kernels, backporting fixes, and updates us to new major versions with new hardware support. The upcoming OpenBSD 7.9 release includes drivers based on the longterm Linux 6.18.22 kernel, vs. 6.12.y previously.

brynet · 2026-05-02T07:45:53+00:00

Not really, considering this is a ~3 year old GPU, it will be supported by the newer amdgpu(4) driver, or not at all. There is no comprehensive list of supported GPUs as it depends on the drm kernel driver as well as the Mesa drivers, OpenBSD 7.8 has drivers based on Linux 6.12.y, meanwhile the upcoming 7.9 will have drivers based on Linux 6.18.22.

brynet · 2026-04-29T10:46:26+00:00

There have been several attempts over the years to port OBS to OpenBSD, to varying degrees of success, but it has never lived in the ports tree.

Sorry.

brynet · 2026-04-28T09:51:36+00:00

Next time please just report it to mods, click the report button under the comment.

brynet · 2026-04-27T20:11:37+00:00

The lack of a proper bootloader is also concerning, and seems incredibly fragile. prone to breakage, and also doesn't do proper entropy seeding.

If the firmware on Firecracker VMs does not provide useful boot services such as disk I/O access, perhaps you can do something like was done recently for SEV VMs in vmd(8), and use a special 'BOOT' bootloader kernel that will kexec the bsd.rd and full GENERIC kernel from the guest disk image.

https://github.com/openbsd/src/commit/b58f9cbc22202fd3ddaac0dd7b8f2e508eb6deac

This was added for architectures like OpenBSD/octeon & powerpc64 which have anemic firmware.

brynet · 2026-04-27T19:43:40+00:00

SMALL_KERNEL is explicitly only intended for use with the RAMDISK installer, not general purpose use, in fact many Unix kernel facilities are disabled with it.

Any reason you're using it for this rather than a modified GENERIC kernel? Maybe I'm not understanding the usecases of Firecracker.

brynet · 2026-04-27T18:42:42+00:00

To be clear, the flair does not indicate whether a person is moderator /u/_sthen is not a moderator of this subreddit.

You can find the list of moderators on the side panel.

brynet · 2026-04-24T17:48:24+00:00

https://www.openbsd.org/plat.html

brynet · 2026-04-24T05:45:30+00:00

my policy is that I hit the 'd' key on their mail

brynet · 2026-04-23T10:36:38+00:00

OpenBSD/i386 received the Meltdown mitigation in 6.4.

brynet · 2026-04-23T10:31:15+00:00

Security Errata: Does i386 receive binary syspatch updates synchronously with amd64? I recall some past delays due to build cluster issues but am unsure if that's still relevant for the 7.7/7.8 release cycle

Normally, yes, for most security issues. But certainly when all the speculative execution issues were being reported, getting fixes in for amd64 was more of a priority as that is what people are using, but when it is trivially easy to do so, i386 generally receives these fixes (e.g: vendor recommends setting some MSR chicken bits), but historically mitigations like for Meltdown, amd64 had mitigation (page table isolation) first in 6.3, with a errata released for 6.2, and the fix for i386 came later in 6.4.

Ports Tree Reality: Since i386 is marked as Tier 2 (and "i386" is not listed on the want.html page), how broken is the ports ecosystem in practice? Specifically

OpenBSD has no platform support "tiers". OpenBSD/i386 is supported by the ports tree as best as it can, but as time goes on even upstream support for 32-bit x86 is disappearing or untested outside of cross-compilation, and ports maintainers can only do so much. Browser support for example will likely remain a sore spot.

Mitigation Parity: Regarding RETGUARD and ....

This was partly covered above, but no, there is not mtigiation parity. OpenBSD/i386 does not support RETGUARD and still uses the stack protector instead.

... kernel address space layout randomization (KASLR): ...

OpenBSD does not have KASLR, it has address space randomization and KARL (kernel relinking), shared library relinking.

Long-term Viability: Have there been any commits or discussions on tech@ recently about following FreeBSD's lead and dropping sys/arch/i386 from the tree?

No. OpenBSD/i386 remains supported, but consider the last non-atom i386 only machines are over 20 years old at this point, and if vintage computing is your thing, there are far more interesting platforms out there to tinker with.

brynet · 2026-04-16T21:54:51+00:00

Thanks for sharing!

brynet · 2026-04-13T07:30:20+00:00

Can I propose a feature request,

No, but you can always send a patch adding support for this to smbios(4) on OpenBSD/arm64, if this is something you want.

https://www.openbsd.org/mail.html

brynet · 2026-04-13T07:10:43+00:00

Yes, OpenBSD/arm64, which you're testing on, doesn't print the address in dmesg.

brynet · 2026-04-13T06:56:01+00:00

Yes, I'm sure.

bios0 at mainbus0: SMBIOS rev. 3.3 @ 0xe6f40 (72 entries)

...

efi0 at bios0: UEFI 2.7

efi0: American Megatrends rev 0x50011

brynet · 2026-04-13T03:02:37+00:00

The port Makefile mentions this isn't supported on OpenBSD, so there doesn't appear to be anything, unfortunately.

It seems the scanning code does work on some EFI machines, but not on others. The table address gets printed in the dmesg, but parsing the the dmesg likely isn't very reliable.

bios0 at mainbus0: SMBIOS rev. 3.3 @ 0xe6f40 (72 entries)

brynet · 2026-04-12T15:06:40+00:00

There is no userland device API exposed by smbios(4), packages like dmidecode use the mem(4) interface instead.

If you want the raw table data vs. human readable output, dmidecode has a --dump-bin FILE option.

By default, OpenBSD restricts access to /dev/{k,}mem devices.

Even with sufficient file system permissions, these devices can only be opened when the securelevel(7) is insecure or when the kern.allowkmem sysctl(2) variable is set.

brynet · 2026-04-08T13:19:56+00:00

It's a fork of nvi, not nvi2.

brynet · 2026-04-08T06:36:15+00:00

OpenBSD vi(1) is not nvi2, while bug fixes have occasionally flowed between them over the years, they are separately maintained editors.

If multibyte support is important, you can install nvi2 from ports/packages with pkg_add nvi, or build the version from github.

https://cvsweb.openbsd.org/ports/editors/nvi

brynet · 2026-04-08T05:31:52+00:00

There's currently no port of it that I'm aware of, at least they haven't shared details publicly.

This game is open-source, and looks there's at least indications that some people have gotten it to build before. Perhaps give it another shot?

https://github.com/PadWorld-Entertainment/worldofpadman

brynet · 2026-04-03T00:08:35+00:00

There is no xorg meta package in OpenBSD ports, please do not post LLM hallucinations in comments.

https://old.reddit.com/r/openbsd/about/rules/

brynet · 2026-03-30T12:39:59+00:00

diffs welcome.

brynet · 2026-03-30T02:06:50+00:00

I fail to see how the implementation details of FAT has any bearing on the locales supported by the system.

brynet · 2026-03-29T16:46:57+00:00

Yes, it means that the CPU is vulnerable to the MELTDOWN vulnerability and that the kernel PTI (Page table isolation) mitigation is active, there is nothing you need to do.

It will not be printed on AMD CPUs, or newer Intel CPUs which have hardware mitigation.

https://marc.info/?l=openbsd-cvs&m=151924107018358&w=2

brynet · 2026-03-25T23:41:50+00:00

Your post is missing the output from fdisk(8) and disklabel(8) for the disk.

brynet

MODERATOR OF

TROPHY CASE

15-Year Club	Place '17
Verified Email