Live data from Hacker News

Freedom and security issues on x86 platforms

mail.fsfeurope.org

81–90 of 282 posts

Re: Freedom and security issues on x86 platforms

#81
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…

To your 1): there would indeed be network traffic, but how many people have a machine they can truly trust capturing and analysing enough of the traffic going in and out of their LAN? Unfortunately there are few, if any, machines we can truly trust.

Re: Freedom and security issues on x86 platforms

#82

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 MANDATING it, there is no incentive, to abstain from proprietary shit, which locks the customers to it. There is no escaping it. Except to quit.

Re: Freedom and security issues on x86 platforms

#83
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.

Important bit to note here: the two year timeline is probably only feasible for low end devices, like the MacBook and MBA.

Towards the higher end, ARM can't hope to field anything in that timeline to compete with even todays i5 or i7s (or corresponding Xeons). Some people do use this kind of CPU power.

Re: Freedom and security issues on x86 platforms

#84

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?

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.

Re: Freedom and security issues on x86 platforms

#85
post #78
post #70

Earlier quoted context omitted.

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?

There are ways of doing it invisibly. Change timestamps in very subtle ways, Embed data in lossy media formats, etc.

If the code says "phone home if anywhere on the screen you see one of the following email addresses" then it won't show up in a normal security audit, unless you email one of those people during the audit. All the NSA has to do is make the phoning home rare enough that it's probabilisticly unlikely to be observed.

Re: Freedom and security issues on x86 platforms

#86
post #70
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.

[deleted]

Re: Freedom and security issues on x86 platforms

#87
This is the main reason that I'm reluctant to upgrade my 5-year-old AMD Phenom II processor.

> MIPS is often overlooked. However, China has revived this architecture for general purpose computing with the Loongson core...

Baikal-T1 [0] is another interesting MIPS processor that I'd like to play with (or maybe even use).

[0] - https://www.linux-mips.org/wiki/Baikal

Re: Freedom and security issues on x86 platforms

#88
post #78
post #70

Earlier quoted context omitted.

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?

How would Wireshark reveal this kind of attack? If the management chip has direct hardware access, it can hide data in innocuous-looking packets that the host machine never sees. You would have to monitor both the packets that the OS thinks it's sending, and the packets actually received by the switch, and constantly compare them for mismatches. Given the performance cost, I find it hard to believe that anyone except the most paranoid organizations would actually do this.

And of course, if you block the obvious exfiltration methods, all you do is force the attacker to do something more creative. Like modulating inter-packet timings, or even sending data to a nearby radio receiver by using the system bus as an antenna.

Re: Freedom and security issues on x86 platforms

#89

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'd imagine people don't bother looking at an oracle technology and just assume it is closed or unsupported due to the ways they generally operate. That doesn't make it right to do this, but that'd be my guess. I certainly didn't know SPARC was open until your comment.

As far as I know, Oracle has not made any SPARC intellectual property available since the acquisition of Sun. The T1 and T2 lines were emphatically Sun-era products.

Re: Freedom and security issues on x86 platforms

#90
post #52

Even if the ME was opened, the chips themselves are complex enough that nearly anything could be hidden. State machines that enable backdoors from instruction sequences can be pretty small (triggering these from a preferred vector, such as a web browser, seems hard-ish though).

I dislike how libreboot skips microcode updates.
Post reply on HN