Shuttleworth Wants To Get Rid of Proprietary Firmware

← Back to Stories (view on slashdot.org)

Shuttleworth Wants To Get Rid of Proprietary Firmware

Posted by samzenpus on Monday March 17, 2014 @06:39AM from the change-your-ways dept.

jones_supa writes "In a new blog post, the Ubuntu main man Mark Shuttleworth calls for an end to proprietary firmwares such as ACPI. His reasoning is that running any firmware code on your phone, tablet, PC, TV, wifi router, washing machine, server, or the server running the cloud your SAAS app is running on, is a threat vector against you, and NSA's best friend. 'Arguing for ACPI on your next-generation device is arguing for a trojan horse of monumental proportions to be installed in your living room and in your data center. I've been to Troy, there is not much left.' As better solutions, Shuttleworth suggests delivering your innovative code directly to the upstream kernel, or using declarative firmware that describes hardware linkages and dependencies but doesn't include executable code."

93 of 147 comments (clear)

Min score:

Reason:

Sort:

Precisely how... by msobkow · 2014-03-17 06:43 · Score: 1

Precisely how does he intend that a machine boot to the install media without executable firmware?
Or is he a proponent of the "disposable machine" -- once infected, you *have* to replace it, because you can't *reinstall*?

--
I do not fail; I succeed at finding out what does not work.
1. Re:Precisely how... by jones_supa · 2014-03-17 06:45 · Score: 3, Insightful
  
  Getting rid of ACPI sounds also like a "good luck with that" plan.
2. Re:Precisely how... by TechyImmigrant · 2014-03-17 06:56 · Score: 5, Insightful
  
  I design hardware. I could wait for someone to accept my changes into the Linux Kernel before I start testing it, or I could write some firmware accessible through ACPI.
  What Shutters wants is irrelevant. What he needs is open interface specifications to the hardware.
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
3. Re:Precisely how... by Anonymous Coward · 2014-03-17 06:58 · Score: 5, Informative
  
  Firmware is just fine, as long as it's non-proprietary--free as in freedom.
4. Re:Precisely how... by jones_supa · 2014-03-17 06:58 · Score: 2
  
  ACPI WMI specs from the HW makers would be nice. It's frustrating how many laptops have broken hotkeys under Linux.
5. Re:Precisely how... by SuricouRaven · 2014-03-17 07:00 · Score: 1
  
  DIL socket. Add your own firmware chip.
6. Re:Precisely how... by fuzzyfuzzyfungus · 2014-03-17 07:01 · Score: 1
  
  Getting rid of ACPI sounds also like a "good luck with that" plan.
  If anything, insufferably shitty firmware has been steadily bloating to the point where we should probably start including it in operating system marketshare charts...
7. Re:Precisely how... by amorsen · 2014-03-17 07:04 · Score: 4, Informative
  
  Precisely how does he intend that a machine boot to the install media without executable firmware?
  He does not complain about executable, he complains about proprietary.
  Besides, ACPI is complete overkill for booting.
  
  --
  Finally! A year of moderation! Ready for 2019?
