Forgot your password?
typodupeerror
Ubuntu Programming

Shuttleworth Wants To Get Rid of Proprietary Firmware 147

Posted by samzenpus
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."
This discussion has been archived. No new comments can be posted.

Shuttleworth Wants To Get Rid of Proprietary Firmware

Comments Filter:
  • 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*?

    • by jones_supa (887896) on Monday March 17, 2014 @01:45PM (#46508839)
      Getting rid of ACPI sounds also like a "good luck with that" plan.
      • by TechyImmigrant (175943) on Monday March 17, 2014 @01:56PM (#46508963) Journal

        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.

        • ACPI WMI specs from the HW makers would be nice. It's frustrating how many laptops have broken hotkeys under Linux.
          • 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 basical

        • by PopeRatzo (965947)

          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.

        • by Lumpy (12016)

          and he will NEVER get it.

          Hell you cant get open microcode on the freaking processors.

          Shuttleworth is starting to become a little nutty.

          • by 0ld_d0g (923931)

            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.

        • by Anonymous Coward

          "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?

          • Re:Precisely how... (Score:5, Interesting)

            by TechyImmigrant (175943) on Monday March 17, 2014 @03:42PM (#46510281) Journal

            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.

            • by fisted (2295862)

              ACPI solves a problem

              And creates half a dozen worse problems in the process.

              • 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?

        • by Anonymous Coward

          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 [coreboot.org] 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.

        • by drinkypoo (153816)

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

        • by mspohr (589790)

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

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

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

      • 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.
        • Yes, it could be one solution.
          • 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.

      • by mspohr (589790)

        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.

      • Re: (Score:3, Informative)

        by nateman1352 (971364)

        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

    • Re:Precisely how... (Score:5, Informative)

      by Anonymous Coward on Monday March 17, 2014 @01:58PM (#46508995)

      Firmware is just fine, as long as it's non-proprietary--free as in freedom.

    • DIL socket. Add your own firmware chip.

      • by Lumpy (12016)

        Yuck QFP is a lot better far better pin density and easier to insert or remove safely.

        • by LoRdTAW (99712)

          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 o

          • by Lumpy (12016)

            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 programme

    • Re:Precisely how... (Score:5, Informative)

      by amorsen (7485) <benny+slashdot@amorsen.dk> on Monday March 17, 2014 @02:04PM (#46509053)

      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.

      • by dargaud (518470)

        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.

        • by tlhIngan (30335)

          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 n

          • by amorsen (7485)

            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.

          • 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
          • by Agripa (139780)

            It also contains the code executed in System Management Mode (SMM) which may handle tasks like legacy emulation and thermal control.

    • by Anonymous Coward

      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.

      Ope

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

    • Re:Precisely how... (Score:4, Informative)

      by sjames (1099) on Monday March 17, 2014 @02:37PM (#46509477) Homepage

      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.

      • 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 [wikipedia.org] 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 fi

        • by sjames (1099)

          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 at

    • by mspohr (589790)

      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.

  • by Hognoxious (631665) on Monday March 17, 2014 @01:48PM (#46508869) Homepage Journal

    Mark Shuttleworth calls for an end to proprietary firmwares

    Well I call for an end to spurious pluralization, so there!

  • by Anonymous Coward

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

    • by peppepz (1311345)
      Everybody runs into problems with ACPI. I've never seen it work properly, on any OS, on any machine that I've owned.
  • by allaunjsilverfox2 (882195) on Monday March 17, 2014 @01:49PM (#46508893) Homepage Journal
    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.
  • by Anonymous Coward
    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.
    • by Desler (1608317)

      But fixing bugs is hard!! Canonical is too busy code-churning for boring stuff like bug-fixing.

      • by lgw (121541)

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

  • by Anonymous Coward on Monday March 17, 2014 @01:57PM (#46508971)

    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.

  • 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?)

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

  • by MouseTheLuckyDog (2752443) on Monday March 17, 2014 @02:09PM (#46509111)

    So how did RMS posses Shuttleworths body?

  • by queazocotal (915608) on Monday March 17, 2014 @02:18PM (#46509209)

    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-... [srlabs.de]
    http://www.youtube.com/watch?v... [youtube.com] (rooting SD cards)
    http://www.youtube.com/watch?v... [youtube.com] (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.

    • by rahvin112 (446269) on Monday March 17, 2014 @03:29PM (#46510129)

      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.

      • I believe it's nearly all phones, if not all of them.

        • by rahvin112 (446269)

          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.

    • 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?
    • by AmiMoJo (196126) * <{ten.3dlrow} {ta} {ojom}> on Monday March 17, 2014 @05:02PM (#46511111) Homepage

      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.

    • 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: It

    • 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
  • In ye olden days, a manufacturer would ship Windows, which could not be changed

    What the hell is he talking about?

  • by Bill, Shooter of Bul (629286) on Monday March 17, 2014 @02:27PM (#46509359) Journal

    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... [businesswire.com]

    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.

    • 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 ar

    • Yep. For truly secure and non-malicious software we need both open source and thorough code audits (à la OpenBSD).
  • 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...

  • Mark must have gotten laid recently. Or had lunch with Richard Stallman. Or...
  • 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.

"Never give in. Never give in. Never. Never. Never." -- Winston Churchill

Working...