BSDCan next week. Downtown University of Ottawa Desmarais.
See you there!
BSDCan next week. Downtown University of Ottawa Desmarais.
See you there!
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
Who was at BSDCan.org 2016?
Remember this?
Those of us in Desmarais remember the lights flickering!
Speaking of which, the conference is open to anyone walking in off the street. Might interest some Ottawa natives as well.
#BSD #FreeBSD #OpenBSD #NetBSD #DragonflyBSD #BSDCan #Ottawa

No one was injured when a massive sinkhole erupted in downtown Ottawa in June 2016, but the metaphorical aftershocks from the collapse — particularly when it comes to the city's LRT network — are still being felt to this day.
@heiseonlineenglish doesn't support DragonflyBSD!
I've been thinking about code and quality of, for quite some time. Compilers should not be a crutch for bad coders but a tool for good ones. I fear we are treating the symptom not the disease.
I have applauded the efforts of OpenBSD in the past, still all of us can and must do better.
Mike Karel memorial travel fund for BSDCan
https://blog.bsdcan.org/2026/05/20/announcing-the-mike-karels-memorial-travel-fund/
I recently wrote http://jdebp.info/FGA/original-vi.html and was thinking of doing something like this, to augment it; because Sven Guckes's list (https://guckes.net/vi/clones.html) is definitely dated and incomplete, nowadays.
It does not have #NeoVIM (for obvious reasons). Most lists of clones miss that there are several forks of Bostic #nvi, not least the two forks that are in #FreeBSD and #NetBSD base. Similarly, #DragonFlyBSD has forked nvi2.