8. Re:Precisely how... by fuzzyfuzzyfungus · 2014-03-17 07:07 · Score: 2
  
  ACPI WMI specs from the HW makers would be nice. It's frustrating how many laptops have broken hotkeys under Linux.
  If we are currently at the point where you can't even get the details of what the Windows Management Instrumentation blobs embedded in the motherboard firmware mean, that might be another reason why somebody running a Linux company might dislike ACPI...
  
  As long as (through some mixture of overt standard-setting to that effect, and basic 'you actually think that we are going to keep testing our BIOS once it boots Windows? That means that it's ready to ship!' OEM engineering) proprietary firmware is basically the lowest level of Windows drivers, writing other OSes on top of it just isn't going to be a pleasant experience.
9. Re:Precisely how... by PopeRatzo · 2014-03-17 07:16 · Score: 2
  
  What he needs is open interface specifications to the hardware.
  That. Absolutely.
  Shuttleworth may be slightly off the mark, but his dislike for proprietary firmware is worth supporting, given what we're learning daily about what people who mean us no good are doing with our consumer electronics.
  
  --
  You are welcome on my lawn.
10. Re:Precisely how... by msobkow · 2014-03-17 07:20 · Score: 1
  
  So you can't power off the machine while it's booting?
  Give your head a shake.
  
  --
  I do not fail; I succeed at finding out what does not work.
11. Re:Precisely how... by Lumpy · 2014-03-17 07:21 · Score: 1
  
  and he will NEVER get it.
  Hell you cant get open microcode on the freaking processors.
  Shuttleworth is starting to become a little nutty.
  
  --
  Do not look at laser with remaining good eye.
12. Re:Precisely how... by msobkow · 2014-03-17 07:22 · Score: 1
  
  Then again, I have to hold down the power switch until it takes effect while booting, so maybe ACPI isn't involved and it's me that needs to give their head a shake.
  Anyone know for sure?
  
  --
  I do not fail; I succeed at finding out what does not work.
13. Re:Precisely how... by Lumpy · 2014-03-17 07:22 · Score: 1
  
  Yuck QFP is a lot better far better pin density and easier to insert or remove safely.
  
  --
  Do not look at laser with remaining good eye.
14. Re:Precisely how... by Anonymous Coward · 2014-03-17 07:27 · Score: 1
  
  Point totally MISSED! The firmware running in the bios should be OPEN SOURCE - as in Coreboot. Modern PCs today don't NEED the bios of old as the hardware drivers get replaced anyway - with more open source.
  Furthermore, the whole UEFI fiasco could have been eliminated if we had a simple SWITCH on a pc to ALLOW writing to flash only when the user decides to update the bios - and I'm talking about a switch connected to the VLSI flash controller that can not be circumvented by software. A whole lot cheaper.
  Open Source 100%.
15. Re:Precisely how... by queazocotal · 2014-03-17 07:27 · Score: 1
  
  It is.
  It's one of the primary means that the kernel (of whatever OS) works out what hardware it's actually running on, and what it should setup.
  ACPI, PCI* configuration registers, and friends are all pretty much required in order to boot a random system successfully.
16. Re:Precisely how... by Anonymous Coward · 2014-03-17 07:28 · Score: 1
  
  "I could wait for someone to accept my changes into the Linux Kernel before I start testing it"
  How's that? If you propose your changes to be accepted to Linux, you should already have tested it, and I guess that's how it generally works right now?
17. Re:Precisely how... by blackiner · 2014-03-17 07:28 · Score: 2
  
  Isn't device tree pretty much declarative firmware? It has gained quite a bit of ground in the ARM on Linux world recently too. Seems like the solution already exists, it just need a bigger push.
18. Re:Precisely how... by amorsen · 2014-03-17 07:32 · Score: 1
  
  queazocotal has it right. ACPI prepares the hardware and tells the kernel where to find it.
  Of course on recent hardware EFI is taking over part of that. EFI is significantly more bloated than traditional ACPI BIOS.
  
  --
  Finally! A year of moderation! Ready for 2019?
19. Re:Precisely how... by jones_supa · 2014-03-17 07:33 · Score: 1
  
  Yes, it could be one solution.
20. Re:Precisely how... by sjames · 2014-03-17 07:37 · Score: 3, Informative
  
  He's talking about ACPI. That is, firmware that the kernel is expected to trust and run in it's own context after being loaded. That is quite distinct from bootstrap firmware that is expected to load and jump into the bootloader and then be inactive until the next boot.
  BTW, much of it is actually broken in various ways.
21. Re:Precisely how... by Florian+Weimer · 2014-03-17 07:47 · Score: 1
  
  The reference implementation of UEFI is open source, and some vendors use it as a basis for their firmware.
  Unfortunately, most Coreboot-using devices are tied down and do not allow non-interactive booting with custom firmware (if they allow custom firmware at all).
22. Re:Precisely how... by LoRdTAW · 2014-03-17 08:06 · Score: 2
  
  I think you mean PLCC. It can be soldered directly to a board or socketed. And in the recent past it was the choice for socketing BIOS chips after DIP32 fell out of favor. QFP is quad flat pack which is always directly soldered to the board and not easily removed. I never seen a QFP socket outside of test fixtures.
  With the high density of todays boards, even PLCC is gigantic in terms of footprint so many have moved to smaller SMT packages. I have seen Intel motherboards using 8 pin SOIC chips, most likely on an I2C or SPI bus. You can buy sockets for them but no mainstream motherboard maker sockets them.
23. Re:Precisely how... by Anonymous Coward · 2014-03-17 08:16 · Score: 1
  
  I design hardware. I could wait for someone to accept my changes into the Linux Kernel before I start testing it, or I could write some firmware accessible through ACPI.
  Or; you could write a FOSS module interlinked with ACPI to coreboot and then everything would be free and you would have the ACPI you wanted. You would probably even find that the community would fix the bugs in the software you wrote for free and you would sell extra hardware.
  The thing is, that we want the full source to every bit. Anything less and the security risk is just too great.
24. Re:Precisely how... by drinkypoo · 2014-03-17 08:39 · Score: 1
  
  What Shutters wants is irrelevant. What he needs is open interface specifications to the hardware.
  One might reasonably argue that what one needs is the source to the firmware and the tools needed to apply it to the device. One's rebuttal might involve cost, but not "you don't need that".
  
  --
  "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
25. Re:Precisely how... by TechyImmigrant · 2014-03-17 08:42 · Score: 5, Interesting
  
  I'm talking about the device not the kernel.
  I can compile up my own kernel and test my device against it. But I can't go and deploy my device on the myriad computer/OS configurations out there if I need stuff compiled into the kernel. ACPI solves a problem. If your solution that replaces ACPI doesn't solve the problem ACPI solves while also solving the trojan-via-firmware problem, then it's useless. ACPI is horrible, and I'm all for replacing it with something better but I'm not seeing a proposal that does both.
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
26. Re:Precisely how... by dargaud · 2014-03-17 08:43 · Score: 1
  
  Besides, ACPI is complete overkill for booting.
  Agree. I've written bootloader code and kernel drivers. All the bootloader really has to do is get the kernel in memory somehow and jump to it. Why can't you boot directly into the kernel you ask ? One reason is size; on many (embedded) systems, there are only a few Kb available for an executable on boot. The other is that the bootloader doesn't not change easily (it needs reflashing or is in some kind of ROM), allowing you to easily change the kernel.
  
  --
  Non-Linux Penguins ?
27. Re:Precisely how... by mspohr · 2014-03-17 08:54 · Score: 1
  
  He said "get rid of proprietary firmware".
  He didn't say get rid of all firmware.
  There is a difference.
  Open source firmware can be audited to see if the spooks are getting their hands on your data... not so with the proprietary stuff.
  
  --
  I don't read your sig. Why are you reading mine?
28. Re:Precisely how... by mspohr · 2014-03-17 08:56 · Score: 1
  
  He didn't say get rid of ACPI.
  He said get rid of proprietary firmware.
  You can have an open source ACPI (https://acpica.org/downloads) which you can audit to find the NSA evil bits.
  
  --
  I don't read your sig. Why are you reading mine?
29. Re:Precisely how... by mspohr · 2014-03-17 09:01 · Score: 2
  
  "What Shutters wants is irrelevant. What he needs is open interface specifications to the hardware."
  I think that's what he wants:
  "Declarative firmware that describes hardware linkages and dependencies but doesn’t include executable code is the best chance we have of real bottom-up security. The Linux device tree is a very good starting point."
  
  --
  I don't read your sig. Why are you reading mine?
30. Re:Precisely how... by tlhIngan · 2014-03-17 09:38 · Score: 2
  
  Besides, ACPI is complete overkill for booting.
  Agree. I've written bootloader code and kernel drivers. All the bootloader really has to do is get the kernel in memory somehow and jump to it. Why can't you boot directly into the kernel you ask ? One reason is size; on many (embedded) systems, there are only a few Kb available for an executable on boot. The other is that the bootloader doesn't not change easily (it needs reflashing or is in some kind of ROM), allowing you to easily change the kernel.
  ACPI is not just used for booting, it's used for controlling the customizations between systems. While the PC architecture has changed little in the way of memory maps since the 1980s, there are still things that various computer manufacturers do that no OS could ever program for.
  For example, PCI interrupt routing was completely up to the manufacturer in routing which IRQ when to which PCI IRQ. They were normally scrambled so you don't have all the cards using one IRQ line, but that information needs to be communicated between the BIOS and the kernel, otherwise the kernel has no way to handle PCI interrupts properly.
  You could define a data structure (which is what ACPI does), or you could program into the kernel every variation around for every motherboard, and hope that every mobo manufacturer out there updates the list and submits the patch.
  The other thing is, well, ACPI handles rebooting, shutdowns and suspend/resume. It tells you how to poke the hardware in various ways to accomplish the goal. It isolates the difference between hardware to the people who know it best - the hardware guys.
  Some of these things may be GPIO pins that change for routing convenience (to enable/disable wireless, for example, or for various status LEDs), power switches that control how the regulators operate, other settings and controls for various voltage rails and such.
  Every PC is not the same, each manufacturer might choose a different power regulator IC that requires different programming to turn it on and off, and ACPI is best to handle it. otherwise the kernel will have to have each and every variation in it programmed in.
31. Re:Precisely how... by nateman1352 · 2014-03-17 09:47 · Score: 3, Informative
  
  Honestly Shuttleworth's reasoning "Binary blobs can contain NSA exploits" is completely irrelevant to ACPI since ACPI byte-code can be completely de-compiled back in to the original source language making it very easy for security researchers to detect any funny business.
  Honestly the modern PC has several microcontrollers in it that contain code that the primary CPU never even sees. I personally would consider those a much bigger security threat than ACPI.
  So lets ask ourselves... why does he really want to get rid of ACPI? The answer is pretty simple, it going to take a lot of coding effort to get the Linux ACPI stack ready to fully support ACPI 5.0 and Connected Standby found on a lot of brand new laptops. This is just a feeble attempt to mask the fact that puring all his resources in dumb projects like Mir and Unity doesn't leave much left to keep up to date on new open PC platform standards.
32. Re:Precisely how... by amorsen · 2014-03-17 11:01 · Score: 1
  
  I do not think that anyone has a problem with interrupt routing tables or ACPI documenting how hardware should be poked. It could be laid out a little simpler perhaps, but that is mostly bikeshedding.
  One of the problems is that ACPI suddenly yanks the CPU out from under you and executes its own proprietary code, and the kernel or user space can do absolutely nothing about it.
  
  --
  Finally! A year of moderation! Ready for 2019?
33. Re:Precisely how... by nctritech · 2014-03-17 11:23 · Score: 1
  
  What people don't get is how PCI + ACPI have made modern computing possible, and how ARM systems suffer terribly precisely because no such equivalents to these exist in the ARM ecosystem (excluding some PCI bridges, but that's only one piece of the puzzle.) Before PCI (and ignoring EISA et al) all peripheral devices in a computer had to be configured manually. You had to know your Sound Blaster 16 used I/O port 220, IRQ 5, 8-bit DMA 1, and 16-bit DMA 5, and tell each one of your DOS programs or your Windows audio driver all of these things.
  
  Granted, some improvements came along the way, but they were troublesome and didn't always work as intended (Plug-and-Play ISA, for example). PCI was the first ubiquitous chipset-to-peripheral bus interface specification that provided all the information needed to figure out any given PCI device's hardware configuration with obnoxious amounts of detail (lspci -vv if you don't believe me).
  
  ACPI was brought in to clean up the other autoconfiguration-unfriendly interfaces that were lying around. Advanced Power Management was the biggest one that comes to mind, though things like MPS were pulled in also. A whole host of highly system-specific information comes in through ACPI and that's what makes it fairly easy to write a "run anywhere" operating system for systems that have ACPI and PCI. It's not perfect by any means, but without it there would be a bunch of proprietary ways to, say, send a "laptop lid was closed" event to the operating system.
  
  ARM does stuff like this with a pile of GPIO pins which are configured differently for every single bloody device that the otherwise identical ARM SoC is engineered around. You can thank ACPI and PCI in large part for keeping us from needing a specially tweaked OS kernel for every single model of PC that gets released. I'm glad they exist, however ridiculous they can seem at times.
34. Re:Precisely how... by TechyImmigrant · 2014-03-17 12:38 · Score: 2
  
  Declarative firmware only gets you so far. You can say 'Register to do X is at this address' but without software than knows what the hell to do with X you don't have a solution. Without an open interface spec, you can't write the software.
  That's why open interface specifications are a prerequisite for a bottom-up auditable code set.
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
35. Re:Precisely how... by fisted · 2014-03-17 12:47 · Score: 1
  
  ACPI solves a problem
  And creates half a dozen worse problems in the process.
  
  --
  CLI paste? paste.pr0.tips!
36. Re:Precisely how... by fisted · 2014-03-17 12:50 · Score: 1
  
  where exactly is that free freedom? Oh, wait.
  
  --
  CLI paste? paste.pr0.tips!
37. Re:Precisely how... by TechyImmigrant · 2014-03-17 13:36 · Score: 1
  
  ACPI solves a problem
  And creates half a dozen worse problems in the process.
  Which bit of "ACPI is horrible, and I'm all for replacing it with something better" did you miss?
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
38. Re:Precisely how... by 0ld_d0g · 2014-03-17 20:33 · Score: 1
  
  Microcode has nothing to with any how you interact with the CPU though. ACPI However *is* the actual Interface. Hes saying lets label all the roads in this town and you're saying Mr. Smith never lets us play inside his yard.
39. Re:Precisely how... by nateman1352 · 2014-03-17 21:37 · Score: 1
  
  What exactly was stupid about my post? Take it you have never heard of ACPI Source Language or the Embedded Controller?
  Seriously where should you more worried about NSA exploits1) a de-compilable and OS visible byte code that controls thermal and power management or 2) An invisible micro controller firmware that converts signals from your scan matrix laptop keyboard into P/S 2 signaling?
  Seriously dude, I write firmware for a living... I know a thing or two about what it does and the state of Linux's ACPI stack.
