Freedom and security issues on x86 platforms
mail.fsfeurope.org
mail.fsfeurope.org
So, why is SPARC left off in all these analyses? It's right there ready to pick up and deploy. More open, easy to acquire, and trustworthy (far as licensing) than than a POWER chip although slower for sure.
That doesn't make it right to do this, but that'd be my guess.
I certainly didn't know SPARC was open until your comment.
Oracle T4 http://www.oracle.com/us/corporate/features/sparc-t4-announc...
Oracle M6 http://www.oracle.com/us/corporate/features/sparc-m6/index.h...
Oracle M7 https://blogs.oracle.com/rajadurai/entry/sparc_m7_chip_32_co...
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).
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.
> 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.
But the SPARCs you mention have their drawbacks. LEON is not that competetive in the high end (in order single issue, low clock freq) and T1/T2 are only cores (i.e. without interesting "uncore" stuff) and not that good as general purpose "desktop like" CPU.
I have much higher hopes for RISC-V, the community is really booming and the architecture is better than SPARC.
I say this as a former Gaisler employee and SPARC proponent :-)
There's definitely drawbacks. I've just not even seen interest in embedded sector of FOSS for SPARC even with open cores. I wouldn't argue stuff like Leon4 in its current form is suitable for replacing a Core Duo or anything. Yet, that it's suitable for many apps but ignored for all apps by FOSS in favor of proprietary MCU's/CPU's might reveal a problem on their side.
Far as RISC-V, the community is booming and I have high hopes for them. Maybe they'll make something. My recommendation was to create Pi-like board with RISC-V SOC by licensing Leon3 or Leon4, replacing SPARC components with RISC-V, and getting the rest w/out effort. I think we would anyway given it's designed for easy configuration/modification. In parallel, continue developing clean-slate replacements. Gives us a rich, interim product to use with full FOSS down the line. What you think of that idea?
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!
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, to get SOC's working. Slowly crank them out at many universities to eventually arrive at a platform with ASIC-proven components. Then, startups can just do integrations with whatever little part is custom for them. Much cheaper. Also, I think analog academics doing open, cell libraries would be a good idea at 350, 180, 90, 45, and 28nm. As money comes in, can just shrink from one tech to another using pre-existing I.P. or cells. People could probably use Qflow OSS ASIC flow with 350nm (maybe 180nm) without or w/ little commercial tooling.
Always looking for HW people's review on these things. What you think?
Academics also sign NDAs about the processes they use, and can only make certain things available; the most open is probably MOSIS, but that's absolutely no good for advanced nodes.
I'd say throw low power and advanced anything out the window, demonstrate a working chip, then look for funding to advance it.
So, why you say forget about it or MOSIS below 90nm if academics are getting working chips done that low?
If you have a few spare million dollars, you still can't necessarily release a lot of data due to the NDAs - usually they give you models for the processes that are proprietary (and they invested a lot in developing, and so will consider any breach an act of war).
ahh crap..."which are sent to customers upon signature of a Confidentiality and License Agreement"
anyways, prices...hope that helps
Doesn't this context hints to us that 100% security would be much harder than creating some design and manufacturing it using standard fabs?
https://news.ycombinator.com/item?id=10468624
There won't be 100% security because underlying physics fights you and our field is too new. Best we can hope for is making attacks hard and physical. There's great work in secure HW/SW architectures that should knock out about all SW stuff with effort. Details published in all kinds of CompSci publications. HW, too, far as implementing it correctly with some security properties. The rest, esp tamper-resistence, is still in infancy far as having stuff that actually works.
Now, what we're talking about in this thread is having an ISA, chip implementation, firmware, and SW stack that is not a black box and is under your control. Preferably without built-in, convenient spyware. Mainstream FOSS users are currently so far away from this that it's a reasonable, interim goal. So, I had to bring up SPARC as an addition to the list that has side benefit of reducing legal risks.
Or if you're method will work so well, are you sure TSMC/Samsung will even accept you as a customer ?
Because it doesn't seem like something that could scale without the legal/political side and that's really much harder than the tech(which is hard, no doubt).
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 ambitions. Etc.
I think that in the next few decades it will become quite accepted that you choose your platform based on who your perceived "adversary" is. If you're concerned about the NSA, you buy a system that's Chinese from soup to nuts. If you're concerned about the PLA, you buy from a vendor with the US Government seal of approval.
It remains to be seen -- and in truth, I am somewhat pessimistic -- about the availability of a hardware/software ecosystem that doesn't require compromise. 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. ("That's a real nice chip fab you have there. It'd be a shame if something...happened...to it. Maybe you want to reconsider your offer to help us out?")
An open architecture that you could get from any number of vendors, and perhaps use to keep the vendors honest, would be a huge step in the right direction, though. But the underlying problem is extremely hard.
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 Europe, defectors could be detected. Then the manufacturer would have to risk destroying their business by getting caught inserting a backdoor.
PS: two more pdfs for you to digest wrt Soft Machines VISC http://dist.svp-home.org/doc/foundations-and-achievements-of...
http://dist.svp-home.org/doc/operating-systems-for-many-core...
Yeah, it's impressively efficient. Adds more evidence to our argument that SPARC implementations can be technologically competitive in efficiency with ARM, etc.
"AFAIUI this would smell like Soft Machines VISC, only better, because FREE!"
It could happen. Achronix's FPGA's are badass, too, hitting up to 1.5GHz. Their dev boards are actually cheaper than Oracle's SPARC servers, too, with added benefit of putting custom logic for accelerators in there w/ SPARC I.P.. I haven't studied much of VISC, though, so I have little comment there.
I'll comment on those other links later tonight as I'm off to do some more paying work. :)
http://sparc.org/technical-documents/
One embedded implementation with a ton of supporting I.P. is GPL'd, FPGA-proven, ASIC-proven, and rad-hard in some verisons:
http://www.gaisler.com/index.php/downloads/leongrlib?task=vi...
And then there's Oracle, their badass chips, and their evil ass lawyers. We can stay away from all that. SPARC is better and safer than Oracle but very importantly SPARC != Oracle.
Best way to deal with them is to straight-up license their tech for a Pi- or router-style board. Then fab, assemble, and sell that joker. That gets the ecosystem going. CompSci people doing CPU's or RISC-V work can keep building reusable components both can use. Then we just pay for the integrations.
I suppose cathedral vs bazaar doesn't affect that at all, but experience has ingrained in me "source tarball ==> won't easily build" biases.
One could see it coming years in advance. Matter of fact, I fought solutions like that in favor of instrumented, robust coprocessors that did that. They could cost $20-30 more. They could even be in an embedded PCI card that also did I/O offloading, firewalls, and security monitoring with secure RTOS. Many extra benefits to justify extra $20-200 depending on form factor. Yet, people wanted dirt cheap, integrated solution.
They got it...
For ARM, all major OSes I'm aware of use the ARM EABI2. (Note both the Linux kernel and gcc support other ABIs, so there is a real practical choice here.)
For PowerPC, at least all the little-endian 64-bit work for POWER8 has been done targeting the standard ABI. (I have no memory of whether big-endian ABIs for PowerPC follow the standard.)
If you had to pick a Oracle (Sun?) T2 based system to purchase off of ebay, with the interest in using it as a "more free, more open" system, what would you buy ?
What OS would you run on it ?
Sorry, let me clarify ...
Pretend you have three kids. But at the same time you'd like to tinker with a fully open system from loader on up.
Is there an old sun sparc that would make rms happy that I could buy on ebay ?
You could probably get an old Apple PowerPC-based system for considerably less than that, and a LibreBoot-compatible x86 system for even less, but they do exist if you wanted to play around with the architecture.
And they do look pretty cool as well.
[1]: https://en.wikipedia.org/wiki/Sun_Ultra_series
[2]: See eBay item 121411279863, which is a Ultra 45 1x 1.6 GHz SPARC with 2GB RAM and 250GB HDD for almost $2k, asking price. Not sure if that's a realistic ask, but it's what they want for it.
Understood - thank you.
Note that Ultra 45 workstations are extremely slow, much slower than you expect. They were very slow even when they were new. Think Pentium 2 performance.
I was involved in launching an ISP where the whole shebang ran on Sun boxes, and which was over-dimensioned to the point where I once stepped into the data center and found a waist-high box full of E250/E450... Feet. The purple plastic ones you had to remove to rack mount the things.
Two years later we'd shrunk down most of the whole thing (except the storage bits, where SPARC still had good performance) to a few racks of Compaq and Dell boxes that were vastly cheaper to maintain (both because they were cheaper, period, and because we didn't need to wrestle with Solaris and the compilers of the time to get stuff working on them).
This was back in 1999 or so, and I never saw a SPARC system in production after 2005 (until a few months back when I visited a telco customer who still swears by them for a very specific purpose).
I still have one of those plastic feet on my desk at home, as a reminder of the folly of buying single-vendor solutions. It sucks as a paperweight. :)
Guessing it's the entry-level price of US$39,821.00 for Oracle's smallest server?
So, why is it not on the table for... anything in FOSS? Doesn't seem rational. Even a bit hypocritical given vendors like Gaisler and nonprofits like SPARC International have met FOSS halfway or almost wholly. Unlike the others that sue FOSS developers.
Far as power efficiency, kristoffer might be able to chime in as it's not in the data sheets for Gaisler. That's suspicious: either the numbers are bad or they leave it off given its meant for customization. Anyway, the Leon4...
http://www.gaisler.com/index.php/products/processors/leon4?t...
...uses 30,000 gates per core. Same ballpark as ARM and MIPS. Power use should be similar or at least acceptable if comparing ARM, MIPS, and Leon on same ASIC process. They often do rad-hard given it makes it resistant to SEU errors. That takes plenty of extra circuitry. Numbers I have for those, the high end, are 15mW per 1Mhz for Leon3RadHard and for Leon4RadHardQuadCore max was 6watts per one slideshow.
I'll take 6watts consumption in a router in exchange for quad-core, IOMMU-enabled, fault-tolerant, open CPU. What about you? Would 6 watts kill it for you?
Compare things that are alike. If you take a manufacturer (say: TSMC), pick its node (say: 16nm FF+) and you decide on a package (physical manifestation of RTL primitives in the silicon) you get better performance per watt on one architecture over some other. ARM and MIPS are inherently very power efficient. You can't just take SPARC and make it more power efficient than these two. It doesn't work like that.
It's also not true that ISA doesn't matter. ISA impacts bandwidth requirements heavily. This in turn impacts latency and latency hiding, cache requirements and many other things. In fact data transfer is typically as costly as (if not more expensive than) computation. Getting data to all the right places on the schedule eats power like crazy. This is exactly why ARM has Thumb. It's not like internally core does different things than it would do with wide ISA. It's just that stuff's more densely packed, which helps tremendously.
Which brings me to my last point. There's an open architecture that's quite nice. It's SuperH (or SH2 in its open source form), which in turn is what ARM's Thumb is based on. It's not perfect, but it's pretty solid. Omitting it in the OP makes me think author isn't very thorough with his research. But everything has to start somewhere. ;)
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.
The router vendor surely looks at the cost of the CPU - ARM and MIPS cores are probably much cheaper.
Keep guessing.
So, it's mainly the ecosystem with companies and FOSS people wanting to benefit from what's already there instead of improve FOSS HW ecosystems. There's currently, but not indefinitely as you said, a cost advantage for the mass market SOC's as well for PPC, ARM, MIPS, and possibly SuperH.
$4 per 100 units (4 pennies each), or $4 per unit in quantity of 100?
Some things like GDT, or lack of a hardware discovery that are anyoying.
Anyone here worked with this?
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 ME system rely on a couple of proprietary third party code, that has on contract with Intel explicit prohibitions of Intel ever letting anyone seeing their source, or the keys needed to sign them.
Also, Intel ME can't be really trusted, the code is not really "reverse-engineeringable", and it works as a full second OS of sorts, it even has its own JVM running, if someone somehow decide to inject spy software into it, you will never know, also I assume that the first destructive virus to latch into that stuff, will take the world truly by surprise depending on when it triggers (for example if it spreads silently but triggers the destructive payload on a specific date).
Also, these features can be abused to abuse the market itself, for example by intentionally making the hardware underperform, and then sell "superior" hardware that has the only difference some software.
I'm supposed to believe this technology is dangerous. But the advocates are children.
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.
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.
If you were to do such a thing, you'd do it by making the machine overclock itself too much occasionally (after the 'artificial use-by date' has passed, thereby incurring physical damage at random intervals. Although really, it would be easy to do without blob, too, if you're doing the design of the physical chip.
"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."
Over the past few years, Apple's done a lot of work in making the same system APIs available across multiple processor architectures; at a base level, iOS and OS X have very similar cores. You can see this with the ease of the transition from ARMv7 to ARMv8, which in most cases just required a new compilation.
As general-purpose applications have been migrated to higher-level APIs, the difficulty of porting those applications to a new processor architecture decreases; if an application is Cocoa-based and compiled for x64, then if those Cocoa APIs are available on an ARMv8 platform, they can be compiled natively for that platform.
I would expect that they have already been building OS X for ARM internally for several years, and that they'd prefer to avoid switching again but would certainly do it if they ever felt like the use of Intel's architecture was creating a problem for their business.
Sidetracking this conversation a little, but I'm more and more wondering whether MS actually has a retrocompatibility track record that is that good, or if it is just a nice story. Granted, they communicate a lot on how hard they work on that subject, and they even have a guy who blogs about that and about how great he is because he injects patches in third parties programs to let them work on new OS versions, but the end result is just... random. -- Well, maybe that guy should work on compat between MS products before those of others...
First no medium/big company would think of upgrading the OS without months or even years of studies and tries -- they likely could do and already are doing the same with OS X, then MS actually actively deprecate a lot of stuff all the time (and even whole subarchs, like Win16 not avail on Win64 installs), they also have so much tech and product birth fail it is not even funny anymore, and finally even when they don't mean to, their very own products in more or less the same line are often broken by next versions supposed to be able to install side-by-side or even just patches (example: Windows SDK 7.1, which is upset if you try to install it with anything else than the .NET 4 RTM preinstalled, and then is very upset again during builds if you upgrade your .NET to 4.6 -- or on a completely different subject compat of recent Words with old .doc which is not stellar)
And finally on the technical design side, some choices are just plain complete crap and stupid. Why would you, I don't know, leverage UMDF (that is especially well suited for USB drivers, for example) to allow 32 bits drivers to run on 64 bits Windows when you can just not give a fuck and force people to use their old consumer or dedicated pro hardware with their old computer, and let them throw everything in the trash when it eventually fails. I mean, during the 16 -> 32 bits transition they actually made far more insane things working (at least kind of working) while here everything would be neatly isolated yet they manage to... not even attempt to do it.
I'll not even begin to talk about the .dll story, which is just even more complicated each time they try to fix it because you still have to support the old methods, sometime by some kind of virtualisation. And then, like I said, they just decide to change their mind and use the old replacement method again, (ex: the .NET 4 => 4.5/4.6 mess explained before) which breaks again because they are still not THAT good at backward compat. (In a cringeful way: have anybody heard about symbol versioning?)
So maybe Apple is doing worse (I don't know much about them), but on a Linux system you can actually administer it carefully if you are skilled enough to make any random old application crap REALLY work on a modern install (you might need to duplicate a complete userspace to do that, but not all the time thanks to symbol versioning, and it is not necessarily huge when you do, and at least you can).
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.
I would not call that giving up on performance...they just designed something for a purpose and it fits that purpose well.
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 platform security is also a push for platform ownership. Tinkering/hacking/your ability as a hardware owner is at ends with corporate security needs and that is a shame.
You are right about ARM though, TrustZone is another DRM-oriented aspect of ARM-based SoCs.
There was a talk at FOSDEM this year about using TrustZone to run a small hypervisor: https://fosdem.org/2016/schedule/event/microkernels_genode_u...
It's equally as incoherent to say supervisor mode and the MMU is 'DRM-oriented'.
The external hdmi doesn't really work properly...I remember not being able to run external monitor in full screen, or at the same time as the lcd screen.
I just installed and ran glxgears. It gets 250 FPS and a default window size. But I do get an command line error libGL error: unable to load driver: rockchip_dri.so, so I don't think I'm getting GPU.
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.
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...)
What x86 Chromebooks do is they allow that region to be writeable but then zero that region on every boot. If your ME was backdoored, it was shipped that way from the factory.
It's so disappointing that Intel undermined the entire trusted computing stack for some unproven ideas of around ME revenue generating opportunities.
http://blog.invisiblethings.org/2015/12/23/state_harmful.htm...
It feels like the sort of opportune market that server operating systems, databases and web servers occupied: less of a visual aesthetic and more of a better-design-wins market.
It's not going to be easy - I'd guess that it would take at least 10 years for a project to get any sort of traction outside of a very small niche group.
On their FAQ page: https://libreboot.org/faq , you can see the question "Why is the latest{Intel,AMD} hw unsupported?"
They go into more detail than the provided link. Also, dropped supports starts in 2008 for Intel, 2013 for amd.
The truth is: we need something like this to protect the whole boot process. But unless we can put our keys/sw in there, we will never be sure.
Honestly, his talk on the state of the project was very bitter. He literally said that there is absolutely no hope that LibreBoot will ever be able to cope with ME, and that the fight is over since 2008.
As much as I would absolutely love to be able to run a free firmware, unless there is a major change/outsider in the hardware manufacturer world, it seems very unlikely that it will be possible on current x86 architectures.
https://www.broadcom.com/docs/support/videocore/VideoCoreIV-...
Few if any of them have "enterprise" grade quality IMO. The ones that strive for this (HP Moonshot, e.g.) are significantly more expensive than $50-100.
Note that the topic at hand is binary blobs and trust and Pi and other ARM SoC fall short there.
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 just failed to notice that our computers are sending video traffic to the NSA without our noticing it?
I can imagine this happening on phones, where the baseband chip is much harder to actually sniff. But through my LAN? I doubt that.
2) Let's imagine that this post is entirely true. Why do Intel and AMD do this? If it's not part of a grand conspiracy, then why? Clearly there are far easier and cheaper ways to achieve what they view as security that don't require such a crippling approach. What's the upside to them?
Any keyboard event generates some kind of interrupt on x86, right ? Suppose this "ME" happens to record the last 64k keystrokes into a rolling buffer. Furthermore, suppose there is a very, very particular sequence of instructions that can be sent to retrieve this rolling buffer ? Boom. No more encryption (at least none that requires typing a key in from the kb).
Oh, you use binary keys ? Cool, intel has special x86 instructions for doing AES. I'm sure they wouldn't do anything like copy the, oh...KEYS, into the hypothetical rolling buffer, would they ? No, that would be "dishonest", and we all know everyone who makes computer hardware and software would never think of doing something so egregiously deceitful, don't we ?
And of course, if you block the obvious exfiltration methods, all you do is force the attacker to do something more creative. Like modulating inter-packet timings, or even sending data to a nearby radio receiver by using the system bus as an antenna.
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 guarantee, but somewhere along the line someone probably would have noticed something if these systems were exfiltrating data via the network using something like IPv4 headers. Specifically, a quick look makes it look like Snort (an open source NIDS) may actually be distributed with rules to alert on IPv4 reserved bits being set.
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.
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.
If the code says "phone home if anywhere on the screen you see one of the following email addresses" then it won't show up in a normal security audit, unless you email one of those people during the audit. All the NSA has to do is make the phoning home rare enough that it's probabilisticly unlikely to be observed.
https://events.ccc.de/congress/2013/Fahrplan/events/5380.htm...
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 privileges on nearly any PC and game console in the world.
Nobody noticed the bad heartbeat packets being sent to openssl for a long time.
Obviously that's not what would be sent. A keylogger would be far more likely.
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.
That's generally a bad trade. Sadly one that many people are willing to make until it bites them.
It would be a lot better if secure mode had its own supervisor mode that worked through a master key that could be installed at boot time.
If you take on premise that the PC is not safe and under your control, but is instead hostile and compromised, basically an outpost of the Internet in your house, then SGX and similar start to make sense. For many people, their computer is always going to be hostile; it was never "theirs" to begin with, so SGX doesn't really cost them anything, and the ability to let a single application basically force its way down to the hardware and elbow everything else in the stack out of the way is an improvement over having to trust the OS, browser, etc.
In a way it represents an abject failure on the part of the dominant OS developer (Microsoft) to produce a consumer computing platform that the average user can trust, as well as the failure of most other alternatives (e.g. DoD-style smartcards) to take off in the consumer market.
There is no need to give up freedoms for that security.
Only when DRM comes into play you can really explain why the user is not in control here.
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.
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 computing), SGX offers the user more security, and a degree of protection against some cloud computing risks.
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.
One approach would be to build some honeypots likely to attract attention. Give them a job that's not too traffic intensive but is suspicious, such as encrypted IRC. Record all traffic in and out of the box using external hardware. Get them fake encrypted traffic from suspicious sources (Tor, strange sites in suspicious countries, etc.) Wait for strange packets to show up that are not meaningful to the host software but cause something to happen on the target.
Still, I agree. I have a 2008 netbook at home I still use regularly, and I hardly throw away a computer that still basically works.
We lose when we give up, I suppose. I know what the Libreboot guy said before on his blog, alluded to here, but this is why, as crusty as some might find him, we most generally support Stallman's politics.
On the other hand, if entertainment computers, such as blu-ray players or gaming consoles are locked-down and full of DRM, then I don't see a big problem. Sure, the government could potentially ban some movies in the future, and require the manufacturers to update the firmware on your machine so that it will no longer play those movies. But movies and games are expensive to produce, and without DRM most of them probably wouldn't get produced in the first place. In any case, movies and games aren't really that important, compared to say books and articles.
The FSF seems to be against DRM EVERYWHERE! They don't seem to realize that DRM might actually be a good thing for some things. Are there any organizations out there that I could donate to, that fight/work for open hardware for general purpose computers, without trying to prevent locked-down entertainment computers?
At the end of the day, I want a hardliner in this space pushing that line because I know, practically, he cannot win. But if consensus is drawn between him and the other extremes I find distasteful, I want him to pull the resolutions and positions as far left as possible, even if that is slightly left of center.
I worry, as current events show, anything less means that counter-forces to the free software movement will wear you down with abject greed by slowly going right of center and taking as much time as it takes to restore the balance back to their proprietary interests after the initial battle has gone to free software advocates. And that is how I see it. Very few of my friends understand the value of highly technical manuals, and that is what open source is about. My brother recently saw my side with automative hacking and experimentation countermeasures on the rise, as reported today on HN. But when I tell non-technical people these manufacturers hide secrets in their faulty designs and let you pay for their ineptitude, even if you want to fix it for yourself on your individual unit without harm or influence on them, they do not get the argument and ask why I think I know better than the compant. They only get the argument when they are locked out of a system they need for their very personal context.
Oh well. This is a very personal choice. I love GPL, I love MIT, and I smile when I think how all these hippies made a world for me in the 60s and 70s I could not live without today.
I wonder if this greed will be profitable for them in the long run? Obviously, most people don't care whether their hardware is open or not. However, a tiny minority of (very) computer literate users do care (a lot). Will it have any impact if this tiny minority abandons the x86 platform?
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].
I recall that some independent company was contracted to audit the entropy generator in VIA C7 but I can't find it now.
"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 high-order byte. Because ordering two 8-character ascii strings can be done with a single 8-byte integer compare instruction (with the obvious generalizations). Because looking for 0x12345678 in a hex dump (visually or with an automatic tool) isn't a maddening task. Because manipulating 1-bit-per-pixel image data and frame buffers (shifting left and right, particularly) doesn't lead to despair. Because that's how any right-thinking person's brain works."
https://www.ietf.org/rfc/ien/ien137.txt
There is no clear "right" answer.
ME is very, very different - it transparently has access to everything.
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.
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.
http://www.androidauthority.com/paranoid-android-calling-it-...
https://redmine.replicant.us/projects/replicant/wiki/Replica...
http://blog.invisiblethings.org/2015/10/27/x86_harmful.html http://blog.invisiblethings.org/2015/12/23/state_harmful.htm...
https://www.youtube.com/watch?v=4kCICUPc9_8
May be also be interesting to others wanting further information.
Towards the higher end, ARM can't hope to field anything in that timeline to compete with even todays i5 or i7s (or corresponding Xeons). Some people do use this kind of CPU power.
I don't think the switch would present a significant problem in marketing or for developers, so it would purely be a question of having the chips that fit the products. The Macbook, as you point out, is basically already there.
> MIPS is often overlooked. However, China has revived this architecture for general purpose computing with the Loongson core...
Baikal-T1 [0] is another interesting MIPS processor that I'd like to play with (or maybe even use).
Now release a bunch of png, jpg, and mp4 media on the internet with the low order bits set to match.
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!)
Yes, I realize you could get around this. The superblob could be a) looking for patterns in JPGs for input, and b) stenographically encoding output into...anything the user is doing.
Sigh. Nevermind.
I don't know who to reach out to at Intel on that suggestion though.
https://www.reddit.com/r/ReverseEngineering/comments/3pwxjn/...
On the other hand, it still is probably possible to prevent a computers unrestricted access to the internet. For now at least.
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...
That's pretty cool. This combined with some benchmarks I saw for server workload on POWER8 will hopefully revive some interest in the platform.
What "appropriate" Secure Boot overrides are available?
2) 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.
Other parts of the posting imply that we have no idea what the software does, but thhe statement above says we have the source code. What am I misunderstanding?
1b) nuke the platform signing key and replace it with your own (iff the vendor lets you)
2) You're mixing things up. "We have no idea what the software does" refers to the hardware management code, which can run a full OS stack. But that quote refers to the tivoization "feature" of Secure Boot: you can recompile your software, but not run it on the hardware, because you lack the signing keys to make the machine trust your code. But, see 1)
I deliberately did not set BIOS password so that the laptop remained usable to whomever got their hands on it.
Nope.
https://mjg59.dreamwidth.org/20303.html
No additional money has to change hands between anyone, and no additional permission needs to be granted from Microsoft to anyone. (You have to get the permission of someone with physical access to the machine during boot, but if your goal here was FOSS users controlling their own computing, it's a good thing that that permission is required.)
Which happens to be a case if you want to use a extension card with its own BIOS. If it is signed, what key is used? Can you resign with your own?
I'm not sure about the implementations and real-world situation, but as far as I get it, with X.509 with Secure Boot generally uses, one should be able put the exact card's vendor certificate (not MS CA root one) to trust the extension card. (Sadly, I think there's no way to trust one specific signature.) I guess that's probably very non-trivial in practice.
At worst, one should be able to put their own CA (to sign their own software) and be forced to add MS CA to trust the third-party software as well. But - if UEFI implementation allows user-defined CAs - it should be possible to run your own code without asking Microsoft's permission.
On desktops and laptops I've seen, there was a way for end-user to upload their own trusted certificates and use those instead of Microsoft ones, and I think that's when done like this (when, whatever the defaults are, end-user can get in control), Secure Boot is a good idea - even though the implementations are not.
I guess there must be some ignorant (or malicious) desktop/laptop vendors that don't provide key management options, but hope there isn't many.
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.
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.