Everyone else: "16 cores and 32 threads!"

Me: "16 cores!"


True security freaks know.

@inference
OpenSPARC had proper SMT implementation I think, Intel's is just bullshit.
I get what you mean though: shmem is bad, you have to do it properly and use ipc, bla-bla-bla
From security perspective you're right of course!
@getimiskon

@m0xee @getimiskon I'm not sure how SMT works on OpenSPARC, but on Intel, AMD, ARM, and POWER, SMT can never be secure, because it shares cache and such.

No matter how many hardware, microcode, firmware, or software, mitigations they make, it will always be vulnerable and we just wait for the next vulnerability to be found.
Follow

@inference
Well, of course they share cache, they can address the memory of the whole process in most OSes, there is no point in isolating them at lower level.
Threads are already a bad idea as they are, you can't make them any more fscked up at hardware level😅
Shared cache is bad when you can use it to access other processes' memory. That is how vulns like Spectre work, flat memory model is to blame for this. Addressing in x86 Protected Mode was so much better than what we have now
@getimiskon

@m0xee @getimiskon Let's just to back to simple, native, static, small, easily maintainable software, and non-SMT, non-optimised processors...

AKA the 1990s.

@inference
Threads were already there as a software concept, as well as preemptive multitasking. It was a matter of time for those to get hardware support, for performance's sake.
But you're right, CPUs weren't nearly that complex as the ones we have today. Had we any security concerns, it was all software — thus way easier to patch things up and get a hardened system.
@getimiskon

Sign in to participate in the conversation
Librem Social

Librem Social is an opt-in public network. Messages are shared under Creative Commons BY-SA 4.0 license terms. Policy.

Stay safe. Please abide by our code of conduct.

(Source code)

image/svg+xml Librem Chat image/svg+xml