40. Re:Precisely how... by Lumpy · 2014-03-18 00:00 · Score: 1
  
  Correct, I mis-identified the package, I have QFP on the brain as I have been searching ebay for some old stock to fix an old DSP board, looks like I have to scrounge for some TMS320's on old boards.
  Some of the newer PLCC's have very dense pins on the surface mounted sockets. And honestly with I2C it is trivial to solder the chip on the board and simply provide a header to reprogram it. The funny part is a lot of the guys that really want socketed chips to use with their external programmer/reader do not realize that it is a lot easier and cheaper to use the on board solutions.
  
  --
  Do not look at laser with remaining good eye.
41. Re:Precisely how... by TechyImmigrant · 2014-03-18 04:15 · Score: 1
  
  Not on target systems I don't control. Can I plug my new thing into the USB port of a Samsung phone? Not if I have to replace the kernel. The thing is locked.
  You can arrange your own machines how ever you like, but if you're building things to work on everyone's machines, then you need to test it in many contexts that you don't control.
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
42. Re:Precisely how... by TechyImmigrant · 2014-03-18 04:18 · Score: 1
  
  I hate ACPI and avoid it at all costs. But I'm fully aware that if you removed ACPI, you would have to replace it with something. My Apple 2 has a scheme for mapping ROMs on cards into memory and calling them at boot time based on descriptors in the ROMs. It has to exist in some form.
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
43. Re:Precisely how... by nateman1352 · 2014-03-18 04:56 · Score: 1
  
  It is true that the kernel is expected to load and run the ACPI bytecode in a trusted context... but your assumption that the BIOS is gone after the OS bootloader runs is inaccurate. SMM keeps BIOS code code resident forever and running at a higher privilege level than your OS kernel. And its impossible for your kernel to see what SMM is doing unlike ACPI which is pretty easy to inspect,
  Your BIOS already owns the platform and getting rid of ACPI won't change that, it will just make it more difficult to firmware engineers (like me) to support all OSes with 1 firmware image.
  I agree that ACPI sucks in a lot of ways, but you must admit that there is something to be said for a standard that has enabled WinXP (10+ year old OS) and brand new stuff like Win8.1 and all the countless Linux releases in between to run on practically any PC regardless of it being brand new or 10 years old.
  IMO the trend towards having special firmware for each OS is disturbing and limits the universal and reusable PC. A lot of this is being driven by Google and thier insistence that Chrome OS systems be shipped without Legacy BIOS or UEFI support (locked down coreboot that only accepts OSes signed by Google unless run in "developer mode", btw even in developer mode you can't install a new coreboot payload to enable UEFI or legacy BIOS boot).
44. Re:Precisely how... by sjames · 2014-03-18 05:42 · Score: 1
  
  I'm not as worried about ACPI from that standpoint as Shuttleworth is. I am worried about the way it is generally buggy and only actually tested on the latest Windows so often. Of course, ACPI should not be used as an excuse to make hardware incompatible with standards.
  I find SMM more concerning since it can obviously be used to produce a really nasty and hard to detect rootkit. At least ACPI has to reveal itself and offers the possability of running it in a sandbox..
  I have no sympathy whatsoever for any attempt to lock in a particular OS and enforce a signed kernel unless the user gets to decide what signing keys are valid.
  From everything I have seen, EFI is an abomination. The best thing that could happen is to erase all evidence it ever existed.
45. Re: Precisely how... by astar · 2014-03-18 06:26 · Score: 1
  
  Yah. But ARM has the little bit of cpu ram. Thus you start out without having to knowi anything about the busses like to the regular RAM. But there are specialized compilers for say AMD64 that produce programs that do not use RAM. But ...
  Grub2 just will not fit in the usual sized BIOS ROM. Mostly everything is easy quantity 1 plus some sort of trade offs in money and skill and time. Now go fix it quantity G this calendar year with everyone trying to stop you.
46. Re:Precisely how... by Agripa · 2014-03-18 07:38 · Score: 1
  
  It also contains the code executed in System Management Mode (SMM) which may handle tasks like legacy emulation and thermal control.
47. Re:Precisely how... by fisted · 2014-03-21 13:53 · Score: 1
  
  Which bit of "worse" did you miss?
  
  --
  CLI paste? paste.pr0.tips!
48. Re:Precisely how... by badkarmadayaccount · 2014-03-31 12:14 · Score: 1
  
  Does the new version solve problems in you opinion? Is it a good move? Just curious.
  
  --
  I know tobacco is bad for you, so I smoke weed with crack.
Source codes, legos, meccanos by Hognoxious · 2014-03-17 06:48 · Score: 3, Funny

Mark Shuttleworth calls for an end to proprietary firmwares
Well I call for an end to spurious pluralization, so there!

--
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Translated by Anonymous Coward · 2014-03-17 06:49 · Score: 1

"We at ubuntu ran into problems working with firmware type X and want to get rid of it and need an excuse, playing on fears tends to work, so let's use that"
1. Re:Translated by peppepz · 2014-03-17 08:21 · Score: 2
  
  Everybody runs into problems with ACPI. I've never seen it work properly, on any OS, on any machine that I've owned.
I can't see this happening. by allaunjsilverfox2 · 2014-03-17 06:49 · Score: 3, Funny

Perfect example would be dell bios. There is no way DELL would allow a USER into bios. Especially one that might cause issues that can't be condensed into auto-replies.

--
Restore the madness of youth's lechery
Re:Silly Rabit by X0563511 · 2014-03-17 06:52 · Score: 2

You don't have to.
Just don't lock your implementation away and let people actually use it

--
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Make Ubuntu work properly first by Anonymous Coward · 2014-03-17 06:55 · Score: 1

Shuttleworth has ambitious plans, but how about taking care of just the basic quality assurance of Ubuntu first. I am greeted with a bloated and laggy desktop (Unity) with constant "Ubuntu has experienced an internal error" popups. Launchpad has multiple reports of the silly bug of many laptops having the screen brightness adjustment go double steps because the brightness event is handled twice. Hibernation, a common feature of modern OS, is still disabled by default. I could go on.
1. Re:Make Ubuntu work properly first by Desler · 2014-03-17 07:00 · Score: 1
  
  But fixing bugs is hard!! Canonical is too busy code-churning for boring stuff like bug-fixing.
2. Re:Make Ubuntu work properly first by lgw · 2014-03-17 07:10 · Score: 2
  
  At Canonical, making Unity worse is job 1! It gets harder every release to make Unity worse than the last one, so it takes all their mental effort. Perhaps with open firmware, Unity could actually electrocute the user, opening a whole new realm of "worse".
  
  --
  Socialism: a lie told by totalitarians and believed by fools.
What RMS has been saying all along. by Anonymous Coward · 2014-03-17 06:57 · Score: 5, Insightful

So people are just now figuring out that o'l fatty hippy beard Richard Stallman was right all along?
Color me fucking surprised! Any code you can't see can and will be used against you.
RMS says things that are uncomfortable and difficult but painfully true. Don't mistake is disinterest in your feelings (Or business model) as hostility.
On the subject of Troy by K.+S.+Kyosuke · 2014-03-17 06:58 · Score: 1

I've been to Troy, there is not much left
Funny thing is, that's less due to Achaeans and more to Schliemann's "excavations". ;-)
(BTW, when did Shuttleworth decide to grow a kinkled beard?)

