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

111–120 of 282 posts

Re: Freedom and security issues on x86 platforms

#111

Post by nickpsecurity »

kristoffer wrote: post #84
vox_mollis wrote: post #77

Earlier quoted context omitted.

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?

Then you are missing the point he is making. LEON is a GPL implementation of SPARCv8 which you can download and use in an FPGA, tape out your own ASIC or buy one of the existing SoCs built with it (might not be that easy...). In other words, more open than the alternatives listed.

Exactly. There's a ton of implementations ranging from free for FPGA's to S-ASIC's from eASIC to embedded CPU's from Gaisler to cloud servers from Oracle to mainframes from Fujitsu & Russia. One can also legally clean-slate a SPARC chip without legal fears. Unlike POWER, ARM, and MIPS. The ISA, its docs, a firmware standard... all of that already open.

So, why is it not on the table for... anything in FOSS? Doesn't seem rational. Even a bit hypocritical given vendors like Gaisler and nonprofits like SPARC International have met FOSS halfway or almost wholly. Unlike the others that sue FOSS developers.

Re: Freedom and security issues on x86 platforms

#112

Post by wyldfire »

mmebane wrote: post #65
Galanwe wrote: post #24

Earlier quoted context omitted.

I was at FOSDEM this year (2016) and there was a talk from the leader of LibreBoot. Honestly, his talk on the state of the project was very bitter. He literally said that there is absolutely no hope that LibreBoot will ever be able to cope with ME, and that the fight is over since 2008. As much as I would absolutely love to be able to run a free firmware, unless there is a major change/outsider in the hardware manufa…

I've been using a Raspberry Pi 3 for the past week, and have been pleasantly surprised by the performance. It's no speed demon, to be sure, but it's good enough for all my basic tasks. I wish there were a general "open computing" branch of the Raspberry Pi Foundation that would produce a $50-$100 "pro" version with more RAM and faster bus+peripherals.

There are more "pro" oriented boards than the Pi series. ODROID, e.g. It indeed has faster I/O and better CPU. You lose out on the scale benefits from Pi.

Few if any of them have "enterprise" grade quality IMO. The ones that strive for this (HP Moonshot, e.g.) are significantly more expensive than $50-100.

Note that the topic at hand is binary blobs and trust and Pi and other ARM SoC fall short there.

Re: Freedom and security issues on x86 platforms

#113

Post by nickpsecurity »

Symmetry wrote: post #110
nickpsecurity wrote: post #99

Earlier quoted context omitted.

They stay on Slashdot and in my news feed. Here's a few from Oracle and one from Fujitsu: Oracle T4 http://www.oracle.com/us/corporate/features/sparc-t4-announc... Oracle M6 http://www.oracle.com/us/corporate/features/sparc-m6/index.h... Oracle M7 https://blogs.oracle.com/rajadurai/entry/sparc_m7_chip_32_co... Fujitsu https://en.wikipedia.org/wiki/SPARC64_VI

Yes, new SPACE processors are coming out. The chips are being made available but the intellectual property isn't.

That's true. I'm also against buying Oracle's I.P. because they're too scheming and sue-happy. I'm listing those to show SPARC ISA has a series of implementations competitive with x86 on the high-end. It's actively developed and badass rather than dead. That's all.

Re: Freedom and security issues on x86 platforms

#114

Post by kbenson »

jjaredsimpson wrote: post #45
ashitlerferad wrote: post #11

Earlier quoted context omitted.

People have certainly done ME reverse engineering: http://me.bios.io/

>there is a little man inside your pc... and his thing is bigger than yours. Your wife knows this. I'm supposed to believe this technology is dangerous. But the advocates are children.

I think you're supposed to be able to distinguish the message from the medium. Certain styles can definitely make that harder, but ultimately if you can't examine an issue by the facts presented, the failure falls on you, as do the consequences.

To be clear, I also think the referenced bit is childish and detracts from the message. I just don't think that should affect your belief in whether it's important.

