Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Freedom and security issues on x86 platforms

mail.fsfeurope.org

Post reply on HN
Print view View original

71–80 of 282 posts

Re: Freedom and security issues on x86 platforms

#71

Post by kristoffer »

nickpsecurity wrote: post #42

Unbelievable. Yet again, we have a post on finding x86 alternative that's most FOSS friendly. Yet again, the author is unaware of or ignores the only architecture that's open, has GPL cores, and an ecosystem. That's SPARC. Oracle's T1 and T2 cores are open-source to study. More appropriately, Cobham-Gaisler's Leon3 HW is dual-licensed under GPL and commercial. The Leon4 is 4-cores. SPARC ISA is open. Open Firmware ex…

I thought it was pretty bad as well ...

But the SPARCs you mention have their drawbacks. LEON is not that competetive in the high end (in order single issue, low clock freq) and T1/T2 are only cores (i.e. without interesting "uncore" stuff) and not that good as general purpose "desktop like" CPU.

I have much higher hopes for RISC-V, the community is really booming and the architecture is better than SPARC.

I say this as a former Gaisler employee and SPARC proponent :-)

Re: Freedom and security issues on x86 platforms

#72

Post by BrainInAJar »

nickpsecurity wrote: post #42

Unbelievable. Yet again, we have a post on finding x86 alternative that's most FOSS friendly. Yet again, the author is unaware of or ignores the only architecture that's open, has GPL cores, and an ecosystem. That's SPARC. Oracle's T1 and T2 cores are open-source to study. More appropriately, Cobham-Gaisler's Leon3 HW is dual-licensed under GPL and commercial. The Leon4 is 4-cores. SPARC ISA is open. Open Firmware ex…

Not to mention that ARM's ABI is hidden behind a paid NDA. ARM is even less open than x86

Re: Freedom and security issues on x86 platforms

#73

Post by acveilleux »

jMyles wrote: post #64

Hmm. OK, I have two questions - maybe somebody here has answers: 1) "...these proprietary blobs could easily contain code to exfiltrate encryption keys, remotely activate microphones and cameras..." This seems basically impossible to actually achieve in reality though, because there will still associated network traffic that can be sniffed, and will have been by now, right? I mean, it is plausible that somehow we all…

The fact that the NSA has implants (from the various Snowden files) that do exactly this and exfiltrate over a network should tell us that this is not so far fetched. The bulk of the data volume is only used when the capability is being exploited. It would not be so hard to send out marker of exploitability over innocuous traffic (say tweaking an HTTP header) meant to be picked up by sniffing / MotS.

Re: Freedom and security issues on x86 platforms

#74

Post by anon4 »

andrewstuart2 wrote: post #23
speeder wrote: post #5

I've been looking into this recently. Basically, the things mentioned on the text, made free software bios and firmwares impossible, some of the free software projects that exist now are mostly "binary blobs loaders", having more binary blob than free software code running. There is some good analysis on why even Intel can't fix this if they wanted to, unless they stopped shipping some features entirely, their Intel…

I'd think it would be easier and more profitable (more convenient for "customers" than buying new hardware) to sell the "speed unlock" solution, much like cryptolocker does with your personal data.

And we'll finally be able to download more RAM.

Re: Freedom and security issues on x86 platforms

#75

Post by qubex »

xenadu02 wrote: post #31
speeder wrote: post #5

I've been looking into this recently. Basically, the things mentioned on the text, made free software bios and firmwares impossible, some of the free software projects that exist now are mostly "binary blobs loaders", having more binary blob than free software code running. There is some good analysis on why even Intel can't fix this if they wanted to, unless they stopped shipping some features entirely, their Intel…

Sounds like rich, fertile ground for the NSA, KGB, and other state agencies. They could be deploying such code right now and I'm not sure we would know it.

The KGB no longer exists. It was superseded by the FSB in 1995.

Re: Freedom and security issues on x86 platforms

#76

Post by 5ilv3r »

cwyers wrote: post #37

Okay, so we get a pile of FUD (Secure Boot and Intel ME are DRM features now? 'kay), no acknowledgement of the actual security threats that compel Intel, AMD, Microsoft and the OEMs to adopt these measures, and an appeal to dump x86 for ARM (um), MIPS (uhhhhhhh), POWER8 (wat), and RISC-V (how?). What is the point of this, exactly?

If a secure boot chain makes you feel nice and fuzzy inside, then perhaps you might be interested in setting up your own. Without the ability to do so, you are boned if the trusted entity becomes untrustworthy (such as if the mfg was to be acquired).

If you alone are the trustworthy entity, things work better.

Re: Freedom and security issues on x86 platforms

#77

Post by vox_mollis »

nickpsecurity wrote: post #42

Unbelievable. Yet again, we have a post on finding x86 alternative that's most FOSS friendly. Yet again, the author is unaware of or ignores the only architecture that's open, has GPL cores, and an ecosystem. That's SPARC. Oracle's T1 and T2 cores are open-source to study. More appropriately, Cobham-Gaisler's Leon3 HW is dual-licensed under GPL and commercial. The Leon4 is 4-cores. SPARC ISA is open. Open Firmware ex…

So, why is SPARC left off in all these analyses?

Guessing it's the entry-level price of US$39,821.00 for Oracle's smallest server?

Re: Freedom and security issues on x86 platforms

#78

Post by jMyles »

salem wrote: post #70
jMyles wrote: post #64

Hmm. OK, I have two questions - maybe somebody here has answers: 1) "...these proprietary blobs could easily contain code to exfiltrate encryption keys, remotely activate microphones and cameras..." This seems basically impossible to actually achieve in reality though, because there will still associated network traffic that can be sniffed, and will have been by now, right? I mean, it is plausible that somehow we all…

It's called covert channels. It could be done by flipping some unused/ignored bits in ip4/tcp headers in a stream of traffic that goes past a collection point.

But this is still easily visible with wireshark, right? Don't you think we'd have discovered this by now?

Re: Freedom and security issues on x86 platforms

#80

Post by 5ilv3r »

em3rgent0rdr wrote: post #63
darpa_escapee wrote: post #8

ARM architectures also suffer from this. You'll be hard pressed to find a board that doesn't require a propriety board support package somewhere in the stack. Ironically, it is usually the bootloader that is/requires a blob or it is the DTB. I remember being in middle school and reading Stallman's articles on the dangers of a TPM-oriented push by manufacturers. As cliche as it is, Stallman was right. The push for pla…

I'm using ASUS C201 which uses ARM. It was a Chromebook, now running libreboot and parabola linux.

Can you share documentation? I have an upstream kernel running on my peach pit, but have not replaced uboot yet.
Post reply on HN