--
Ezekiel 23:20
Starts with one generic enough by gmuslera · 2014-03-17 07:03 · Score: 1

And if people start buying from that brand over rivals (or having country legislation forbidding not open enough and/or so backdoored hardware) it may move others to do the same.
Also, if a "hidden" functionality is exposed in major brands using that executable code to perform malware-like activities that brands should be punished in security aware circles. That won't reach the majority of people, but will be an start.
Possesion by MouseTheLuckyDog · 2014-03-17 07:09 · Score: 2

So how did RMS posses Shuttleworths body?
1. Re:Possesion by fahrbot-bot · 2014-03-17 07:13 · Score: 5, Funny
  
  So how did RMS posses Shuttleworth's body?
  There's an obscure clause deep down in the GPL ...
  
  --
  It must have been something you assimilated. . . .
2. Re:Possesion by Kjella · 2014-03-17 07:59 · Score: 3, Insightful
  
  It's part of the GPLv666 under the "Demonic Possession" section if you use the "or any later version" clause. I hear Stallman wrote the original in blood, he couldn't find any open source ink. And you really don't want to know how the toe jam is involved.
  
  --
  Live today, because you never know what tomorrow brings
3. Re:Possesion by triffid_98 · 2014-03-17 12:03 · Score: 1
  
  So how did RMS posses Shuttleworths body?
  
  A trojan in his ACPI firmware?
