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

201–210 of 282 posts

Re: Freedom and security issues on x86 platforms

#201

Post by duskwuff »

kabdib wrote: post #57
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.

The boot ROMs on these things are proprietary, though. The vendors I've talked with have been extremely coy about what's in them (got an overview from Marvell once, spent a day looking at code on a projector screen and getting a walkthrough. They could have hidden much).

The boot ROM typically gets out of your way pretty quickly, though. At worst it means you have to deal with some firmware-signing nonsense before chaining into a Linux kernel (or U-Boot); it isn't active in a running system.

Re: Freedom and security issues on x86 platforms

#202

Post by xorblurb »

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

IIRC Allwinner does not have public datasheets, and honestly I prefer to have an half-documented half-accessible x86 platform rather than a theoretically fully-accessible ARM one that in practice is 1/10 publicly usable (the cpu alone is not enough to have fun with a platform... especially in the ARM SoC world -- and existing drivers have never replaced a good documentation of the hardware they drive.)

Re: Freedom and security issues on x86 platforms

#203

Post by kbenson »

oldmanjay wrote: post #177
kbenson wrote: post #114

Earlier quoted context omitted.

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.

Well, it's a wiki, so "author" is very loose (and when I checked at the time of my original comment, the change to add some of that verbiage was the most recent change, if still quite old). Ultimately, much of the information on the internet is presented without reference, so tone is the least of our problems. We need to be able to read what is being presented, and decide whether it's important enough to use that we should verify it. In this case, the tone shifts, but the message is along the same lines (the ME is your adversary), if very crudely done.

I do think you have a point though. It's not entirely up to the reader, there is a minimum threshold of clearly communicating facts that needs to be met by the author. But I don't think it's safe to say something that's unclear in tone means it was the expressed intent of the author to cause confusion. Humor can add quite a bit to an argument if done right, as humor often has the ability to cut through some of our preconceptions. Humor done wrong might be confusing, but that could very well be unintentional.

Re: Freedom and security issues on x86 platforms

#204

Post by duskwuff »

kabdib wrote: post #52

Even if the ME was opened, the chips themselves are complex enough that nearly anything could be hidden. State machines that enable backdoors from instruction sequences can be pretty small (triggering these from a preferred vector, such as a web browser, seems hard-ish though).

> triggering these from a preferred vector, such as a web browser, seems hard-ish though

Easier than it used to be, though, especially given modern Javascript JIT compilers. (And that's to say nothing of more direct methods like Chrome Native Client!)

Re: Freedom and security issues on x86 platforms

#205

Post by nradov »

nickpsecurity wrote: post #138
makomk wrote: post #136

Earlier quoted context omitted.

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.

That's one of those sad realities of Worse is Better in action. Definitely a disadvantage. Far as why big-endian was The Right Thing, drfuchs had this to say: "Because big-endian matches how most humans have done it for most of history ("five hundred twenty one" is written "521" or "DXXI", not "125" or "IXXD"). Because the left-most bit in a byte is the high-order bit, so the left-most byte in a word should be the hi…

This issue has been argued incessantly for 40+ years. You should read the famous article "On Holy Wars and a Plea for Peace".

https://www.ietf.org/rfc/ien/ien137.txt

There is no clear "right" answer.

Re: Freedom and security issues on x86 platforms

#206

Post by moefh »

nkurz wrote: post #165
valarauca1 wrote: post #154

Earlier quoted context omitted.

So if API's are copyright-able. And SPARC T1/T2 are GPL CopyLeft. Shouldn't Oracle have to open source T3/T4/T5/M7 processors also? (No I don't have the money required to sue Oracle and keep this suit open for the 2 decades settlement will take).

No, that's not how open-source licensing usually works. Assuming Oracle own all the IP rights (having purchased them from Sun), they aren't bound by the terms of the GPL. The GPL grants certain permissions to others if they comply with its terms, but the person who offers the license doesn't lose any rights they already have. They have no obligation to keep successive generations of derivative products open source.

True, that's even spelled out in the GPL itself (that's from GPL 2, but GPL 3 has similar content in section 9):

> 5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License [...]

The copyright owner obviously doesn't need the license to have permission to modify the code, so they're not bound by it.

Re: Freedom and security issues on x86 platforms

#207

Post by rcxdude »

astrobe_ wrote: post #194
darpa_escapee wrote: post #170

Earlier quoted context omitted.

Lucky. I have to hunt around for DTBs based on modified Rockchip and Freescale SoCs to update my devices. I am unwilling to distribute said binaries to make it easier for people with the same hardware as I to update their 3 year old software. That, too, is a shame.

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.

Re: Freedom and security issues on x86 platforms

#208

Post by Qwertious »

na85 wrote: post #184
nucleardog wrote: post #134

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

"absence of evidence is not evidence of absence"

This isn't true. Absence of evidence is weak evidence of absence, and suggests that it's not the case.

Not disagreeing with anything else in your comment, but that quote completely defies Bayes 101.

Re: Freedom and security issues on x86 platforms

#209

Post by vox_mollis »

hackuser wrote: post #197
vox_mollis wrote: post #196

Earlier quoted context omitted.

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.

> 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. Do you know where I can read more about that? A good, technical, authoritative resource? In my little bit of research, details are sparse and authoritative technical details even more sparse.

Yes, it's tough to find web resources on this. Here is a google books search result:

https://books.google.com/books?id=TEa0yDByYmQC&pg=PT232&lpg=...

I'm mostly taking this on good authority from a friend who works in mobile engineering. So, caveat there.

Re: Freedom and security issues on x86 platforms

#210

Post by geofft »

cwyers wrote: post #175
5ilv3r wrote: post #76

Earlier quoted context omitted.

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.

Yup. I run Debian instead of Gentoo because, for various reasons, I trust the Debian project to be better at things (like triaging, backporting, compiling, and testing security updates promptly and correctly) than I trust myself. I think this is a common decision.

I later extended this logic and bought a Chromebook—a decision I don't take lightly, as a free-software advocate, but I was not convinced that there was an alternative that effectively let me retain more control over my computing. One of the things the Chromebook does that basically nobody else does (systemd vaguely wants to do this, my previous employer wanted to do this for our customers, etc., but I don't think anyone actually does) is it enforces a secure-boot-style thing for the entire OS, and makes it hard for anyone who doesn't have the signing key to take control of my computing away with me. In an ideal world, someone other than Google would have the signing key. But per the logic above, I definitely don't want it to be me.

Post reply on HN