Re: Freedom and security issues on x86 platforms

#115

Post by nickpsecurity »

kabdib wrote: post #55
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…

Is SPARC unpopular because of its power consumption?

There used to be a lot of competition between several types of RISC machine and several x86 vendors. I know about the consolidations on x86 side. I'm not sure why SPARC lost favor versus others, though. I wasn't able to afford RISC workstations back when all that was happening. It would be nice for one of older folks to chime in on what made SPARC unpopular back then.

Re: Freedom and security issues on x86 platforms

#116

Post by praptak »

qubex wrote: post #75
xenadu02 wrote: post #31

Earlier quoted context omitted.

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.

Clever of them to make the world think they don't exist anymore! Only surpassed by the Czech navy... but I better not speak of such topics.

Re: Freedom and security issues on x86 platforms

#117

Post by kristoffer »

nickpsecurity wrote: post #106
kristoffer wrote: post #71

Earlier quoted context omitted.

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…

"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." There's definitely drawbacks. I've just not even seen interest in embedded sector of FOSS for SPARC even with open cores. I wouldn't argue stuff like Leon4 in i…

I agree that LEON is overlooked in the MCU market.

Wrapping up one or multiple of the RISC-V cores in GRLIB is something I think would benefit both Gaisler and the RISC-V community and something I have thought of doing myself if I had the time!

Re: Freedom and security issues on x86 platforms

#118

Post by digler999 »

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…

I agree that if these things were by default constantly exfiltrating, say, webcam data, someone would have noticed. But their use is likely much more insidious.

Any keyboard event generates some kind of interrupt on x86, right ? Suppose this "ME" happens to record the last 64k keystrokes into a rolling buffer. Furthermore, suppose there is a very, very particular sequence of instructions that can be sent to retrieve this rolling buffer ? Boom. No more encryption (at least none that requires typing a key in from the kb).

Oh, you use binary keys ? Cool, intel has special x86 instructions for doing AES. I'm sure they wouldn't do anything like copy the, oh...KEYS, into the hypothetical rolling buffer, would they ? No, that would be "dishonest", and we all know everyone who makes computer hardware and software would never think of doing something so egregiously deceitful, don't we ?

Re: Freedom and security issues on x86 platforms

#119

Post by nickpsecurity »

LargoLasskhyfv wrote: post #82
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…

There are even more implementations than the ones you mentioned. http://temlib.org/site/?page_id=14 and then http://apple-core.info/outcomes.html , schematic overview http://www.date-conference.com/files/file/date11/ubooth/157.... , necessary toolchain http://sp.utia.cz/index.php?ids=results&id=applecore . Apart from that, i'm thinking something like OpenFirmware should be mandatory for every Vendor, because without…

Those are pretty neat. Didn't know about the Apple many-core. Far as OpenFirmware, I think it should be mandatory along the lines of something like First Sale doctrine. If we bought a device, we should be able to control its use by law. We can't do that with software due to copyright. That implies an open, mandatory firmware available that lets us load our own software in.

Re: Freedom and security issues on x86 platforms

#120

Post by TazeTSchnitzel »

JustSomeNobody wrote: post #68
tinco wrote: post #48

Earlier quoted context omitted.

I suspect at some point they will simply drop Intel for their own (ARM) platform. I think moving will be easy once all app store submissions are in bitcode.

I strongly believe you are correct. They have been mentioning that their ARM processors are desktop worthy. I also believe Apple are displeased with Intel's current inability to consistently get their new chips to market. All of this has to make one think Apple will take matters into their own hands soon. Likely within the next 2 years.

It sounds almost unbelievable, but it could happen. I mean, Apple, unlike every other computer company, has successfully transitioned processor architecture twice before (68k to PowerPC, PowerPC to Intel). They could pull the same tricks they pulled for PPC to have a smooth transition: x86 emulation on ARM, “Universal” (fat) binaries, and making it easy for developers to port their apps.
Post reply on HN