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

131–140 of 282 posts

Re: Freedom and security issues on x86 platforms

#131

Post by twoodfin »

sspiff wrote: post #83
JustSomeNobody wrote: post #68

Earlier quoted context omitted.

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.

I don't have a guess at what Apple is actually going to do, but the Retina rollout is a plausible model. Even 5+ years after the first Retina product, it's still not available across the lineup.

I don't think the switch would present a significant problem in marketing or for developers, so it would purely be a question of having the chips that fit the products. The Macbook, as you point out, is basically already there.

Re: Freedom and security issues on x86 platforms

#132

Post by concernedctzn »

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…

What is more unbelievable is the Management Engine itself, not a nitpick about a platform being left out of the list of alternatives. It did not seem like he was creating a comprehensive list, just a first attempt.

Re: Freedom and security issues on x86 platforms

#133

Post by nickpsecurity »

petra wrote: post #129
nickpsecurity wrote: post #106

Earlier quoted context omitted.

"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…

Nick, The larger context of all this issue is defense. So on one side there are the five eyes governments wanting it this way. On the other side(and probably very interested in 100% security), you might have various countries supporting terrorist organizations, terrorist organizations, crime syndicates, russia, china, etc. Doesn't this context hints to us that 100% security would be much harder than creating some des…

I've addressed a good chunk of what it takes for system and hardware security in at least two places:

http://pastebin.com/y3PufJ0V

https://news.ycombinator.com/item?id=10468624

There won't be 100% security because underlying physics fights you and our field is too new. Best we can hope for is making attacks hard and physical. There's great work in secure HW/SW architectures that should knock out about all SW stuff with effort. Details published in all kinds of CompSci publications. HW, too, far as implementing it correctly with some security properties. The rest, esp tamper-resistence, is still in infancy far as having stuff that actually works.

Now, what we're talking about in this thread is having an ISA, chip implementation, firmware, and SW stack that is not a black box and is under your control. Preferably without built-in, convenient spyware. Mainstream FOSS users are currently so far away from this that it's a reasonable, interim goal. So, I had to bring up SPARC as an addition to the list that has side benefit of reducing legal risks.

Re: Freedom and security issues on x86 platforms

#134

Post by nucleardog »

teraflop wrote: post #88
jMyles wrote: post #78

Earlier quoted context omitted.

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…

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

Lots of organizations use various forms of intrusion detection. A network intrusion detection system (NIDS) would be an off-device system which monitors network traffic for suspicious or obviously malicious packets.

It's certainly no guarantee, but somewhere along the line someone probably would have noticed something if these systems were exfiltrating data via the network using something like IPv4 headers. Specifically, a quick look makes it look like Snort (an open source NIDS) may actually be distributed with rules to alert on IPv4 reserved bits being set.

Re: Freedom and security issues on x86 platforms

#135

Post by wolfgke »

CyberDildonics wrote: post #128
nickpsecurity wrote: post #111

Earlier quoted context omitted.

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 s…

This makes me wonder why we don't see sparc chips in things like routers or other hardware that doesn't require lots of binary compatibility from 3rd party software.

Because ARM and MIPS chips are a lot more power-efficient.

Re: Freedom and security issues on x86 platforms

#136

Post by makomk »

nickpsecurity wrote: post #44
riscy wrote: post #40

I'd personally like to see the FOSS community try to embrace the POWER architecture: Ubuntu/Canonical are major members of the OpenPOWER foundation [1], so at least an entity sympathetic with our philosophy has an influence on the architecture. [1] http://openpowerfoundation.org

Red Hat has supported POWER for a long time. Debian does. Even Mint had a PPC release. The big BSD's do. Amiga's are still on PPC haha. I think it's not a question of FOSS support by OS developers. It's the users and app that don't commit to x86 alternatives.

One issue with PPC and POWER is that they're generally big-endian and everything assumes little-endian these days thanks to x86. Even JavaScript is little-endian now.

Re: Freedom and security issues on x86 platforms

#137

Post by nickpsecurity »

concernedctzn wrote: post #132
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…

What is more unbelievable is the Management Engine itself, not a nitpick about a platform being left out of the list of alternatives. It did not seem like he was creating a comprehensive list, just a first attempt.

The management engine is a result of a steady stream of changes, enhancements, proposals, etc going back probably a decade. There was demand from business and government sectors for easier repair/management, better security, and lock-in from software/media segments. Consumers largely were apathetic and stayed out of those discussions as usual. However, there was demand among some of them for cheaper repairs and better malware protection. Management Engine was one of results of all that.

One could see it coming years in advance. Matter of fact, I fought solutions like that in favor of instrumented, robust coprocessors that did that. They could cost $20-30 more. They could even be in an embedded PCI card that also did I/O offloading, firewalls, and security monitoring with secure RTOS. Many extra benefits to justify extra $20-200 depending on form factor. Yet, people wanted dirt cheap, integrated solution.

They got it...

Re: Freedom and security issues on x86 platforms

#138

Post by nickpsecurity »

makomk wrote: post #136
nickpsecurity wrote: post #44

Earlier quoted context omitted.

Red Hat has supported POWER for a long time. Debian does. Even Mint had a PPC release. The big BSD's do. Amiga's are still on PPC haha. I think it's not a question of FOSS support by OS developers. It's the users and app that don't commit to x86 alternatives.

One issue with PPC and POWER is that they're generally big-endian and everything assumes little-endian these days thanks to x86. Even JavaScript is little-endian now.

That's one of those sad realities of Worse is Better in action. Definitely a disadvantage. Far as why big-endian was The Right Thing, drfuchs had this to say:

"Because big-endian matches how most humans have done it for most of history ("five hundred twenty one" is written "521" or "DXXI", not "125" or "IXXD"). Because the left-most bit in a byte is the high-order bit, so the left-most byte in a word should be the high-order byte. Because ordering two 8-character ascii strings can be done with a single 8-byte integer compare instruction (with the obvious generalizations). Because looking for 0x12345678 in a hex dump (visually or with an automatic tool) isn't a maddening task. Because manipulating 1-bit-per-pixel image data and frame buffers (shifting left and right, particularly) doesn't lead to despair. Because that's how any right-thinking person's brain works."

Re: Freedom and security issues on x86 platforms

#139

Post by MichaelGG »

the8472 wrote: post #61

And it's getting worse, SGX[1] allows 3rd party encrypted binary blobs to run on your CPU without being inspectable. It's sold as way to protect your secrets from malware. But it more likely will be used to run DRM code on the user's computer while treating the user as a hostile entity. [1] https://software.intel.com/en-us/sgx

SGX has the potential to be amazing though. With it you can build "trusted" applications. For example, a Bitcoin mixer that's provably secure. (Well as secure as trusting Intel and users not to be able to break the chip.)

Re: Freedom and security issues on x86 platforms

#140

Post by nickpsecurity »

CyberDildonics wrote: post #107
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…

To be fair, Oracle winding up with the most open hardware is such an outlier it would be like checking if Stephen Hawking won the Boston marathon.

Lmao. Yeah, that would be ridiculous. Truth is more reasonable:

https://news.ycombinator.com/item?id=11424195

Post reply on HN