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

171–180 of 282 posts

Re: Freedom and security issues on x86 platforms

#171

Post by nebulous1 »

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…

He's not saying that all machines are actively doing any of that, or even that Intel/AMD/anybody have already developed code to do so. He's just pointing out that this chip exists, it has to capability to do what he's described, and there's nothing that we can currently do to stop it if we're using an affected machine, as we don't have any control over the code being run. As to why the companies would do this ... it wouldn't necessarily be them if they lost control of the signing keys. And you can't ignore the fact that the FBI just tried to get Apple to do something pretty damn similar.

Re: Freedom and security issues on x86 platforms

#172

Post by nickpsecurity »

wolfgke wrote: post #161
nickpsecurity wrote: post #156

Earlier quoted context omitted.

Remember, I mentioned the SOC vendors as well. They currently license MIPS and ARM. Many choose MIPS due to cheap license. ARM's license, royalties, and restrictions are ridiculously expensive. SPARC has a cost advantage over it. So, once again, it's neither energy nor costs that are reasons they chose MIPS and ARM over SPARC. Keep guessing.

I'm not so sure: Because currently ARM processors are currently sold in a large volume (if not for a technical reason then by momentum) they can be made a cheaper by economy of scale. This does not mean that this has to stay in the future, but currently this seems to be the case.

Now there's a good argument. Here's the real value, though, straight from ARM themselves: the ecosystem. They've built a whole ecosystem of boards, firmware, software, everything around ARM you get when you license their tech. It might be cheaper with economy of scale as well although licensing and royalties have to factor in. I'd default on MIPS there since they can be up to 10x cheaper than ARM. But yeah, a Freescale iMX ARM was like $4 per 100 units last time I looked it up.

So, it's mainly the ecosystem with companies and FOSS people wanting to benefit from what's already there instead of improve FOSS HW ecosystems. There's currently, but not indefinitely as you said, a cost advantage for the mass market SOC's as well for PPC, ARM, MIPS, and possibly SuperH.

Re: Freedom and security issues on x86 platforms

#173

Post by albinofrenchy »

Retr0spectrum wrote: post #142
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…

Source on the JVM claims?

I'd like to see that source too. On something this low level, running a JVM seems both useless and prohibitively expensive.

Re: Freedom and security issues on x86 platforms

#174

Post by nickpsecurity »

LargoLasskhyfv wrote: post #163
nickpsecurity wrote: post #119

Earlier quoted context omitted.

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.

I knew you'd like that. The temlib is impressive because of its completeness, though it seems like hobbyist thing, maybe useful for retrocomputing and software archaelogy ;) But this comment http://temlib.org/site/?p=567#comment-210 makes me realize that the design doesn't even fully utilize the almost EOLd Spartan-6 (a low end one, even in its heyday). Now imagine what could be done in something new? Combined with t…

"makes me realize that the design doesn't even fully utilize the almost EOLd Spartan-6 (a low end one, even in its heyday)"

Yeah, it's impressively efficient. Adds more evidence to our argument that SPARC implementations can be technologically competitive in efficiency with ARM, etc.

"AFAIUI this would smell like Soft Machines VISC, only better, because FREE!"

It could happen. Achronix's FPGA's are badass, too, hitting up to 1.5GHz. Their dev boards are actually cheaper than Oracle's SPARC servers, too, with added benefit of putting custom logic for accelerators in there w/ SPARC I.P.. I haven't studied much of VISC, though, so I have little comment there.

I'll comment on those other links later tonight as I'm off to do some more paying work. :)

Re: Freedom and security issues on x86 platforms

#175

Post by cwyers »

5ilv3r wrote: post #76
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.

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

That really, really depends on how trustworthy you are, doesn't it? I would argue that most computer users don't and shouldn't trust themselves to secure against low-level threats, and some of the people who do trust themselves really shouldn't.

Re: Freedom and security issues on x86 platforms

#176

Post by gecko »

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.

The POWER line, and all PowerPCs except the G5, are actually bi-endian, and quite a few operating systems run in little-endian mode (including all vaguely recent Linux releases I know). The G5's lack of a bi-endian mode is why VirtualPC didn't ship on it for a long time (if at all; I don't even remember).

Re: Freedom and security issues on x86 platforms

#177

Post by oldmanjay »

kbenson wrote: post #114
jjaredsimpson wrote: post #45

Earlier quoted context omitted.

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

If a piece is written with a confusingly inappropriate tone for the subject matter, you can't solely blame the reader for being confused since it was the expressed intent of the author to instill that state.

Re: Freedom and security issues on x86 platforms

#178

Post by CloudFlrFeedbck »

nickpsecurity wrote: post #167
rsync wrote: post #155

Earlier quoted context omitted.

"Oracle's T1 and T2 cores are open-source to study." If you had to pick a Oracle (Sun?) T2 based system to purchase off of ebay, with the interest in using it as a "more free, more open" system, what would you buy ? What OS would you run on it ?

I wouldn't. I'd use Gaisler's immediately because it's fully open and already FPGA qualified. I'd then buy a good FPGA board. Then I'd run it on there. It would probably run like a multi-core version of my old Pentium II. Yet, I programmed, hacked, gamed, and so on with it. Later, I'd put it on an eASIC Nextreme or actual ASIC if money came in for better performance, power, and unit pricing.

Which FPGA would you use? High-end FPGAs (and FPGA software) are very proprietary and locked down.

Re: Freedom and security issues on x86 platforms

#179

Post by pdkl95 »

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…

> without our noticing it?

Nobody noticed the bad heartbeat packets being sent to openssl for a long time.

Re: Freedom and security issues on x86 platforms

#180

Post by jMyles »

nebulous1 wrote: post #171
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…

He's not saying that all machines are actively doing any of that, or even that Intel/AMD/anybody have already developed code to do so. He's just pointing out that this chip exists, it has to capability to do what he's described, and there's nothing that we can currently do to stop it if we're using an affected machine, as we don't have any control over the code being run. As to why the companies would do this ... it…

> And you can't ignore the fact that the FBI just tried to get Apple to do something pretty damn similar.

I was very against the FBI's reasoning in the Apple case (and in fact, I'm against their existence generally).

But I don't think that bypassing an unlock retry limit is "pretty damn similar" morally, legally, or technologically to a solution that can arbitrarily execute code remotely, on demand, and with root privileges on nearly any PC and game console in the world.

Post reply on HN