On Intel not talking to OpenBSD about recent FPU vuln

Chip vendors controlling the security of OSes should be more transparent in their selection process. They should maintain a list of OSVs that they maintain embargoed fixes. Then uses could determine if they want to trust the OS or not, or try to lobby to try and get the ISA vendor to support their OS. Is the OS on the list, ok then they may have some chance at fixing things. If not on the list I expect to be vulnerable until the embargo ends. There are MANY more OSes than Microsoft Windows, Apple macOS, a limited number of Linux distros, and sometimes FreeBSD.

In some forums, Bryan Cantrill is crafting a fiction. He is saying the FPU problem (and other problems) were received as a leak. He is not being truthful, inventing a storyline, and has not asked me for the facts. This was discovered by guessing Intel made a mistake. We are doing the best for OpenBSD. Our commit is best effort for our user community when Intel didn’t reply to mails asking for us to be included. But we were not included, there was no reply. End of story. That leaves us to figure things out ourselves. Bryan is just upset we guessed right. It is called science.




Theo of OpenBSD: Speculating about Intel at BSDCan




OpenBSD gets RETGUARD (anti-ROP) for Clang x64

RETGUARD for clang (amd64) added to -current

Contributed by rueda on 2018-06-06 from the d(e)ropping-the-gadgets dept.

Todd Mortimer has committed “RETGUARD” for clang (for amd64).



OpenBSD gets KARL (Kernel Address Randomized Link)




Over the last three weeks I’ve been working on a new randomization feature which will protect the kernel. The situation today is that many people install a kernel binary from OpenBSD, and then run that same kernel binary for 6 months or more. We have substantial randomization for the memory allocations made by the kernel, and for userland also of course. However that kernel is always in the same physical memory, at the same virtual address space (we call it KVA). Improving this situation takes a few steps.[…]



OpenBSD adds sysctl kern.allowkmem to reduce ‘decades of kernel snooping’

“Make a move towards ending 4 decades of kernel snooping. Add sysctl kern.allowkmem (default 0) which controls the ability to open /dev/mem or /dev/kmem at securelevel > 0.  Over 15 years we converted 99% of utilities in the tree to operate on sysctl-nodes (either by themselves or via code hiding in the guts of -lkvm). pstat -d and -v & procmap are affected and continued use of them will require kern.allowkmem=1 in /etc/sysctl.conf.  acpidump (and it’s buddy sendbug) are affected, but we’ll work out a solution soon. There will be some impact in ports.”




Filippo Valsorda: reversing OpenBSD FDE passwords

Filippo Valsorda of the CloudFlare Security Team wrote a blog on OpenBSD’s full-disk-encryption, after he lost his password.

So I lost my OpenBSD FDE password
The other day I set up a new OpenBSD instance with a nice RAID array, encrypted with Full Disk Encryption. And promptly proceeded to forget part of the passphrase. […] I did a weak attempt at finding some public bruteforce tool, and found nothing. I say weak because somewhere in the back of my brain, I already wanted to take a peek at the OpenBSD FDE implementation. Very little is documented, and while I do trust OpenBSD, I want to know how my data is encrypted. So this was the “perfect” occasion. […]

Related info: