/tech/ - Technology★

>>993688 (OP)

OpenBSD is not vulnerable, time to install OpenBSD

>>993692

OpenBSD is also not usable

you can disable SMT in the kernel

Intel is now a random vulnerability generator.

>>993700

That stmnt proofs that you haven't even tried it. OpenBSD is usable as a desktop OS. It has world-class documentation (on par with GNU Emacs) and it does most things out-of-box but it isn't bloated. OpenBSD takes security very seriously, the OpenBSD team even cuts out crappy stuff, like Bluetooth support and the Linux compatibility layer (I am not saying Linux sucks).

I don't know if the AMD version will be as egregious. You have to remember that Intel's HT is a hacky version that was designed to get around IBM's patents.

>>993692

>OpenBSD is not vulnerable,

>Last year, another team of researchers found a similar side-channel vulnerability named TLBleed impacting Intel's Hyper-Threading (SMT) technology. Following the discovery of TLBleed, the OpenBSD project decided to disable support for Intel's HT technology in upcoming versions of the OpenBSD operating system, on the grounds of security.

BSD was vulnerable and still can be if users reactivate it, if gnu/linux users don't want to be vulnerable they just have to do the same by deactivating it.

>>993692

most exploits don't work on openbsd because almost nothing runs on openbsd period

>>993756

what can it run?

>>993786

OpenBSD 6.4 was released not long ago, and by default it's not vulnerable because they disabled the SMT when that version was still in development. Most OpenBSD users run either the latest stable release (in this case 6.4) or the development snapshots. So what he said is correct, and OpenBSD is not vulnerable unless you're running an old version or have re-enabled the vulnerability yourself. In some very rare cases, you might be stuck on an old release because of hardware issues, but otherwise there's no excuse to not run at least the most up-to-date stable release. If you choose not to, that's basically the equivalent of ignoring security patches that were offered to you.

>>993688 (OP)

>The PoC steals an OpenSSL (<= 1.1.0h) P-384 private key from a TLS server by successfully exploiting PortSmash, but the attack can be modified to target any type of data.

There was an OpenSSL update literally yesterday to address this.

>>993800

Haven't been able to try much yet, as I only installed an OS (NetBSD) two days ago, and finally got U-boot to work 100% unattended (without me typing shit over the serial port). Right now I'm struggling to get the framebuffer into a mode < 1280x1024, so I can run the wsvt X server in a mode that doesn't overwhelm the CPU. Because yeah, this being NetBSD there's no Mali driver (or Lima, the open-source replacement, which so far is only for Linux). But my board comes with Android pre-installed on the eMMC, and I could play youtube videos in full screen (1024x768 was what Android used) without any noticeable glitches. And of course, browsing the web with Chrome just worked. But that was only for testing the board. So in theory it can do a whole lot, but since I'm running non-accelerated X server it won't do so great. No problem for me, since I don't need much, else I'd have installed Linux instead (to get the GPU benefits). I only need to be able to run Firefox on occasions. I tried it in 1280x1024 and it lags badly. Want to try 800x600 and see (that would be sufficient for my purposes).

>>993793

Just wait for the Raptor Blackbird.

Core 2 Duo don't have Hyper-Threading.

>>993846

>The PoC steals

>>993760

>my bluetooth devices won't work

g-great OS there, bro!

>>993760

>OpenBSD is usable as a desktop OS.

If your standards for "usable" are still in the last century, sure.

>the OpenBSD team even cuts out crappy stuff, like Bluetooth support and the Linux compatibility layer

And you call that usable?

>>994065

>if you can't run anything, you are perfectly safe

Great security model right here

>>994083

>>994012

Taking out bad code is better than having it remain in the codebase. Besides, Bluetooth is worse than using USB cable.

Niggaz, arent we living in some cool ass time?

Like, few years ago buffer/stack/heap overflows were all the rage, now it is hardware exploits that are getting abused.

Rowhammer, Spectre, meltdown, now this?

Shiiiieeetttt

Just lemme check what JS libraries allow for accurate timing attacks and whatnot lmao

>having SMT enabled

enjoy dimished responsiveness

>>994149

Where's the proof?

>>994217

Windows scheduling

>>994272

>caring about security

>running Windows

Pick one.

>>994272

Didn't Microshit fix their retarded scheduler that got slower with the more resources you gave it?

>>993756

I do love it how you can actually get schematics for Olimex hardware.

>>993699

Speak for yourself. I had already disabled hyper threading on my openbsd machines because it was noticeably slower. After Theo's warning I disabled it everywhere.

>>994293

>caring about singlethreaded performance

>leaving SMT on

>>994296

I don't know because I am running Windows 7 without updates. But I doubt there will ever be a scheduler that can use SMT without having performance drawbacks. SMT is only useful if programs actually take advantage of it, otherwise it's actually worse.

>>993688 (OP)

Another misleading thread title, so far it’s only confirmed on Intel.

INTEL IS THE ONLY COMPANY WHICH APPEARS TO BE VULNERABLE TO THE VAST GRAND MAJORITY OF THESE ISSUES.

>>999606

>Only Intel CPUs use SMT

>>999606

They might have only proven it on Intel so far, but they plan to do so with AMD next.

> "We leave as future work exploring the capabilities of PortSmash on other architectures featuring SMT, especially on AMD Ryzen systems," the research team said in a version of their paper shared with ZDNet, but Brumley told us via email that he strongly suspects that AMD CPUs are also impacted.

I'm so glad i never spent money on intel shit.

>>999743

Don't worry fam, that's still enuf to play Super Intel Smash Bros.