Some context from a hardware perspective. by queazocotal · 2014-03-17 07:18 · Score: 5, Informative

Great - you don't want ACPI.
I'm looking at my Nokia n900 phone.
(merely because I happen to have a detailed understanding of the design).
Inside it, there are the following closed-source blobs running on turing complete processors.
LED controller firmware.
SIM java virtual machine
SIM raw firmware.
eMMC controller.
SD controller.
Hard-real-time modem controller.
Modem high-level engine.
Bluetooth CPU.
Wifi processor.
Main linux application processor
GPU.
I strongly suspect there is also an embedded processor in:
Power managment controller.
LCD.
Battery charge monitor.
GPS. (It's possible this is just an application running on the closed-source modem high level engine).
https://srlabs.de/rooting-sim-...
http://www.youtube.com/watch?v... (rooting SD cards)
http://www.youtube.com/watch?v... (battery firmware hacking)
Similar efforts have been done with reverse engineering the firmware of bluetooth devices, wifi.
The notion that you should only care about the code running on the CPU being open has always seemed really naive to me.
1. Re:Some context from a hardware perspective. by rahvin112 · 2014-03-17 08:29 · Score: 3, Informative
  
  There are many cellphones where there is an independent CPU running the cellular radio. This CPU runs a proprietary OS that runs has write access to all memory and can actually override the main CPU. In theory the radio CPU and OS could actually overwrite memory on the fly and redirect the kernel in completely transparent ways.
2. Re:Some context from a hardware perspective. by ericloewe · 2014-03-17 09:09 · Score: 1
  
  I believe it's nearly all phones, if not all of them.
3. Re:Some context from a hardware perspective. by AmiMoJo · 2014-03-17 10:02 · Score: 3, Interesting
  
  Okay, but despite being Turing complete most of those devices could be contained by an open source firmware in a secure way. For example the LED controller is probably what, an I2C device? There is no way it could compromise anything with an even half way competent ACPI implementation. The battery monitor, LCD, GPS and probably a few others probably fall into that category too.
  For everything else you need a secure APCI implementation that is based on not trusting the firmware in those devices. Okay, the wifi firmware could intercept, modify or leak any packets, but at least with an open source ACPI implementation the damage could be limited, contained and perhaps detected. It's not perfect but it's a lot better than what we have now.
  
  --
  const int one = 65536; (Silvermoon, Texture.cs)
  SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
4. Re:Some context from a hardware perspective. by YoopDaDum · 2014-03-17 21:15 · Score: 1
  
  True, but at least on a PC the main CPU could protect itself against any device being an IOMMU. And in smartphones ARM also has an IOMMU IP (called SMU). I don't think it's commonly used yet, but on principle at least it is possible to hook any smart peripheral with an embedded processor (or several nowadays for a 4G cellular modem for example) to the SMU, and then the SMU to the SoC NoC providing access to the system memory. Then the user application processor (AP) can restrict any memory access from those devices.
  
  So even if such a smart peripheral is exploited, if it sit behind an IOMMU/SMU the AP can restrict to which parts of the memory it can access, just like a MMU provides such protection between processes. The peripheral, even if inside the SoC die, can be sandboxed.
  
  Is this how it is done today? I guess not. For SoCs, I'm not sure a lot of chip vendors pay for the additional SMU IP, unless they have another use-case that requires it (like supporting virtualization). And even if the hardware is there, I'm not sure it is actually used for security containment as I described. Could a linux expert comment on that for the PC world at least?
  
  Now of course an IOMMU/SMU will never protect against an embedded chip purposefully designed to be able to take control of the chip and access system memory without restriction, like the management chip on some Intel chips (vPro feature IIRC). But as you point out there are a lot of smart peripherals, and if we could at least mitigate exploits from them it'd be that many less potential holes.
  
  Last point, security always has a cost: someone needs to handle the IOMMU/SMU management to do the sandboxing. And a sandbox may prevent zero copy, requiring extra copying from the AP in some cases (to move data from AP reserved memory to/from a given device sandbox).
5. Re:Some context from a hardware perspective. by wed128 · 2014-03-18 01:28 · Score: 1
  
  Yes.
6. Re:Some context from a hardware perspective. by rahvin112 · 2014-03-18 04:56 · Score: 1
  
  I believe so as well but without reviewing every possible phone I wasn't comfortable making that prediction. I know almost every major SOC that produces radio chips does this because of fear that people would tamper with radio power levels but it's a major security hole that I'm sure is being exploited by groups like the NSA.
Shuttleworth wrote ... by tipo159 · 2014-03-17 07:18 · Score: 1

In ye olden days, a manufacturer would ship Windows, which could not be changed
What the hell is he talking about?
This is about ARM 64 bit Servers by Bill,+Shooter+of+Bul · 2014-03-17 07:27 · Score: 3, Informative

Its already been decided by the industry that its going to be ACPI.
And Canonical helped desgin it... with ACPI in it
http://www.businesswire.com/ne...
So I don't understand why Mark is suddenly against it. Sudden change of heart leading Ubuntu to be non compatible with other linux operating systems? Again? I don't get it.

--
Well.. maybe. Or Maybe not. But Definitely not sort of.
1. Re:This is about ARM 64 bit Servers by Bill,+Shooter+of+Bul · 2014-03-17 10:33 · Score: 1
  
  Yes, there are many fears of what a government could do to gain access. There is no way to avoid it currently. Saying ACPI has the potential for problems doesn't add anything new to the conversation that's been going on for years.
  I'm guessing someone just informed him what his company agreed to, or he's gone a bit crazy.
  
  --
  Well.. maybe. Or Maybe not. But Definitely not sort of.
2. Re:This is about ARM 64 bit Servers by Bill,+Shooter+of+Bul · 2014-03-18 04:41 · Score: 2
  
  Responding to my own post. Mark explained himself on Google plus (can't link to it directly but look for Jon Masters post about annoying a billionaire) :
  "SBSA did not specify ACPI or any other crapware, and we were happy to support a standards-based approach. I think it's a poor effort if we can't achieve the goal of standards in a more modern, secure, open way."
  So it appears that he supported one standardization effort, but it didn't specify ACPI. I don't know what the truth is as the relevant documents aren't public. Mark also claims that he did propose an alternative approach that would still allow a single kernel but not ACPI. Not sure how specific it was, or if it was anything beyond " Lets have the kernel guys do it!".
  
  --
  Well.. maybe. Or Maybe not. But Definitely not sort of.
3. Re:This is about ARM 64 bit Servers by Bill,+Shooter+of+Bul · 2014-03-18 05:01 · Score: 1
  
  https://plus.google.com/106265...
  
  --
  Well.. maybe. Or Maybe not. But Definitely not sort of.
Because "Open Source" isnt an NSA vector by enigmatic · 2014-03-17 07:48 · Score: 1

Remember GnuTLS
1. Re:Because "Open Source" isnt an NSA vector by jones_supa · 2014-03-17 08:11 · Score: 1
  
  Yep. For truly secure and non-malicious software we need both open source and thorough code audits (à la OpenBSD).
That ship sailled in the early 90's by Wierdy1024 · 2014-03-17 08:06 · Score: 1

No escaping proprietary firmware now. I would hazard a guess that a laptop purchased today has firmware or firmware libraries from over 1000 teams.
You don't see them, because most are stored in roms and flash, and your OS doesn't need to know about them...
Re:Silly Rabit by ihtoit · 2014-03-17 08:15 · Score: 3, Insightful

it's called reference frameworks. By the time you get to Userland, a Creative soundcard looks to the software identical to a Turtle Beach. This would be impossible without a reference. One obvious example is DirectX. What you want out of the arse end of the driver layer is a device interface that's compatible with DirectX. What happens between the driver layer and the hardware is entirely up to the manufacturer, but the DirectX compatibility is a certain requirement for even the slightest hope that you'll even get a peep out of it in Windows. And one of the reasons why the Linux driver model, at least from my own personal perspective, is horribly broken. Is there a reference framework for *anything* in Linux?

--
Political debates have me rolling my eyes so much I think I got optical whiplash. I should sue. - Foamy The Squirrel
More context by maestroX · 2014-03-17 09:03 · Score: 1

reminder for the list; signed code, tivoization, like sigma et. al. firmware support pretty much equals caveat emptor nowadays, I like to re^H^Huse the cpu/mobo for something useful oh well raspberry pi + sim anyone?
Charles Stross? Is that you? by daboochmeister · 2014-03-17 10:07 · Score: 2

Your description of the GPLv666 with a "Demonic Possession" section sounds very worthy of a Charles Stross novel, in every respect. Kudos!

--
"Ahh! I see you're in that indeterminate Schrodinger state where - oh, uh ... never mind." Dave Bucci
Re:Silly Rabit by Arker · 2014-03-17 10:31 · Score: 1

"Is there a reference framework for *anything* in Linux?" Yes, it's called Slackware.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Re:Silly Rabit by tepples · 2014-03-17 14:58 · Score: 1

Is there a reference framework for *anything* in Linux?
For graphics there's KMS and DRI and Gallium. For audio there's ALSA. For printing there's CUPS. For scanning there's SANE. Etc.
Chrome OS > OS X by tepples · 2014-03-17 15:05 · Score: 1

Most laptaps these days are sold with OSX actually
Citation needed that over 50 percent of laptops are MacBooks. Last year freaking Chrome OS outsold OS X (source: Google macbook laptop market share).
Re:Silly Rabit by Arker · 2014-03-17 18:43 · Score: 2

You misunderstand me, I love slack too. I was (somewhat tongue-in-cheek) pointing to its role as the standard implementation. Which unfortunately is really just a memory as for over a decade now other distros have insisted tenaciously on ignoring solid standards and everyone just reinvents the wheel, in ever more byzantine fashion each iteration.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
The train left the station in the 2000s by Burz · 2014-03-17 20:25 · Score: 1

Escaping proprietary firmware.... http://www.coreboot.org/Welcom...
An OS can cope with hostile peripherals: by Burz · 2014-03-17 21:02 · Score: 1

In fact Qubes assumes they are hostile to a great extent already.
As long as one trusts the BIOS and other critical boot-time elements (i.e. ACPI), you have a very good shot at maintaining security with a system like Qubes and this is why Qubes users are expessing a lot of interest in Coreboot (open BIOS).
(Of course, one must also trust the CPU and chipset, but these are often provided by the same vendor which reduces the trust issue down to one party. And we're not even talking firmware or software here: Its hardware, which is further down the open source horizon, but someday.....)
Re:Silly Rabit by ihtoit · 2014-03-18 09:16 · Score: 1

Yeah, most of those popped into my head one second after I hit "send"(!)... but speaking from my own experience, I've never been able to get a Winprinter working under CUPS (maybe I'm being 'tarded about it). As to graphics, I wasn't even going to pick up the whip if it wasn't an ATI/AMD or NVidia chip (OK, the drivers are proprietary for both, but I'm not bitter - I even managed to get Beryl running on an upgraded Rage Pro). Trying to get anything near "accelerated" on any other graphics chip was for me, like pushing a cow backwards up a staircase.

--
Political debates have me rolling my eyes so much I think I got optical whiplash. I should sue. - Foamy The Squirrel
Re:Silly Rabit by ihtoit · 2014-03-18 09:20 · Score: 1

I love Zipslack... still use it on a positively ancient Dell CP (Pentium MMX) laptop. It's handy when all I want to do is type and don't need to be hearing the fan (which hasn't worked since ever and that isn't an issue anyway as the processor barely gets warm).

--
Political debates have me rolling my eyes so much I think I got optical whiplash. I should sue. - Foamy The Squirrel
Winprinter by tepples · 2014-03-18 11:33 · Score: 1

but speaking from my own experience, I've never been able to get a Winprinter working under CUPS (maybe I'm being 'tarded about it).
That depends on how you define "Winprinter". There used to be a concept of a "GDI printer" (or a "QuickDraw printer" during the classic Mac OS days), which relies on a rasterizer running on a PC to create a bitmap in some proprietary format and send it to the printer. More generally, they're called "non-PostScript printers", and they work fine under CUPS provided the manufacturer is friendly to the CUPS community. I bought my HP OfficeJet 4500 for exactly that reason: official support for printing and scanning through the HPLIP package. If your non-PostScript printer manufacturer doesn't ship a CUPS driver, blame the manufacturer.
1. Re:Winprinter by ihtoit · 2014-03-18 14:40 · Score: 1
  
  tried several bottom-shelf Lexmark inkjets, a couple of the Canon portables (BJ-10e and a BJC-80) and an HP Deskjet 320 as well. Ended up hooking up a Brother HL1030 (laser with manufacturer-supplied CUPS driver) and a HP Officejet 6210 MFD (ran through HPLIP), the other gear is gathering dust and spider colonies in a closet somewhere - can't even give the bloody things away...
  
  --
  Political debates have me rolling my eyes so much I think I got optical whiplash. I should sue. - Foamy The Squirrel
he's seen the light. by Finite9 · 2014-03-18 18:04 · Score: 1

Wow, is it true? This is the guy that was all about willingly making it easy for folk to install proprietary drivers for everything to ease adoption of Ubuntu. I remember all the forum discussions about that. Has he finally had a change of heart? RMS is likely having a moment of grim satisfaction right now.

--
"Everyone knows that vi vi vi is the number of the beast" -- Richard Stallman