@cynicalsecurity Unless somebody can explain in deep technical detail what “disabling HT in the BIOS” actually means (i.e. in what state are the threads and how can one still interact with them) the only sane thing to do seems to be to actually bring up *all* logical cores, enable MCE and explicitly park them with interrupts disabled. At least this way all cores are in a well defined state.
Disabling HT in the BIOS is rather hand-wavy until somebody explains what’s actually happening.
The Digest, now on Mastodon @bsd.network
This is way overdue: I'm now posting Digest notes to bsd.network/@dragonflydigest, a BSD-specific Mastodon server. It's bothered me for a while that I'm autoposting Digest headlines to Twitter, which is useful for Twitter users but still supporting a walled garden. Mastodon is a better implementation of a similar idea, and bsd.network nicely groups all sorts… ...
En mettant en place un outil de surveillance qui détecterait 99% des terroristes avec seulement 0.1% de marge d'erreur, 90% de ce que vous détectez ce sont des innocents.
C'est juste des statistiques et c'est foutrement instructif ⬇⬇⬇
stream de #PSES2018 ?
il faut bien utiliser le stream1: https://stream.passageenseine.fr/stream1/index.m3u8
sinon avec le stream2 on a juste le chat qui dort (remarquez que c'est reposant comme stream) https://stream.passageenseine.fr/stream2/index.m3u8
Paper about #LazyFP Intel CPU flaw is out:
“LazyFP: Leaking FPU Register State using Microarchitectural Side-Channels”
second try with DBUS_SESSION_BUS_ADDRESS="no:" as launching keepassxc still triggered dbus-daemon launch.
/me should go reading libdbus code source
how to asking libdbus for no D-Bus: run with DBUS_SESSION_BUS_ADDRESS="" in environment.
dbus-launch(1) man page says if DBUS_SESSION_BUS_ADDRESS is not set, it means "autolaunch:". So try to convience dbus that I really want to *not* run it.
(note: it is still in testing... maybe nowdays it is really a mandatory componment. let's see what doesn't work)
Oh look, Theo de Raadt seems to confirm my feeling regarding Intel Hyperthreading that I tooted about yesterday:
My life is swirling sewage-laden toilet bowl right now, but the world needs an article on OpenBSD "breaking embargos."
If other people find the sources, I'll take an hour and hammer them into a post.
Post original mailing list and article links in answer to this toot. Or don't. Whatevs.
I'll credit folks, of course.
My bias on this: there were fubars, like the 8 out of 10 OpenSSL bug. They'll argue against embargos over beer, but if they agree to it they'll keep it.
Colin Percival tweeted a short thread on the “Lazy FPU” vulnerability that was just disclosed (CVE-2018-3665).
Colin credits his learning about it to Theo de Raadt. Took him ~5 hours to come up with working exploit code.
More info on seclists.org and discussion on lobste.rs.
Earlier this year, Julian Stecklina (Amazon) and Thomas Prescher (Cyberus Technology) jointly discovered and responsibly disclosed another vulnerability that might be part of these, and we call it LazyFP. LazyFP (CVE-2018-3665) is an attack targeting operating systems that use lazy FPU switching. This article describes what this attack means, outlines how it can be mitigated and how it actually works.
Systems using #Intel ® Core-based microprocessors may potentially allow a local process to infer data utilizing #LazyFP state restore from another process through a speculative execution side channel.
@lattera Assuming the problem is with openssl-sys crate, usually a small patch is enough: https://github.com/openbsd/ports/blob/master/lang/rust/patches/patch-src_vendor_openssl-sys_build_rs
and with some black magy to convince cargo that "really nothing have changed, just build please" : https://github.com/openbsd/ports/blob/master/lang/rust/Makefile#L105