Freedom and security issues on x86 platforms • Hacker News Board

Re: Freedom and security issues on x86 platforms

#181

Post by sokoloff » Mon, Apr 04, 2016, 8:26 PM UTC

nickpsecurity wrote: post #172

wolfgke wrote: post #161

Earlier quoted context omitted.

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

> a Freescale iMX ARM was like $4 per 100 units last time I looked it up.

$4 per 100 units (4 pennies each), or $4 per unit in quantity of 100?

Re: Freedom and security issues on x86 platforms

#182

Post by jMyles » Mon, Apr 04, 2016, 8:27 PM UTC

pdkl95 wrote: post #179

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.

...but eventually, heartbleed was noticed. And covertly sending large amounts of multimedia content from a PC is far more conspicuous behavior.

Re: Freedom and security issues on x86 platforms

#183

Post by pdkl95 » Mon, Apr 04, 2016, 8:28 PM UTC

ctz wrote: post #168

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 is a major point and one I thought the linked post would deal with from its title. For a user-owner point of view, I agree with your assessment of SGX. I imagine that, once it becomes used for things like media DRM and games copy protection, users will start turning it off in their BIOS, or managing the signing key whitelist manually. And I wouldn't blame them. But from a user-not-owner point of view (ie, cloud c…

https://jbeekman.nl/blog/2015/10/intel-has-full-control-over...

Re: Freedom and security issues on x86 platforms

#184

Post by na85 » Mon, Apr 04, 2016, 8:29 PM UTC

nucleardog wrote: post #134

teraflop wrote: post #88

Earlier quoted context omitted.

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

You keep saying that "someone should have noticed something" but as the old adage goes, absence of evidence is not evidence of absence

What you seem to keep missing is that we know from the Snowden leaks that the capability already exists, and NSA has successfully used implants to do data exfil in the past.

Re: Freedom and security issues on x86 platforms

#185

Post by the8472 » Mon, Apr 04, 2016, 8:41 PM UTC

ctz wrote: post #168

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 is a major point and one I thought the linked post would deal with from its title. For a user-owner point of view, I agree with your assessment of SGX. I imagine that, once it becomes used for things like media DRM and games copy protection, users will start turning it off in their BIOS, or managing the signing key whitelist manually. And I wouldn't blame them. But from a user-not-owner point of view (ie, cloud c…

If you don't trust your cloud provider i'm not sure whether SGX is the solution. Consider all those side-channel attacks.

It might provide an additional defense barrier, but you'd still want to run on trusted hardware. And if you have trusted hardware then it should be ok to use user-provided signing keys, just as you can do with secure boot configurations (at least the acceptable kind).

So as long as you're the exclusive user of a machine it should be sufficient to also hand your public key to the cloud provider so they can put it in the BIOS.

The only reason for SGX to not support that is DRM&Co.

Re: Freedom and security issues on x86 platforms

#186

Post by nebulous1 » Mon, Apr 04, 2016, 8:46 PM UTC

jMyles wrote: post #180

nebulous1 wrote: post #171

Earlier quoted context omitted.

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

Have to quite strongly disagree with you there. The FBI wanted Apple to create and sign software that they could forcibly push onto the phone in order to get it to do what they wanted it to do. In the recent case it was about bruteforcing a passcode, but the concept is identical regardless of the payload. It's exactly the same scenario Intel or AMD could be faced with. The entire Apple situation hinged on the fact that it was possible for Apple to comply, without that there would be no situation.

Re: Freedom and security issues on x86 platforms

#187

Post by kristoffer » Mon, Apr 04, 2016, 8:46 PM UTC

nickpsecurity wrote: post #125

kristoffer wrote: post #117

Earlier quoted context omitted.

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!

That's about half the peer review I need on that given your background. Next I need a SPARC opponent with HW/SOC experience background giving same recommend haha. Might send it to some of the academics. Another part of my plan was to get academics to build and public domain the source/verilog/whatever so we can benefit from their cheap EDA licensing and shuttle runs. Pick bare minimum I.P. we need, like DDR or PCI, t…

Academics should absolutely open source their stuff to a larger degree and contribute it a common open source community. I don't think LEON/GRLIB will be that community but may be a part of it. OpenCores did not succeed but I have hopes for what's cooking around FOSSi foundation/LibreCores.

Re: Freedom and security issues on x86 platforms

#188

Post by pdkl95 » Mon, Apr 04, 2016, 8:46 PM UTC

jMyles wrote: post #182

pdkl95 wrote: post #179

Earlier quoted context omitted.

> without our noticing it? Nobody noticed the bad heartbeat packets being sent to openssl for a long time.

...but eventually, heartbleed was noticed. And covertly sending large amounts of multimedia content from a PC is far more conspicuous behavior.

> multimedia content

Obviously that's not what would be sent. A keylogger would be far more likely.

Re: Freedom and security issues on x86 platforms

#189

Post by rcarmo » Mon, Apr 04, 2016, 8:47 PM UTC

When I saw RISCV mentioned as an alternative, I had to check the date twice to make sure it wasn't an April Fools'. I understand the concerns and all, but wish the alternatives were a little better picked out.

Most people already mentioned SPARC and ARM as alternatives, so I won't delve into those arguments other than point out that there will _always_ be commercial interests at stake here - hardware, unlike software, requires considerable material resources to create* and distribute (and is still harder - and therefore rarer - to create for its own sake), so there won't be a wide variety of viable options out there, and new CPU architectures don't grow on trees.

Better to lobby for open specs on the "offending" bits of hardware, really.

* - yes, software creation can also require material resources (and a whole lot of time, which can be expensive). Let's not belabor that point...

Re: Freedom and security issues on x86 platforms

#190

Post by broodbucket » Mon, Apr 04, 2016, 8:50 PM UTC

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.

This is FUD, POWER8 is bi-endian and they're pushing LE as standard with the OpenPOWER ABI.