oa ☑ is a user on mamot.fr. You can follow them or interact with them if you have an account anywhere in the fediverse. If you don't, you can sign up here.
oa ☑ boosted
oa ☑ boosted

From twitter.com/LockPickingLwyr/st:

"The company that sent me the pictured fingerprint lock has provided the security quote of the year: “...the lock is invincible to the people who do not have a screwdriver.”"

oa ☑ boosted

More details about the #LazyFP Intel CPU issue. Affected OSes:
- Linux (mostly pre 4.4.y, y < 138)
- FreeBSD
- Windows
- KVM when run on affected Linux kernel versions
- All Xen versions and generally all hypervisors that employ lazy FPU switching

Affected CPUs:
- Verified on the Intel Core microarchitecture from Sandy Bridge to Skylake
- State of other processors unclear

There are also attack details, at least for one of three variants they discovered.

blog.cyberus-technology.de/pos

oa ☑ boosted

Oh look, Theo de Raadt seems to confirm my feeling regarding Intel Hyperthreading that I tooted about yesterday:

marc.info/?l=openbsd-tech&m=15

See also this discussion/rant (with @mulander @cynicalsecurity @csirac2) about Hyperthreading from January:

mastodon.social/@Kensan/992990

oa ☑ boosted

@stsp @mulander @cynicalsecurity @csirac2 Yeah, as mentioned in the other thread from January, the option to disable HT has been removed from many BIOSes.

It’s the reason why we had to add code to the Muen kernel which basically only brings up one thread per physical CPU core.

oa ☑ boosted

Pondering some more on the “Speculating Intel” #BSDCan talk: I have a feeling there are more issues to be found wrt. hyperthreading. A lot more state is shared between Hyperthreads than physical CPUs which, as we have learned, already share more state than intended...

oa ☑ boosted

fully pledged slaacd(8) coming to a mirror near you soon.
$ ps A | grep '[s]laacd'
22110 ?? Isp 0:00.01 /sbin/slaacd
2300 ?? Ip 0:00.01 slaacd: engine (slaacd)
58317 ?? Ip 0:00.03 slaacd: frontend (slaacd)

oa ☑ boosted

From the article on so-called responsible disclosure I'm writing: Coordinated disclosure, as currently performed, should be called unethical selective disclosure. Pay the right people your agreed extortion, and you're now on the favorites list.

#infosec

oa ☑ boosted
oa ☑ boosted

KoL sarcasm, open source Show more

oa ☑ boosted

Ah on voit enfin la théorie du ruissellement s'appliquer.

oa ☑ boosted

The question "Should I run *BSD?" is officially my new pet peeve.

If one feels the need to ask this question online in 2018, with advanced search engines, fast internet, virtualization technologies, and abundance of quality documentation, then no, they will not find what they're looking for in the BSD world. Unless they're looking for wasting the time of people who cannot distinguish helpfulness, from enabling laziness.

oa ☑ boosted
oa ☑ boosted
oa ☑ boosted

Stefan Sperling (@stsp) releases (with permission) the emails between the #OpenBSD project and the #KRACK #embargo.

[mathy] "I sent one mail on 14 August where I mentioned the new disclosure date of 16 Oct. In that same mail I also gave the OK to quietly commit a fix. "

marc.info/?l=openbsd-tech&m=15

oa ☑ boosted

responsible disclosure Show more

oa ☑ boosted

#OpenBSD intuition regarding a new side-channel caused by the speculative execution on systems with lazy FPU context switching wasn't unsubstantiated. Intel has just published an avdisory: intel.com/content/www/us/en/se

oa ☑ boosted

INTEL-SA-00145

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.

intel.com/content/www/us/en/se