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

251–260 of 282 posts

Re: Freedom and security issues on x86 platforms

#251

Post by grumble1234 »

em3rgent0rdr wrote: post #63
darpa_escapee wrote: post #8

ARM architectures also suffer from this. You'll be hard pressed to find a board that doesn't require a propriety board support package somewhere in the stack. Ironically, it is usually the bootloader that is/requires a blob or it is the DTB. I remember being in middle school and reading Stallman's articles on the dangers of a TPM-oriented push by manufacturers. As cliche as it is, Stallman was right. The push for pla…

I'm using ASUS C201 which uses ARM. It was a Chromebook, now running libreboot and parabola linux.

so jealous... I've tried to replicate that setup on my C201 but kept hitting issues. I might give it another shot some day soon. Does Libreboot make it easier to boot from SD/USB?

Re: Freedom and security issues on x86 platforms

#252

Post by brokenmachine »

zvrba wrote: post #249

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.

Can you give more details on what OS and tracking SW you were using?

Re: Freedom and security issues on x86 platforms

#253

Post by ashitlerferad »

makomk wrote: post #62
darpa_escapee wrote: post #8

ARM architectures also suffer from this. You'll be hard pressed to find a board that doesn't require a propriety board support package somewhere in the stack. Ironically, it is usually the bootloader that is/requires a blob or it is the DTB. I remember being in middle school and reading Stallman's articles on the dangers of a TPM-oriented push by manufacturers. As cliche as it is, Stallman was right. The push for pla…

Most Allwinner chips can run an entirely open-source stack and there's quite a few hobbyist-oriented boards out there based on them. (Technically the ROM bootloader is closed source, but all it does is load your choice of bootloader into RAM and execute it. After that you have full control, including the ability to run code in TrustZone mode and on the supervisor CPU core if one exists.)

Security issues in ROM are still security issues. Even if it is in ROM, it still needs to be auditable.

Re: Freedom and security issues on x86 platforms

#254

Post by ashitlerferad »

ctz wrote: post #29
ashitlerferad wrote: post #10

Earlier quoted context omitted.

There are plenty of boards that run using mainline u-boot and mainline Linux, you can often ignore the vendor BSP. You are right about ARM though, TrustZone is another DRM-oriented aspect of ARM-based SoCs.

TrustZone is just another processor mode and associated memory protection, nothing more, nothing less. It's equally as incoherent to say supervisor mode and the MMU is 'DRM-oriented'.

In practice, TrustZone is for DRM.

Re: Freedom and security issues on x86 platforms

#255

Post by ashitlerferad »

vox_mollis wrote: post #196
hackuser wrote: post #36

This sounds similar to basebands on cellular devices: Subsystems controlled by the vendor, not accessible from the 'user' system, remotely updatable and with access to everything.

Except modern baseband processors usually don't have direct access to main memory or peripherals - they are usually linked to the rest of the phone via a serial bus. ME is very, very different - it transparently has access to everything.

serial attached basebands are much rarer than basebands with full or partial control of the CPU or RAM.

Re: Freedom and security issues on x86 platforms

#256

Post by voltagex_ »

rcxdude wrote: post #207
astrobe_ wrote: post #194

Earlier quoted context omitted.

So it's not an "ARM architectures" issue. It's a problem between you and your provider, who for some reason is not willing to provide the DTS. That said, given that DTB/DTS is an open spec, tools to reverse a DTB into a DTS should probably exist (like this one: http://forum.xda-developers.com/android/software-hacking/how... )

You don't even need a secondary tool. The standard devicetree compiler, dtc, can convert a dtb back into a dts no problem. The dtb format is a pretty basic serialisation of the dts file, so fairly little information is lost (mainly pre-processor stuff like includes and some macros for constants) and you can easily round-trip.

On some boards, the dtb controls things like voltage to the eMMC, so getting it wrong can be catastrophic.

Re: Freedom and security issues on x86 platforms

#257

Post by zvrba »

brokenmachine wrote: post #252
zvrba wrote: post #249

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.

Can you give more details on what OS and tracking SW you were using?

Absolute LoJack, with windows. It installs itself as a windows driver before/during the boot. It sends location once a day, or more often if you flag the device as stolen/missing. It can also remotely "brick" the device (yes, it can be undone by the owner) if the data is of concern.

I deliberately did not set BIOS password so that the laptop remained usable to whomever got their hands on it.

Re: Freedom and security issues on x86 platforms

#258

Post by jestar_jokin »

albinofrenchy wrote: post #173
Retr0spectrum wrote: post #142

Earlier quoted context omitted.

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.

Java has precedent for running on low-performing devices; see J2ME[0], which ran on a whole bunch of old mobile phones, and Java Card[1], which ran on smart cards.

https://en.wikipedia.org/wiki/Java_Platform,_Micro_Edition

https://en.wikipedia.org/wiki/Java_Card

Re: Freedom and security issues on x86 platforms

#259

Post by MichaelGG »

nullc wrote: post #250
MichaelGG wrote: post #139

Earlier quoted context omitted.

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

What's their justification? I've heard that too, but it sounds too stupid to be true. "Here's an amazing feature built in to all our CPUs. Except you can't use it."

Re: Freedom and security issues on x86 platforms

#260

Post by puzzlingcaptcha »

PeCaN wrote: post #105
forty wrote: post #25

What about VIA x86 CPUs? http://www.viatech.com/en/silicon/processors/ Do they implement some "secure boot"-like features?

To the best of my knowledge, VIA CPUs have no secure boot, management engine, or any other proprietary secondary hardware. Coreboot supports many VIA CPUs and motherboards[1], though it's unclear if it uses any binary blobs the FSF seems alright with VIA Technologies and apparently they're cooperative with open-source BIOS[2]. 1. https://www.coreboot.org/Supported_Motherboards 2. https://www.fsf.org/campaigns/support…

VIA CPUs do have a crypto engine called Padlock (with all the usual goodies plus a randomness generator) which is not 'open' so be careful with that.

I recall that some independent company was contracted to audit the entropy generator in VIA C7 but I can't find it now.

Post reply on HN