home tags events about rss login

Things happen.

horia bonked 14 Jun 2026 10:52 -0700
original: stsp@bsd.network

I have published "mergesiteset" which despite being a relatively simple script has been saving me a lot of time merging configuration files while preparing #OpenBSD upgrades in production environments: https://marc.info/?l=openbsd-ports&m=178127596851228&w=2

Don't have a site set yet? Back up all the important configuration files you have changed in a tarball rooted at / and you have one.

And if you want to use sysupgrade with your site set without running a custom installation mirror to download sets from, see https://marc.info/?l=openbsd-tech&m=178128371857523&w=2

horia bonked 10 Jun 2026 09:28 -0700
original: bcallah@bsd.network

By the way, our first two publications on evaluating #OpenBSD mitigations are out. Both of these papers evaluate some amd64 anti-ROP mitigations: specifically changing the register selection order and semantically equivalent rewriting of instructions that may produce a potential polymorphic gadget instruction. This tracks a paper by mortimer@ back in 2019 at AsiaBSDCon.

The TL;DR is "OpenBSD can shrink binaries a little and gain a little performance without any security loss simply by reverting these mitigations." The mitigations did not hold up to independent evaluation.

The first paper did an exact 1:1 port of these mitigations to FreeBSD and found that register reallocation eliminates only about 0.3% of unique gadgets, for a 0.5% increase in binary size (mortimer@ claimed 6% reduction and "entirely free"). It is useless at best but more likely actively detrimental, as it produces a false sense of security. It also found the instruction rewriting reduces unique gadgets by about 3.5% with a binary size increase of about 1.8% (mortimer@ claimed 5% reduction with 0.15% binary size increase).

We then did a separate implementation of the instruction rewriting mitigation to GCC in the second paper. Our GCC implementation does the older <xchg; op; xchg> dance, as that's what mortimer@'s paper described. This is way worse; producing about a 3% performance hit for no security benefit at all.

The only part of both mitigations worth saving is for basic arithmetic, OpenBSD LLVM now takes advantage of the fact that basic arithmetic has two forms. For example, the newer instruction rewriting mitigation turns
addq %rax, %rbx (48 01 c3)
into
{load} addq %rax, %rbx (48 03 d8)

The new instruction rewriting mitigation is genuinely free in terms of binary size and execution speed, but doesn't move the security needle, so this one can stay as it is harmless. Other rewritings still have the flaw of increasing binary size and reducing performance for no security benefit.

Anyhow feel free to read the papers:
https://ieeexplore.ieee.org/abstract/document/11458911
https://www.researchgate.net/publication/405728967_A_Final_Return_for_OpenBSD_Anti-Return-Oriented_Programming_Mitigations

#BSD #FreeBSD #NetBSD #DragonFlyBSD #Linux #Unix #security #cybersecurity

horia bonked 10 Jun 2026 09:25 -0700
original: ciotbsd@billboard.bsd.cafe

[Kirill's journal]

[Kirill's journal]

OpenBSD under QEMU

Architecture specific notes for OpenBSD guests under QEMU, with working command lines where installation succeeds and failure points where it does not.

OpenBSD under QEMU

Architecture specific notes for OpenBSD guests under QEMU, with working command lines where installation succeeds and failure points where it does not.

(#openbsd #qemu)