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

241–250 of 282 posts

Re: Freedom and security issues on x86 platforms

#241

Post by vancan1ty »

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?

Taken from this link: https://libreboot.org/faq/

"The ME firmware is compressed and consists of modules that are listed in the manifest along with secure cryptographic hashes of their contents. One module is the operating system kernel, which is based on a proprietary real-time operating system (RTOS) kernel called "ThreadX". The developer, Express Logic, sells licenses and source code for ThreadX. Customers such as Intel are forbidden from disclosing or sublicensing the ThreadX source code. Another module is the Dynamic Application Loader (DAL), which consists of a Java virtual machine and set of preinstalled Java classes for cryptography, secure storage, etc. The DAL module can load and execute additional ME modules from the PC's HDD or SSD. The ME firmware also includes a number of native application modules within its flash memory space, including Intel Active Management Technology (AMT), an implementation of a Trusted Platform Module (TPM), Intel Boot Guard, and audio and video DRM systems."

Re: Freedom and security issues on x86 platforms

#242

Post by arca_vorago »

AnthonyMouse wrote: post #230
Kadin wrote: post #221

Earlier quoted context omitted.

Many big players have vested interest in hardware platforms that are not tampered with out-of-the-box, or open to easy tampering, by their adversaries. The Chinese have an interest in having a hardware platform that doesn't have NSA code baked into it; the US government and major US corporations likewise want hardware that doesn't phone home to Unit 61398. The Russians don't want either but probably have their own am…

> Hardware fabrication is a capital intensive industry, and capital intensive industries are pretty vulnerable to coercion by the governments in which all their capital equipment sits. If the spec is open then it should be possible for a fancy lab to verify that the hardware is manufactured to spec, right? So if you have it manufactured in Taiwan but then have random samples verified by labs in the US, Japan and Euro…

At the sizes we are talking about, it's plausible to put in a hardware backdoor that even grinding down could miss...

Re: Freedom and security issues on x86 platforms

#243

Post by soraminazuki »

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…

Yeah, all the stuff we know from the Snowden leaks are "part of a grand conspiracy theory", I guess...at least according to you.

Re: Freedom and security issues on x86 platforms

#246

Post by spiralpolitik »

muricula wrote: post #34
DenisM wrote: post #19

Earlier quoted context omitted.

Apple will be sitting pretty with their own CPU, heh? At least in the iOS devices, but who knowns what the (near) future brings to the Mac line.

I doubt it. The powerpc to Intel switch was really painful because the desktop platform has the perpetual ball and chain of backward compatability. I doubt Apple would try to beat Intel at their own high performance game anyway.

At one point AppKit and FoundationKit supported 4 architectures (68k, x86, HP, and Sparc), most Cocoa based applications were just a recompile away.

The main issue with the PowerPC to x86 was Carbon which was never designed to be a cross-platform toolkit in the same away that Cocoa was. Given that Carbon 64 never got off the starting blocks and Carbon 32 was deprecated way back in 10.8 switching architectures will be less painful this time around.

Re: Freedom and security issues on x86 platforms

#247

Post by jMyles »

soraminazuki wrote: post #243
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…

Yeah, all the stuff we know from the Snowden leaks are "part of a grand conspiracy theory", I guess...at least according to you.

Well is it? Or isn't it? Why do you say, "according to [me]?"

Re: Freedom and security issues on x86 platforms

#248

Post by kristoffer »

DominikD wrote: post #212
kristoffer wrote: post #195

Earlier quoted context omitted.

Power consumption is of course very much dependent on the chosen fabrication process and SoC configuration. A LEON3/4 core is comparable to something like a ARM Cortex-M7 and it is not the ISA (when comparing ARMv7 vs SPARCv8) but the implementation that will affect power most. LEON is quite small and power efficient.

Node selected for fabrication does not equalize power consumption. You could go to the same node with other, inherently more power efficient architecture and gain even more oomph per watt. Power efficiency stems from the architecture itself; manufacturing process is a red herring (and a costly one). What you're saying is pretty much like "seasoned bodybuilder would kick white-belt karate practitioner's ass, so it's c…

I said fabrication process AND RTL architecture matters more than ARMv7 vs SPARCv8. They are both quite nice RISC architectures. Nothing in either one is especially power hungry.

Sure you have Thumb, that saves a little on memory bandwidth which is good. But nobody uses it anyways, and you might run slower so you can't sleep as fast.

I like the J2 (the open source sh) project as well but it doesn't have a MMU which rules it out for anything but simpler embedded projects.

Re: Freedom and security issues on x86 platforms

#249

Post by zvrba »

This is a one-sided view. It can, and also is, used to implement theft-protection, thanks to which the police tracked the guy, he got convicted and I got my expensive laptop back. Yes, the guy reinstalled the OS, but the tracking SW survived precisely thanks to these technologies.

Re: Freedom and security issues on x86 platforms

#250

Post by nullc »

MichaelGG wrote: post #139
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.)

Last I spoke to Intel representatives, SGX enclaves couldn't be taken out of debug mode without having a contract and signing key from Intel.

In other words, those amazing applications appear to require Intel to approve the software author. Their keying mechanism allows revocation too.

I hope this changes or that the information I received was in error, but if not then SGX is mostly only useful for DRM. A shame because there really are a lot of productive applications.

Post reply on HN