Live data from Hacker News

Uncorrectable freedom and security issues on x86 platforms (2016)

decentralize.today

81–90 of 141 posts

Re: Uncorrectable freedom and security issues on x86 platforms (2016)

#81
post #68

Earlier quoted context omitted.

Please. While no-doubt the NSA take advantage of this probably-insecure privileged processor, I seriously doubt they were behind it. Secure boot is an obvious business need and Intel and AMD clearly implemented it in the laziest way possible. And by laziest I mean: nobody is going to argue with you in a meeting if you say "we don't need to release the source code for this". Seriously, anyone who has actually worked i…

We're not talking about secure boot, we're talking about Intel Management engine, which is a totally different story. You do not need ME at all to implement Secure Boot feature. Actually, no one really knows what Intel ME is doing, and _that_ is a huge problem.

Though I agree that there is a high likelihood that there is nefarious activity going on, I also ageee that there a legitimate uses for extra processors and firmware.

Take microcode for example. At one time (as I understand it) microcode was not a signed blob. However companies wishing to hide details of their microarchitecture chose to encrypt it.

My guess is that these encrypted blobs grew first out of corporate closed source culture, which is strong in HW companies. If they are subverted with actively malicious code it was probably by secretive efforts, not the NSA simply propositioning the HW manufacturer.

Finally I'd like to point out that unless you design your CPU chip yourself and oversee the layout of it on the die, it is also possible that the semiconductor manufacturer you hire could embed their own nefarious processor within your design.

In practicality, I think running RISC V on an FPGA would have a very low risk of subversion. Though the FPGA design tools might add nefarious logic too.

Re: Uncorrectable freedom and security issues on x86 platforms (2016)

#82

Want complete software freedom? How about the MIPS chips the Russian military uses[1]? Those don't have an NSA back door. Sucks you can't really buy them as they are only made for use in Russian military and government applications. "Last year, the Russian government announced that it doesn't want to rely on Intel and AMD chips from the U.S. anymore and will focus more on using homegrown chips from Russia." [1] http:…

Those probably have Russian backdoors though.

In most cases, a foreign gov spying on you is harmless.

Re: Uncorrectable freedom and security issues on x86 platforms (2016)

#83

Earlier quoted context omitted.

Those probably have Russian backdoors though.

In most cases, a foreign gov spying on you is harmless.

In most cases a foreign government spying on you is trading their insights with your government in order to sidestep domestic spying restrictions.

Re: Uncorrectable freedom and security issues on x86 platforms (2016)

#84
> These technologies, in turn, are used to implement various forms of remote control and Digital Rights Management (DRM) technologies, including Secure Boot, which even now requires FOSS users to purchase a license from Microsoft to boot FOSS on affected machines that lack an appropriate Secure Boot override.

I dislike the mandatory use of these features as much as the next nerd, but this is inaccurate FUD. Secure Boot is a code in flash that checks the signature of whatever you try to boot against some rather complicated policy. It's regular code and would work more or less the same on any platform that runs machine code off of ROM or flash.

There's something that Intel calls, IIRC, "Verified Boot" that tries to prevent someone with an in-system programmer or desoldering skills from changing the flash, but that has nothing to do with the Management Engine either.

And FOSS users don't need to purchase any license from anyone. They can use a tool like Linux Foundation's PreLoader or Red Hat's shim (open source but awkward to modify because you need the signed binary to boot on a stock system) to boot anything they like. No negotiations, no license, no communication with MS at all.

Re: Uncorrectable freedom and security issues on x86 platforms (2016)

#85
How is this not an anti-trust issue?

Of course the government wants this capability to access anyone's system, so I assume nothing will be done. This has to be one of the worst things that has happened in the history of computing.

EDIT: Handy for CBP use, I imagine.

Re: Uncorrectable freedom and security issues on x86 platforms (2016)

#86
post #85

How is this not an anti-trust issue? Of course the government wants this capability to access anyone's system, so I assume nothing will be done. This has to be one of the worst things that has happened in the history of computing. EDIT: Handy for CBP use, I imagine.

This has nothing to do with anti trust. Selling hardware doesn't require you provide software or the ability to run your desired software.

Re: Uncorrectable freedom and security issues on x86 platforms (2016)

#87
> Major distributions have worked around this issue by purchasing a signing key from Microsoft for their binary packages, but the end user is unable to modify the signed software without a license from Microsoft, even though they have the source code available to them under the GPL.

Is this an accurate description of what is happening? (I don't pay much attention to desktop systems: I spend most of my time concentrating on the ever-worsening mobile arena.) Do these "major distributions" come with a recent version of bash? As someone who develops software under the GPLv3 license, I would not want my software being distributed to these machines via this hack :/.

Re: Uncorrectable freedom and security issues on x86 platforms (2016)

#88

Earlier quoted context omitted.

Those probably have Russian backdoors though.

In most cases, a foreign gov spying on you is harmless.

What are the chances that the access pass from the foreign government to actors you don't want spying on you: criminals or your own government's intel agencies?

Re: Uncorrectable freedom and security issues on x86 platforms (2016)

#89
post #6

The article states the following for RISCV: >"While this architecture is extremely limited in performance, price" Can anyone say thy the performance of RISCV is so lacking?

Nobody has invested the money and work to make it happen.

You can take RISC-V ISA specification or ready Verilog/VHDL and produce working ASIC chip relatively easy, but it's not fast.

If you want fast general purpose chip in that competes toe-to-toe with AMD and INTEL, it will take huge amount of chip and physical design, simulation and verification. AMD has spent tens of millions to get new x86 ISA compatible architecture out. Doing the same for RISC-V without enough demand would be economic suicide.

Re: Uncorrectable freedom and security issues on x86 platforms (2016)

#90
post #87

> Major distributions have worked around this issue by purchasing a signing key from Microsoft for their binary packages, but the end user is unable to modify the signed software without a license from Microsoft, even though they have the source code available to them under the GPL. Is this an accurate description of what is happening? (I don't pay much attention to desktop systems: I spend most of my time concentrat…

> > Major distributions have worked around this issue by purchasing a signing key from Microsoft for their binary packages, but the end user is unable to modify the signed software without a license from Microsoft, even though they have the source code available to them under the GPL.

> Is this an accurate description of what is happening? (I don't pay much attention to desktop systems: I spend most of my time concentrating on the ever-worsening mobile arena.) Do these "major distributions" come with a recent version of bash? As someone who develops software under the GPLv3 license, I would not want my software being distributed to these machines via this hack :/.

It's not entirely accurate. Effectively what most modern distributions do is that they have a "shim" which is signed by Microsoft. That shim then enrols the distribution's own UEFI keys on the laptop. So their kernel is signed with both their own key and Microsoft's key. This means that you can modify your code without "permission" from Microsoft. openSUSE, Fedora and Debian all employ this tactic so that our distributions can boot on newer laptops.

Do I wish this wasn't necessary and that everything ran core boot? Yes. Is there a better way of handling this problem? Not as far as I know.

Post reply on HN