back to article Shuttleworth: Firmware is the universal Trojan

Canonical boss Mark Shuttleworth has called on the world to abandon proprietary firmware code, calling all such code “a threat vector”. In this blog post, Shuttleworth makes the case that manufacturers are simply too incompetent, and attackers (including government security agencies) too competent, for security-by-obscurity in …

COMMENTS

This topic is closed for new posts.
  1. Robert Heffernan

    Wow

    This would have to be the most intelligent thing I have heard Shuttleworth say!

    1. Ole Juul

      Re: Wow

      It is indeed bang on. "Abandon proprietary firmware code."

      Not only is it a vulnerability as we've seen over and over again, but it is often deliberately feature poor.

      To really do a good job, let's get rid of the "proprietary firmware" that is the pre-installed OS on store bought computers.

      1. Oh Homer
        Linux

        Re: "deliberately feature poor"

        And Windows-centric.

    2. Anonymous Coward
      Anonymous Coward

      Re: Wow

      "This would have to be the most intelligent thing I have heard Shuttleworth say!"

      Really? So what, a washing machine manufacturer is going to post a message on the linux mailing list or sourceforge saying "Hey guys, we need some firmware writing for our new 1200 spinspeed model. Any takers?" Or is it just a case of lets publish all source code and hope someone understands servo motor controller XYZ123 well enough and gives enough of a toss about washing machines to spot coding errors?

      Please.

      I like Linux as much as the next guy - been running it at home since 93 - but I'm getting a bit tired of this whole OSS is the solution to all our software problems. If that were the case how come Shuttleworth came up with an abortion like Unity? If anything should be got rid of its that festering dogs dinner.

      The people who write firmware are usually experts in that particular field and I for one do NOT want some have-a-go amateur writing, for example, the baseband software for my mobile phone or the controller of the lift I use in the mornings. And nor frankly do I want Linux running everything. Its complete overkill for a lot of applications and KISS still applies in the 21st century.

      Sure, some firmware has faults, but compare the number of those against the firmware you use everyday without even thinking about it.

      1. DanDanDan

        Re: Wow

        Downvote from me for misunderstanding Open Source software on a fundamental level.

        "Have-a-go amateur"? Almost all major open source projects are supported by commercial interests. The Linux kernel is contributed to in a very significant manner by big name corporations, not have-a-go amateurs.

        http://www.linuxfoundation.org/publications/linux-foundation/who-writes-linux-2013

        1. Anonymous Coward
          Anonymous Coward

          Re: Wow

          >Downvote from me for misunderstanding Open Source software on a fundamental level.

          Sorry pal, its you who doesn't understand it. The point of Open Source is that the code is available for anyone to look at - it matters not who funds it or otherwise.

          >"Have-a-go amateur"? Almost all major open source projects are supported by commercial interests.

          >The Linux kernel is contributed to in a very significant manner by big name corporations, not

          >have-a-go amateurs.

          And the "major" projects will be outnumbered 1000-1 by all the smaller OSS projects out there. So have a go amateur is an entirely valid epithet especially since there are plenty of those who still contribute to the linux kernel. And I don't mean it in a negative way , I just mean someone who isn't employed to write some code but does it anyway and perhaps isn't an expert in the field.

          PS - it might help if you posted links that don't require registration before view.

          1. Stuart Van Onselen

            Re: Wow

            You're missing the point. The suggestion is not that hardware manufacturers absolve themselves of the responsibility to write their own firmware by calling in the "amateurs". They're free to do that, of course, if they want to see their sales plummet.

            The idea is that after writing their own craptastic drivers that they then publish the code. This lets competent people look for security holes, and allows the amateurs to fix or re-write the code. This presents the users with the option of loading alternative firmware, and it allows the hardware vendors the option of absorbing new code into the "official" release.

            1. Tom 38

              Re: Wow

              The suggestion is not that hardware manufacturers absolve themselves of the responsibility to write their own firmware by calling in the "amateurs". They're free to do that, of course, if they want to see their sales plummet.

              The idea is that after writing their own craptastic drivers that they then publish the code. This lets competent people look for security holes, and allows the amateurs to fix or re-write the code.

              It also allows other competent people to look at what commodity chips the hardware manufacturer has put onto the breadboard and produce a knock-off for virtually no investment.

              It also provides insight into any proprietary algorithms you use, eg wifi firmware frequently has (had?) proprietary rate algorithms, and nVidia and ATI keep the very proprietary bits of their drivers in their firmware.

              Shuttleworth doesn't care about any of that though, since he is an ideologue and this gets in the way of his faith. Yes, it would be fucking awesome if we had at those bits and pieces, but it would suck balls if it meant that hardware was either more expensive, less readily available or not developed.

              1. Stuart Van Onselen

                Re: Wow

                It also allows other competent people to look at what commodity chips the hardware manufacturer has put onto the breadboard and produce a knock-off for virtually no investment.

                nVidia and ATI keep the very proprietary bits of their drivers in their firmware

                As has already been pointed out, a sufficiently motivated and well-funded commercial rival can always disassemble the blobs and get at these "crown jewels" anyway, for all the good that does them. You see, ATI, nVidia, et al are not using just all off-the-shelf parts to make their stuff, and it's extremely difficult to reverse-engineer a billion-gate custom chip whether or not you have the firmware at hand. So they have very little to fear from open-source firmware, it's mainly paranoia and the bean-counters holding them back.

          2. Stuart Van Onselen

            Re: Wow

            Also: I'm not sure if you're making a separate point, or if you're actually suggesting that Shuttleworth is wants all firmware to be written in Linux. He explicitly states that he things declarative software is the best option. That's obviously not any type of OS, it's more like a static reference book.

            I don't know of too many knowledgeable people who consider Linux to be "the answer to everything". While Linux can actually be stripped down quite nicely for low-end devices, of course things like ultra-compact RTS OSs are vital for many embedded applications, and only the terminally ignorant would claim otherwise.

            Things like cell-phone baseband stacks will not be over-writeable, ever, because of legal implications and inter-operability concerns. That still doesn't stop security experts finding holes in them and letting the manufacturer know that it needs to patch them before it begins the next round of certification testing.

            The same thing applies to any safety-critical systems.

            And your comment about firmware specialists being needed to understand the intricacies of particular hardware components is certainly true, but it has no bearing on the issue of the suitability of open-source because, as I mentioned, the idea is not that the writing of firmware be left entirely in the hands of "amateurs".

            1. Anonymous Coward
              Anonymous Coward

              Re: Wow

              "that he things declarative software is the best option"

              It seems to me his idea of declarative software is nothing more than a glorified config file. The actual software he wants already written in the kernel. These sort of ideas sound great in theory - abstract everything away and just twiddle a few knobs to suit - but in practice it never works well because they're are just too many gotchas quirks and unknowns.

          3. Anonymous Coward
            Anonymous Coward

            Re: @boltar

            I have been reading the Reg for a few years and from reading many many articles I have come to this conclusion - All OSS coders, at least on El Reg, are experts in every field and language, and do not make mistakes, EVER. Sloppy coding and security vulnerabilities are for those "Windows" coders.

            With this knowledge I sleep soundly every night and I hope you will too.

            1. Stuart Van Onselen

              Re: @boltar

              And another one misses the point by a light year.

              It's not that OSS is inherently better, it's that anyone can see how good/bad it is, and then try to improve it, as opposed to relying entirely on Microsoft / Apple / the firmware blob-makers.

              1. Anonymous Coward
                Anonymous Coward

                Re: @ Stuart Van Onselen

                You missed the point, the previous post was an obvious joke. Get off your high horse and get a sense of humor.

                1. Stuart Van Onselen

                  Re: @ Stuart Van Onselen

                  Sorry, AC.

                  But never assume that a joke is "obvious" to everyone else, because there are always overly-literal wankers (such as myself) who will take it seriously. And it's even more likely that someone will misunderstand when there are so many similar posts made in absolute seriousness in this very thread.

              2. Anonymous Coward
                Anonymous Coward

                Re: @boltar

                > anyone can see how good/bad it is

                But almost nobody does.

                And therein lies the elephant in the room.

  2. Charles Manning

    He's right... and wrong!

    Like with most things in life, the truth is somewhere between the extremes.

    Yes, firmware is increasing becoming a potential vector. These days we have gone far beyond system designs where the CPU does everything and the OS is the gatekeeper of the CPU and thus what happens in the system. We now have increasingly sophisticated peripherals which are bus masters in their own right. They range from ethernet/serial/communication subsystems to graphics subsystems and lots, lots, more. Since many of these are bus masters, they can access any memory or peripherals in the system. Naughty firmware can very easily expose your whole system to the network. Thus, the threat is more than just technically feasible.

    So full marks to Shuttleworth for identifying a problem. Nothing new in this though - people have known of this for ages. It has even been discussed in hushed, and less hushed, voices in Reg commentardsville. Due to lack of originality we'll give him a C.

    But the solution... He doesn't know what he's talking about.... I've been in embedded system design for over 30 years now and I wish it was a tenth as simple as he makes out.

    Firmware typically needs to be incredibly responsive and run on very cheap hardware. That will always mean that people writing firmware will push the envelope. Pie-in-the-sky solutions seldom deliver anything. And, at the end of the day it is still code and needs to be written by people who are not aware of the full implications of what they are doing.

    So shuttleworth gets an F for that part of the paper.

    1. Flocke Kroes Silver badge

      Re: He's right... and wrong!

      Wouldn't it be nice to be sure you do not have NSA firmware in your hard disk that will hand over the drive encryption key to anyone that knows the NSA's secret handshake? How about replacing a camera's firmware to make it a standard UVC device or to make the LED always come on when it is recording? Would you like to know if your 32GB HDLC card contains 32GB, or 8GB with some lying firmware that will crash and burn when it gets quarter full.

      Given proper documentation, people will do these things for themselves and share them with others. They will use Linux when it is the right tool for the job or something smaller when Linux does not fit. I can understand Mr Shuttleworth simplifying the message. Imagine what what the Daily Wail or the Grauniad would do with a technical quote over 5 words. A proper IO MMU on USB interfaces was overdue last decade. Try explaining why to a non-technical journalist and see what headline he comes up with.

      Enough of the UK government now understand the value of open standards sufficiently to mandate ODF. It took them under a decade to catch on. Several other governments took less time. The same thing will happen with open firmware. Techies want it now. People will want it soon. Progressive governments will mandate it later. Manufacturers will then hire coders to maintain it, and in about fifteen years members of the Conbour party will draft a law requiring it on new purchases.

      1. rh587

        Re: He's right... and wrong!

        "How about replacing a camera's firmware to make it a standard UVC device or to make the LED always come on when it is recording?"

        My first thought was the Magic Lantern firmware add-on for Canon cameras to provide a whole host of improved functionality for videographers such as being able to turn off the Automatic Gain Control and a bunch of video stuff which for obvious reasons is generally a poor cousin to the stills functionality.

        It's entirely proprietary and undocumented - Canon would really rather you didn't, and bought a nice expensive video camera off them as well, so the guys behind it reverse engineered the DIGIC processor by literally just putting an LED on the board and reverse engineering it from the hardware up. Quite a feat of brain power and logic!

        If man can make it, man can break it...

      2. Anonymous Coward
        Anonymous Coward

        Re: He's right... and wrong!

        Given proper documentation, people will do these things for themselves and share them with others

        Yes and no. Firmware can also contain clues to business secrets, to the way a supplier has managed o speed up graphics etc. so I can see the other side of the coin as well - that does not mean I disagree with the idea of open code, just a realisation that it's not quite as easy as it seems.

        As for flashcards and wrong size reporting - if you find a way to tell the firmware of a hard disk to mark its allocated contents as bad blocks, you will find that that content is no longer touched, and that includes any wipe or delete routines. Worth thinking about..

        1. Charles 9

          Re: He's right... and wrong!

          As for flashcards and wrong size reporting - if you find a way to tell the firmware of a hard disk to mark its allocated contents as bad blocks, you will find that that content is no longer touched, and that includes any wipe or delete routines. Worth thinking about..

          Is this true even on the low level?

    2. Decade
      Boffin

      Re: He's right... and wrong!

      Wow, I wasn't even thinking about hard drive firmware. If you're really paranoid, you can employ full-disk encryption on that. Bus master peripherals are trickier...

      I was thinking more like coreboot, based on LinuxBIOS. There's no fundamental reason for the motherboard firmware to be proprietary software, when motherboard makers suck at writing firmware and free alternatives exist.

    3. MacroRodent

      Re: He's right... and wrong!

      >Firmware typically needs to be incredibly responsive and run on very cheap hardware.

      That's precisely the code I would like to see written by enthusiasts, not corporate drones. You know the demo scene? One sub-genre is making really limited hardware like C64 do things you would never have thought possible with it...

      1. Anonymous Coward
        Anonymous Coward

        Re: He's right... and wrong!

        That's precisely the code I would like to see written by enthusiasts, not corporate drones

        Oh really? And abandon, say, QA and other trivial things? A for enthusiasm, but you may need to think about this a bit more.

        1. MacroRodent

          Re: He's right... and wrong!

          >Oh really? And abandon, say, QA and other trivial things?

          Of course not. This could work analogously with Red Hat's RHEL, with the companies using the firmware doing QA on their hardware.

          Besides the existing state of firmware QA isn't stellar either. Eg., I have a big.brand DVD recorder / DVB-receiver combination that locks up almost always when it sees disk it does not like (wrong format, or too scratchy). The great corporate QA department obviously tested it only with perfect disks.

        2. Flocke Kroes Silver badge

          Who abandons QA?

          Half the places I have worked did not know what QA was, and half of those that had some thought it was only there to cause trouble. Microsoft disbanded their test team because they were 'delaying' Vista. The most common attitude I receive in industry is 'It compiles - ship it'. That is quickly followed by 'Version 2 hardware is ready to go, no more work on firmware for version 1. If there is a problem, customers will have to purchase new hardware'.

          Take a look at the Debian policy documents some time.

          There was an article recently about flying toasters coming back from the dead - presumably on Windows because they never went missing from Linux. I have far more confidence in open source software being tested and maintained than in proprietary.

    4. big_D Silver badge

      Re: He's right... and wrong!

      And a lot of the router "firmware" problems are old versions of Linux running on routers not being patched and allowing vulnerabilities through, as well as the proprietary stack on top of Linux.

      As Charles stated, the actual firmware is a known problem, but the proposed solution is a backwards step, especially in the IoT, where low power and highly efficient SoCs or ICs are called for, pushing all of that back out to a general purpose CPU, more memory and storage is going to drive the price and power consumption up, whilst reducing efficiency.

      Better standards for testing security and more transparency are called for.

    5. tentimes

      Re: He's right... and wrong!

      I dispute this. I used to write BIOS/Firmware code and there is no reason why the handoff cannot take place in a different manner. The firmware could also be open sourced, what there is of it, and kept to a minimum.

      I understand the things that take place on this boundary (within my own area of expertise anyway) and there was never any real discussion of these issues. Had there been then we could have either (a) Made the BIOS/Firmware open (since it is supposed to be minimal anyway) and/or cut back on what BIOS did. Typically I was writing in assembler/C for the firmware and you could put all sorts of back doors in there if you wanted. I bet there are loads of them in POS machines (as has been proved).

    6. DropBear
      WTF?

      Re: He's right... and wrong!

      Indeed, firmware is a vulnerability. Indeed, it would be better if it would all be open source. However, the "general solution" of not having embedded executable code is idiotic on such a monumental scale, it beggars belief.

      Perhaps it would work in the specific context of BIOS / ACPI he is generally writing about - but to have ALL hardware dangling on the CPU as some basic I/O... good grief. What is he thinking?!? How does he expect to push through ever-increasing resolution from a camera through USB if there isn't anything running on the other side of that, pre-compressing stuff first...? And that is a prime target for infection - let's just remember the rogue firmware that redefined the camera as a camera+keyboard and started "typing" into the OS, breaking out of its VM! Or does he intend to read and write HDD heads on-the-fly as CPU I/O as well...? If so, he's delusional. If not, his point is extremely poorly worded. Kudos either way.

      As far as I'm concerned, I still remember the times when "soft modem" used to be a swear-word. Nothing has changed merely because now we have more CPU cycles...

      1. Tom 13

        Re: What is he thinking?!?

        What he's thinking is that there's only one part of the stack that gets reliably* updated: the OS. We all patch it on a monthly basis. If security of your system is only as good as your last path (which all too frequently it is), the logical solution is to make the attached devices read only and have the bits that get patched do all the work.

        It's a nice neat theoretical solution. It's practicality may be doubtful, but there don't seem to be a lot of practical solutions being kicked around at the moment either.

        * if you don't like "reliably" per se, substitute "on average (mean and mode) gets patched the most often," but that wasn't going to be a very readable sentence.

    7. Anonymous Coward
      Anonymous Coward

      Re: He's right... and wrong!

      "We now have increasingly sophisticated peripherals which are bus masters in their own right."

      Yeah, a really new idea, that. Let me see. CDC 6400 PPs. Network cards on 8-bit PC bus with 80186 processors......

  3. JCitizen
    Holmes

    Unfortunately we need to look at this!!!

    Although I already suspected and acted on the "Snowden leaks", WAY before they came out; ALL code is suspect now that the revelation IS out! We need do an entire overhaul of all code to open source! It will not guarantee we won't get cracked, but at least we can keep an eye on it , if we band together and standardize the code! Of course, now that the wide world of the web is not under one domain source control now, we can see chaos in the near future - but it was headed that way anyway - I'm sure of it!

  4. Christian Berger

    But then we'd need hardware standards

    For example the framebuffer mode of every graphics card would need to work identically. We'd need to have just a small set of USB controllers, and all of that needs to be discoverable by the operating system. Otherwise you'd need to port your OS to every system just like you already need to do in the mobile world.

    1. MacroRodent

      Re: But then we'd need hardware standards

      No, the hardware would just have to be documented, no hidden bits needing non-disclosure agreements to see. Of course getting rid of nonsensical variation would be useful, and might be a side-effect of more openness and the requirement to properly and publicly document things (gratuitous changes become more expensive to do).

      1. Charles 9

        Re: But then we'd need hardware standards

        Basically, you wanna ban trade secrets. Never gonna happen since trade secrets are one of the valid business differentiators still legal under law. It's what allows for nVidia and AMD to keep trying to one-up each other. As long as there is a need to protect trade secrets or patents (and I mean honest hardware-based patents), then there will always be a need for obfuscated, proprietary hardware to guard against industrial espionage if nothing else.

        1. MacroRodent

          Re: But then we'd need hardware standards

          >Basically, you wanna ban trade secrets.

          Not at all. Just keep them on the other side of the programming interface. If the trade secret can be seen from the firmware code, it is no trade secret at all, because those with serious financial interest in getting the secrets can get the binary blob disassembled and analyzed. The only people hampered by the binary blob are those who honestly want to program the device.

          1. NullReference Exception

            Re: But then we'd need hardware standards

            And those with a *really* serious financial interest in getting the secrets can (literally) disassemble and analyze your hardware... the fact it's not software isn't going to stop them.

        2. Flocke Kroes Silver badge

          Trade secrets

          AMD have been publishing hardware specs for years. Nvidia started more recently - because it was to their advantage. You can get detailed specs on the behaviour of an ARM or Intel CPU, but that is nothing to with the implementation. You cannot put the documentation through a PDF to verilog converter. There is no such beast, and never will be.

          1. Tom 38

            Re: Trade secrets

            AMD have been publishing hardware specs for years. Nvidia started more recently - because it was to their advantage.

            Bad example I think - AMD started publishing hardware specs for their graphics cards after they separated out the proprietary bits into loadable firmware modules that you load and run on the card. The firmware then provides the "hardware interface" that is described in the specs - this is what Shuttleworth wants to remove.

    2. Roo

      Re: But then we'd need hardware standards

      "For example the framebuffer mode of every graphics card would need to work identically."

      I'm guessing that the PC BIOSes, CGA, EGA and VGA must have passed you by. :P

      As for the USB controllers, there are already standard mechanisms for talking to them (EHCI, OHCI) etc. In fact I think a large part of USB's success and subsequent ubiquity can be attributed to the stuff like the EHCI/OHCI specs. It has saved people writing an awful lot of code that does the same thing but slightly differently !

      Reinventing the interfaces for these widgets costs vendors money too, so there is an incentive for these folks to standardise - which is precisely why we have things like VESA, AC97 etc. Standardising stuff can mitigate some of the barriers to vendors releasing docs too (eg: patents) too.

      Regards,

      Rupert

      1. Roland6 Silver badge

        Re: But then we'd need hardware standards @Roo

        I think you are confusing interface specifications with firmware. Interface specifications treat the devices on either side of the interface as black boxes; firmware resides within the black box.

        What is the real benefit of having the firmware running in my VESA compliant LCD monitor/tv open sourced? particularly as the vendor has most probably not included any way for the firmware to be field upgraded.

        Yes there are some things that may theoretically benefit from being open source, however as the various router vulnerabilities and exploits has highlighted: it is one thing to find and fix a bug, it quite another to deploy that fix to devices already in the field.

        1. Roo

          Re: But then we'd need hardware standards @Roo

          "I think you are confusing interface specifications with firmware. Interface specifications treat the devices on either side of the interface as black boxes; firmware resides within the black box."

          That rather misses the point I was making, ie: that it's possible to have vendors make hardware behave to a standard...

  5. bazza Silver badge

    Er, What?

    Given that most of the Internet connected smart devices (SmartTV, fridges, home routers, set top boxes) are running on top of some form of Linux kernel already, what's he on about? These are the things that are getting comprehensively hacked, and mostly it is mistakes in the software stack above that is to blame. Whatever way you look at it, it's poor design, implementation and maintenance of firmware that is the root cause, not the lack of Linux inside.

    Even if the firmware was standardised and opened up, how's that going to improve things? The result would be that one single flaw would allow hackers to breach all devices worldwide, not just one family of routers from one company. Sure, one single fix would deal with it, but that's not comforting. Imagine if all home routers got compromised and the attacker disconnected them all from the net. How then would anyone be able to get the fix?

    If firmware became a standardised open platform there would be pressure to have things like virus checkers, etc running on them. It's happened with Android, why wouldn't it happen with standardised linux based firmware on other devices? And how would old devices be supported? The consequences are that there would be new firmware versions that won't run on older hardware, so we'd have the "Windows XP" style of obsolescence problem on everything, not just our desktops.

    So it comes back to good design, and a commitment from manufacturers to maintain and improve their firmware and hardware. Having a real "Read Only" switch on the device so that a hacker physically cannot alter it or install malware would be a very good start.

    1. dogged

      Re: Er, What?

      Thanks. Most sensible comment yet.

      There's an unfortunate tendency for people to leap at the word "open" and declare it a solution for absolutely everything. It isn't.

      1. Flocke Kroes Silver badge

        And what has closed ever solved?

        Take a quick trip to the twentieth century, and see what things were like before the rest of the world knew what open source was. Windows NT for people prepared to pay through the nose for software that worked. Windows ME for home users. Microsoft used its monopoly in operating systems to get monopolies in other fields - networking, office software and browsers. Microsoft were being found guilty of abusing their monopoly all over the world. They were paying millions a day for breaking the rules, but carried on because the fines were not a big enough incentive to stop. They got the judge in the US case replaced with someone who would give them nicer penalties. They were even granted a stay so they could come up with more 'penalties' because they were getting whatever they asked for.

        Now look at what open source has given you - the cooperative multi-tasking of DOS/W95/98/ME was replaced by XP at a reasonable cost because of competition from Linux. XP has lasted to this day because the existence of Linux gave you an alternative to Vista and Windows 8. The small cheap computer existed (disappeared and came back again) because of Linux. IE7 and Microsoft's non-standard HTML have gone because of competition from Firefox. Home NAS exists because you can use SAMBA and not need a full price Windows license and hardware big enough to run it. Microsoft tried - and failed - to own the entertainment distribution business because PVR hardware + Linux cost less than a Windows license. Satnavs are a reasonable price because Linux is free and runs on cheap hardware. You do not have to keep BT's spyware in your router because of openwrt. Libre Office is crushing Microsoft Office back into expensive nicheware. Microsoft never got more than their nose into super computing. Imagine the cost of a data centre with a Microsoft license for each CPU - not at today's prices, but at monopoly prices.

        Quit literally, all the kings horse's and all the king's men could not stop Microsoft's monopoly power. The thing that did was the Gnu Public License. Back in the twentieth century, the vast majority did not believe that was possible. Fifteen years later, you are the minority.

    2. Roo

      Re: Er, What?

      "Even if the firmware was standardised and opened up, how's that going to improve things? The result would be that one single flaw would allow hackers to breach all devices worldwide, not just one family of routers from one company"

      Clearly that would be stupid, and it's not what Shuttleworth appears to be advocating. RTFA.

      On the other hand that is pretty much the situation as it stands now because vendors tend to use off-the-shelf bootloaders & BIOSes in any case. You don't seriously expect a vendor on razor thin margins to write AND verify a new bootloader / BIOS everytime they ship a product do you ?

      Personally I would love to have hardware that sat there inert until I installed the bootloader of my choice on it. I have wasted far too much time working with poorly documented, broken abandonware BIOSes. Moving that stuff up the stack would mean I don't have to learn a new set of tricks everytime I get a new machine to look after.

      1. Roland6 Silver badge

        Re: Er, What?

        >Personally I would love to have hardware that sat there inert until I installed the bootloader of my choice on it.

        Can't see what Mark Shuttleworth is proposing will actually help you. You only need to look at the fun and games of PC motherboard monitoring tools, that are having to be constantly updated to keep pace with the release of new motherboards and chipsets, to see the problems with having application software directly interfacing to hardware rather than via a defined set of BIOS calls.

        1. Roo

          Re: Er, What?

          "to see the problems with having application software directly interfacing to hardware rather than via a defined set of BIOS calls."

          FYI PC BIOS calls are *very* rarely used these days - most OSes talk direct to the hardware via drivers. The reasons for that include performance, and working around broken PC BIOS design. Not really sure how you could reasonably expect a 16bit PC BIOS to work well with a 64bit OS...

          OTOH if you have a static description of the hardware and the OS provides the drivers then you are not tied into using 16bit PC BIOS calls for the next 40 years...

          1. Roland6 Silver badge

            Re: Er, What?

            >most OSes talk direct to the hardware via drivers.

            I think that what most OSes these days talk to, isn't the 'hardware' in the 1980's sense, but as you pointed out in a previous comment, but more to abstract and intelligent 'hardware' such as a USB or SATA controller through a well defined interface. Obviously, we can split hairs over whether this interface is part of the 'official' BIOS or available via direct access (DMA, System Bus, etc.) to the firmware in the controller.

            And I get your point about the role of a BIOS in modern systems being much reduced to essential services such as (effectively) providing a static description of the available hardware and bootloader services.

  6. Hans 1

    Not sure what the best approach is as I do not work in embedded system design, but proprietary firmware blobs are definitely the worst possible solution. Trojans are one problem, the other being their reluctance to allow third parties to redistribute their blobs, which of course is their way of controlling their blobs.

    @Charles Manning

    Great, you give him an F because his solution is too complex to implement yet you cannot come up with a better one ...

    1. Ed 13
      FAIL

      "Great, you give him an F because his solution is too complex to implement yet you cannot come up with a better one ..."

      He was just pointing out that complexity == cost, which doesn't go down well in a capitalist free market economy, so people will go with proprietary as it cheaper.

    2. Charles 9

      Trojans are one problem, the other being their reluctance to allow third parties to redistribute their blobs, which of course is their way of controlling their blobs.

      That's because those blobs represent trade secrets if not patents. The blobs represent a guard against industrial espionage by a rival firm, so there's a money angle for them meaning they won't give them up. Firm like this, if forced to open up, would probably pack up and go home instead, leaving no one to offer innovations.

      1. MacroRodent

        Serious industrial spies will have no trouble getting hold of a binary blob to analyze, even if its redistribution is restricted (spies by definition do not obey the rules). Such redistribution restrictions hamper only honest users.

        1. Hans 1
          Linux

          >Serious industrial spies will have no trouble getting hold of a binary blob to analyze

          Exactly

          To the others that downvoted me and reply with utter FUD (You seriously believe that, no, really ? Wow!):

          Claiming blobs secure your patents/features from competing firms is simply silly. Imagine all the drivers that exist for GNU/Linux where no blobs are needed - are the businesses that create those devices all gone bust ? Guess what, no.

          Besides, OSS code is MUCH cheaper than proprietary code, because you have volunteers.

          So I stand by my initial claim, blobs are evil and need to go - so much 20th century practice. Welcome to the new world of free and open firmwares.

          Wanna install OpenVPN on your DSL router, you can do so now with open firmware ...

        2. Charles 9

          But the thing is, trade secrets and patents are protected by law. That's why industrial espionage is illegal. The blob shows intent to keep secret, sorta like the DMCA provision.

          Also, hardware patents prevent people from rolling their own, so you're up the creek with a Hobson's choice.

  7. cracked
    Stop

    End Of Life

    Hello, what can I help you with today?

    Oh, I'm very sorry to hear that; but I'm sure your bank will compensate you ... Now, how long have you owned your current toaster?

    I see ... And when you purchased it, did the salesman inform you of the EOL Date?

    Oh ... Well, it was the year after you bought it.

    What? No, obviously the manufacturer is no longer updating the firmware for that model. No ... I'm sorry to say that the firmware from the current model isn't compatible.

    What!!? You thought it would make your toast for years to come! But it does so much more than simply toast!

    Yes, of course it does. That was required so that it could upload the number of slices you toasted to that ... cloud-based calorie-counter ... What' was it called? Ah, I forget ... I think it closed down a year or two ago ...

    Hmm? You don't use a cloud-based calorie-counter? Ah; then this probably wasn't the toaster for you!

    What? Well yes, it was still uploaded ... Oh, to some default profile the manufacturer created, I should imagine ... Has the data been what?! Good lord I shouldn't think so; it's just some simple firmware.

    You didn't realise? Did you read the manual? Ah no, there wouldn't be; not for a product in that price bracket - You would have to downloaded it, from the manufacturer's website.

    Have they really?! Well, I guess that does happen in this industry.

    And you bought it two years ago, you say? ... Well, it's about time for a new one then, isn't it! The burning of bread has moved on a pace, since you were last in the market. Can I recommend the latest ...

    1. Charles 9

      Re: End Of Life

      There would probably be unintended consequences, but what if there was a policy that prescribed that "working life" periods were determined by someone other than the manufacturer? Of course, the obvious question becomes, "Who?" DTA mode again...

  8. Aslan

    Prudent

    This sounds like a wonderfully prudent idea.

    I believe the way this would work is the properties of the hardware are provided in firmware, and then the OS loads code to the firmware flash, or if code is already loaded checksums the content. Thus you see the same level of performance, but have a system you can check to see if you control.

  9. tentimes

    He;s right - but MS etc won't give up the money from NSA

    There is no way that the NSA will let this one slip by. They will just increase the secret billions they give Microsoft etc to keep this working for them. Kill every fledgling company that makes a board that boots to kernel, buy it out etc. BIOS and firmware are too tasty for America to let go of them.

    1. dogged

      Re: He;s right - but MS etc won't give up the money from NSA

      Where's the AC with his cut&paste Microsoft security troll when you need him?

      You dullard.

  10. Michael H.F. Wilkinson Silver badge

    It's not just the "regular" firmware

    What about all the microcode in most, if not all CISC processors (not sure about modern RISC machines)? In principle it could be doing all sorts of things beyond performing the instruction requested by the given op-code.

    Opening up the code for inspection might work, but then you would still need to check the actual product shipped to ensure it adheres to the open specifications.

    The problem with paranoia is choosing an appropriate point to stop suspicions, and start trusting. I have no easy answer for that.

    1. Roo

      Re: It's not just the "regular" firmware

      "Opening up the code for inspection might work, but then you would still need to check the actual product shipped to ensure it adheres to the open specifications."

      You are allowed to ship an open test suite with your an spec. Also there is nothing stopping people from writing their own tests - at least they have a spec they can test against... ;)

      "The problem with paranoia is choosing an appropriate point to stop suspicions, and start trusting. I have no easy answer for that."

      It's a question of cost-benefit. At present the cost-benefit of checking my home router to see if it's been reconfigured (sometimes the ISP likes to dip in and erase all the firewall rules - let alone hackers) without my say so is actually firmly in negative territory at the moment. A static hardware description underpinning a cut-down OpenBSD install on that router would save me an awful amount of time and pain.

  11. Anonymous Coward
    Anonymous Coward

    almost right

    Firmware the universal trojan? Surely that's the NSA/GCHQ.

This topic is closed for new posts.

Other stories you might like