back to article Samsung laptops can be NUKED by ANY OS – even Windows: new claim

New Samsung laptops that destroyed themselves when booting Ubuntu Linux can be bricked by ANY operating system – including Windows – according to a top embedded developer. Nebula programmer Matthew Garrett has shed new light on a baffling bug that renders shiny Sammy computers completely unusable by accident, and blamed the …

COMMENTS

This topic is closed for new posts.
  1. David Ward 1

    Hopefully he tested his concept code on a machine that he can recover by manually re-flashing the UEFI firmware from a console or something similar and isn't distributing it to the uninformed.

  2. Anonymous Coward
    Anonymous Coward

    So that's why it stopped working

    And I thought it was all down to Windows 8!

    1. Anonymous Coward
      Anonymous Coward

      Re: So that's why it stopped working

      Don't mention Windows 8. It will incur the comments of EADON

      1. Danny 14
        Joke

        Re: So that's why it stopped working

        We do not speak his name! The OS chooses the user, it is not always clear why.

  3. Alan Brown Silver badge

    Recovery...

    ...is simply a matter of pulling the cmos battery and letting bios ram evaporate.

    Nonetheless it shows that samsung need to get their fecal matter together. A lot of machines are likely to be RMAed for this procedure if anyone malicious decided to use it to tweak endusers' noses.

    1. Anonymous Coward
      Anonymous Coward

      It has bugger all to do with the CMOS battery and "BIOS RAM".

      You don't know what you're talking about; that's not where UEFI variables live, and you aren't even using the correct terminology. You're about ten years out of date and ill-informed with it. Why don't you actually read the linked article with the PoC? Or these two wikipedia entries:

      http://en.wikipedia.org/wiki/Nonvolatile_BIOS_memory

      http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Variable_services

      (Not linkified because I'm not allowed to post links for some arbitrary reason.)

      1. Grikath

        Re: It has bugger all to do with the CMOS battery and "BIOS RAM".

        nope.. the closest you can get to this effect using legagy OS and hardware is something like bricking a VIC 20 by POKE-ing straight into ROM. The poor things had no defense at all...

        Looks like someone forgot to build in some restrictions regarding adressable memory locations.

        1. Anonymous Coward
          Anonymous Coward

          Re: It has bugger all to do with the CMOS battery and "BIOS RAM".

          Except that a VIC20 ROM was just that, ROM, you couldn't 'POKE' anything into it that survived a reset and even then only if you were executing Kernel from RAM.

          The closest thing I can think of for this scenario is a Flash BIOS killing virus like CIH/Chernobyl or flashing an embedded device with the wrong firmware.

          Recoverable with a little effort and not strictly a hardware 'failure' as such but still a massive pain in the arse for users all the same.

          1. Danny 14

            Re: It has bugger all to do with the CMOS battery and "BIOS RAM".

            some motherboards have recoverable bios's. Not sure if the systems are bricked enough to even allow this to start though (assuming a fault like this could be traced to desktop mobos, I doubt consumer grade laptops have this sort of redundancy built in)

            1. Tom 13

              Re: Not sure if the systems are bricked enough...

              I didn't look into the reports, but if they were recoverable I expect there wouldn't have been as many complaints.

              A couple years back Gigabyte released a series of MBs that had a flashable BIOS with a hard ROM backup. If you buggered the flash memory, you could still revert to the ROM which would then reprogram the flash. I thought they were rather handy. Haven't seen anything like them in a while though. Seems like rather inexpensive protection to me.

          2. Andy Enderby 1
            Happy

            Re: It has bugger all to do with the CMOS battery and "BIOS RAM".

            heh.... Oh how I laughed when someone mentioned CIH. I remember an R&D department at a British PC manufacturer getting laid low by that little piece of ****......... They were out of the game for a week if I remember..... Thanks to older hardware and marginally better anti virus policy compliance tech support was unaffected....... thankfully.

      2. keith_w
        Boffin

        Re: It has bugger all to do with the CMOS battery and "BIOS RAM".

        could it be because you are posting anonymously?

    2. Anonymous Coward
      Anonymous Coward

      Re: Recovery...

      Most EFI Variable Store implementations save the variable data to the same SPI NOR Flash device that contains the BIOS firmware itself. I am not aware of any implementation that does not use the SPI NOR Flash on a modern Core i7.

    3. Anonymous Coward
      Anonymous Coward

      Re: Recovery...

      WILL PEOPLE PLEASE STOP CALLING UEFI BIOS.

      Really, it's getting beyond a joke. If I hear another person say something like "All you need to do is switch off secure boot in the BIOS" or "Can't you just switch off UEFI in the BIOS", I'm going to scream.

      This is supposed to be a tech site.

      1. h3

        Re: Recovery...

        At least on my reasonably new Supermicro board the place to enable / disable UEFI is the legacy BIOS (That is the default it starts disabled). Everything you say doesn't make sense makes perfect sense in the case of my board.

      2. Suricou Raven

        Re: Recovery...

        People still flatten clothes with 'irons' long after they ceased to be made of iron.

        The term 'BIOS setup' will outlast the BIOS itsself.

        1. Anonymous Coward 15

          Re: Recovery...

          "BIOS" was always used incorrectly. The term originated as part of CP/M. The corresponding part of MS-DOS is io.sys.

          1. mark 63 Silver badge

            Re: Recovery...

            "The corresponding part of MS-DOS is io.sys."

            er, is it?

            I thought the bios was a level below that .

            Although I did notice once that winNT was able to use drives the BIOS hadnt bothered detecting

            1. /dev/null
              Boffin

              Re: Recovery...

              I think notionally the MS-DOS BIOS was split between the ROM BIOS (which would be customised to the particular hardware configuration of the PC) and IO.SYS (or IBMBIO.COM if you had PC-DOS) which was intended to be generic. The term "BIOS" is now so closely associated with boot firmware that we forget it used to be an integral part of a PC's native OS....

          2. Anonymous Coward
            Anonymous Coward

            Re: Recovery...

            Bo11ocks, BIOS was a part of the PC, sure CP/M may have used it first but way back in the mists of time where my career began, the 2764 (Or smaller, see IBM PC Tech Ref for details) EPROM on a motherboard contained the BIOS, Basic Input Output System.

            It contains just enough code to initialise the hardware and load the bootsector off whatever storage media (assuming no peripheral has a ROM that contains the magic numbers to tell BIOS code it's should run that first) you have attached which only then pulls in IO.SYS. IO.SYS is an integral part of MS-DOS and as such, IO.SYS is only required on a PC if you're running DOS or a derivative thereof.

            1. Tom 13

              Re: Bo11ocks, BIOS was a part of the PC

              You're way too deep in the 7 layer model for people who can't tell an app from the OS.

        2. Tom 13
          Devil

          @Raven

          How about we set your IDE hard drive parameters while we iron out the bugs in your BIOS? Or would you prefer we just set the MFM Drive ID number?

          Where's the crotchy older than dirt icon?

      3. Kiwi
        Linux

        Re: Recovery... @AC 16:23

        "If I hear another person say something like "All you need to do is switch off secure boot in the BIOS" or "Can't you just switch off UEFI in the BIOS", I'm going to scream."

        Why? On many mobos that's exactly where you turn it off. Both secure boot and UEFI. And many mobo makers call UEFI "BIOS" as well, some calling "BIOS" "Legacy BIOS".

        "This is supposed to be a tech site."

        It is. That's why people talk about turning UEFI off in BIOS. Or using BIOS to disable/turn off secure boot.

        Begone, vile hampster.

  4. Anonymous Coward
    Anonymous Coward

    So is Eadon going to have a retraction of all his anti-windows comments?

    Title says it all...

    1. Filippo Silver badge

      Re: So is Eadon going to have a retraction of all his anti-windows comments?

      That would take a *long* time.

      1. Quxy
        Facepalm

        I'm not Eadon...

        But I recall that any anti-Windows comment he may have posted on this particular topic was overwhelmed by a flood of 'AC's with such helpful suggestions as "Well if you will run freeware crap, you get what you pay for...".

        No, Eadon may be a a rabid penguin-head, but at least he signs his own name! And after all, he's *our* rabid penguin-head...

        1. Daniel B.
          Trollface

          Re: I'm not Eadon...

          Not to mention that Eadon's anti-windows comments have no bearing on this, as the article states that Windows *can* and *does* brick a Samsung lappy the same as Linux. IIRC the 'AC's were also mostly MS shills saying the same thing about "freetards getting what they deserved".

          So it is actually the shilltards who should be apologizing to *Eadon*. My my ... the irony...

          1. dogged
            Stop

            Re: I'm not Eadon...

            MS shills

            Hate to pop your paranoia but I don't believe there are such creatures on the Reg boards. Even RICHTO is pretty much a reaction to Eadon, Bob Vistakin, Barry Shitpeas and Mrs Barry Shitpeas (I only noticed the other day that "Philomena Cunk" is another Charlie Brooker character, insert facepalm here).

            The "shilltards" here seem to be confined to linux and Android.

            For the record, I work for a small development company in South Wales at the moment.

            1. Tyrion

              Re: I'm not Eadon... MS shills

              There are definitely MS shills / fanboys on the reg. You only have to look at all the downvoting that goes on. Most simply don't comment, they just sign up for an account then go around downvoting anything not pro-micro$oft. I've seen it first hand, hell I've even had one or two admit to it. It's sad really.

        2. Annihilator
          Meh

          Re: I'm not Eadon...

          But I recall that any anti-Windows comment he may have posted on this particular topic was overwhelmed by a flood of 'AC's with such helpful suggestions as "Well if you will run freeware crap, you get what you pay for...".

          Yeah I'm also noticing the rather muted response from the anti-Linux crowd on this article. It's like they've applied logic and realised they're wrong.

          Or they're just not up yet - give it time.

          1. Anonymous Coward
            Anonymous Coward

            Re: I'm not Eadon...

            Why blame Linux or Windows?

            This is Samdungs fault. Anyone who is under any illusion that they make good products really needs to think again.

            1. Tom 13

              Re: This is Samdungs fault.

              I believe the Kipling line is something approximating:

              but the sins that you do two by two you shall pay for one by one.

              Yes Samsung is primarily at fault for a very faulty BIOS/UEFI implementation. But the Linux distro was also at fault for sloppy coding and failure to test. Posters who weren't shilling for one side or the other appropriately beat up on both of them. We did give points to Linux guys for at least admitting they'd written sloppy code and rapidly posting defenses and fixes. And now it seems the Linux guys have done some solid research which indicates Samsung REALLY needs to fix their crap.

        3. Anonymous Coward
          Anonymous Coward

          Re: I'm not Eadon...

          Re: Eadon signs under his own name.

          How do we know?

          Is he also RICHTO, does he reply to himself under other pseudonyms or as AC? For all I know he may be half the people on the board, using a pseudonym is just as AC as using AC, because we don't know if comments are limited to that pseudonym from its owner.

          1. DF118

            @AC 16:26 Re: I'm not Eadon...

            You could've just said maybe he's a sockpuppeteer.

          2. Anonymous Coward
            Anonymous Coward

            Re: I'm not Eadon...

            "For all I know he may be half the people on the board, using a pseudonym is just as AC as using AC"

            I'm RICHTO and so is my wife.

          3. Tom 13

            Re: using a pseudonym is just as AC as using AC

            But if I used my real name here, how would you know it wasn't a pseudonym?

        4. Anonymous Coward
          Anonymous Coward

          Re: I'm not Eadon...

          You remind me of a French taxi-driver's comment on why a well known crook had just been re-elected Mayor:

          "C'est un vieux con, mais c'est notre vieux con a nous."

        5. Paul 129
          Linux

          Re: I'm not Eadon...

          But corebios is looking good about now. The more I read about UEFI the more i want to put linux there instead :-P

  5. Anonymous Coward
    Linux

    Poor Apple.

    OSX simply is not modern and sophisticated enough to brick a Samsung laptop.

    1. Chad H.
      FAIL

      Re: Poor Apple.

      Or Apples been doing UEFI longer than anyone else....

      1. Matt_payne666

        Re: Poor Apple.

        and Silicon Graphics/SGI has been doing its own take on UEFI firmware a lot longer than apple........

        1. ThomH

          Re: Poor Apple.

          Intel's been working on EFI since 1998 if we really want to get into it.

          It's Forth based, right? So we're probably talking about a stack overflow?

          1. Anonymous Coward
            Anonymous Coward

            Re: Poor Apple.

            It's Forth based, right? So we're probably talking about a stack overflow?

            No. You are confusing UEFI with Solaris's OpenBoot.

            UEFI has a shell --> http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Efi-shell

            1. Destroy All Monsters Silver badge
              Coat

              Re: Poor Apple.

              > It's Forth based, right?

              That would actually mean there was some hope.

              Yet another "industry standard" that is a Bad Idea, Badly Implemented.

              1. Anonymous Coward
                FAIL

                Re: Poor Apple.

                Utterly incredible that all of this critical low-level code has been crap from back in the mists of time.

                BIOS, UEFI, it seems to make no difference, it's nasty buggy stuff that is only just good enough to boot the hardware to the point where more capable software can rescue everything out of the cesspit.

                A massive FAIL going back 30+ years...

                1. Anonymous Coward
                  Anonymous Coward

                  Re: Poor Apple.

                  Who says it is the BIOS and UEFI to blame?

                  This is a case of poor implementation, the actual concept is sound.

          2. /dev/null
            Boffin

            Re: Poor Apple.

            EFI was invented by Intel to be the standard boot firmware for Itanium systems. It was only afterwards that someone thought it porting it to x86 would make a good replacement for the old PC BIOS, something which was well overdue.

            1. Tom 13

              @/dev/null: let me fix that for you:

              ...for the old PC BIOS, something which is still WELL overdue.

              On the other hand, at the BIOS level you're pretty much coding by hand and error testing is tricky. Worst part is what assumptions do you get to make about your inputs, because you don't have a lot of room to maneuver. I don't even write sloppy .Net code let alone the sort of really well though through machine code that goes into a BIOS. It may be crap, but when I really think about it, those guys have actually done pretty well by us through the last 30 years.

          3. Tom 13

            Re: It's Forth based, right?

            So what you're saying is that Intel said:

            Go Forth and conquer

            and they did?

        2. Anonymous Coward
          Anonymous Coward

          Re: Poor Apple.

          SGI aren't consumer machines.

  6. banjomike
    FAIL

    Oh, dear...

    ...someone is going to get a real shocker of an email from Mr Torvalds.

  7. Khaptain Silver badge

    Why Linux could trigger a bug that Windows might not

    Firmwares will present an API to an OS or will react through a multitude of electrical signals from various external sources.

    Therefore as long as an OS can interact with a processor or interface of some kind ( RS232) etc then in theory any OS has the capacity to trigger firmware functions,.

    Linux was written by inquisitive programmers that like to hack any and all given APIs, interfaces in the quest for knowledge or functionality. This allows Linux to be used for a myriad of different purposes .

    Windows and MacOs, on the other, have a different purpose than that of Linux. They are intentionally created as single purpose "End User" OS's whereas Linux is a Swiss Army Knife. WinOS and MacOS do not need the same amount of functionality, I am generalising quite a bit but it's easy to understand what I am getting at.

    This I believe could differentiate why one system would trigger bugs but another would not. Linux devs might write code and functionality that remain in the overall scope of the Linux way of thinking whereas MS Devs would simply ignore the existance of such and such an API because it does not fall into the scope of their requirements..

    YMMV

    1. Tim Parker

      Re: Why Linux could trigger a bug that Windows might not

      "This I believe could differentiate why one system would trigger bugs but another would not. Linux devs might write code and functionality that remain in the overall scope of the Linux way of thinking whereas MS Devs would simply ignore the existance of such and such an API because it does not fall into the scope of their requirements.."

      ..or it could be that someone wrote some code that conformed to the UEFI spec and because the firmware had bugs it bricked the laptops. That someone in the first instance was a Linux developer writing a kernel driver but, as appears to have been demonstrated, the choice of OS is irrelevant and the code can come from user-space (so any developer, not necessarily one from the institution responsible for the OS, could potentially trigger this).

      I'm not sure some strange theory about how and why certain organisations write the code they do is particularly useful in this instance.

      1. Khaptain Silver badge

        Re: Why Linux could trigger a bug that Windows might not

        @Tim

        Please reread my second phrase

        >Therefore as long as an OS can interact with a processor or interface of some kind ( RS232) etc then in theory any OS has the capacity to trigger firmware functions,.

        I am quite sure than I am being explicit enough in detail in order to understand that that no one particular OS is any more capable than any other .....

        Yes, I agree that the instruction will come from User Space, I did not state otherwise.

        <quote>I'm not sure some strange theory about how and why certain organisations write the code they do is particularly useful in this instance

        It is extremly relevant, Linux devs have the capacity, knowledge and depth of understanding that can take them further than other OS devs might need/want to go.

        In case you didn't understand the undertow, Linux developers push things further than Windows developers normally need to.... and that is usually a good thing, although unfortunately not in this case because of badly written firmware..

        1. Tim Parker

          Re: Why Linux could trigger a bug that Windows might not

          "@Tim

          Please reread my second phrase

          >Therefore as long as an OS can interact with a processor or interface of some kind ( RS232) etc then in theory any OS has the capacity to trigger firmware functions,.

          I am quite sure than I am being explicit enough in detail in order to understand that that no one particular OS is any more capable than any other ....."

          As far I am concerned that statement is fine - I have no problem with it.

          "Yes, I agree that the instruction will come from User Space, I did not state otherwise."

          Good - however the slant of your post seems to indicate that Microsoft devs (or presumably OSX or any other OS) just wouldn't use the API in the same way. I suspect you may be right that proportionally more Linux developers may be dealing with board level programming, however this issue came to light not due to some devvie hacking an API but a professional programmer using the interface as it was intended, and further more to spec. My point is that this could easily have been a developer from Microsoft, Apple, Solaris, HP-UX, QNX blah balh, writing an official driver or utility and the same thing could have happened, i.e. the issue is not with the philosophy of the development culture, but with a firmware that is not just buggy (that's too be expected in any code base) but is broken in respect to a mandated, and extremely important part, of the specification with rather drastic consequences.

    2. Anonymous Coward
      Anonymous Coward

      But Windows can trigger it.

      Linux was written by inquisitive programmers that like to hack any and all given APIs, interfaces in the quest for knowledge or functionality. This allows Linux to be used for a myriad of different purposes .

      Windows and MacOs, on the other, have a different purpose than that of Linux. They are intentionally created as single purpose "End User" OS's whereas Linux is a Swiss Army Knife. WinOS and MacOS do not need the same amount of functionality, I am generalising quite a bit but it's easy to understand what I am getting at.

      Your thesis is nonsense. Windows provides the exact same access to the UEFI variable space as Linux does, through the SetFirmwareEnvironmentVariableEx function - as used in the Windows-based PoC mentioned in the article.

    3. Annihilator

      Re: Why Linux could trigger a bug that Windows might not

      @Khaptain "Linux was written by inquisitive programmers that like to hack any and all given APIs, interfaces in the quest for knowledge or functionality."

      This wasn't a hack or an unusual use of an API or interface though. At a basic level it's a buffer overflow issue with Samsung's implementation of the UEFI.

      Incidentally, I think what you point out (Linux more likely to trigger a bug) isn't quite correct, I think it's more nuanced than that. I suspect that Linux is more likely to trigger a bug that the public can then hear about. Windows devs working for MS were just as likely to trigger this overflow (especially as it's an acceptable UEFI call FWIU), but the symptoms, bug report and fix wouldn't be made public.

      1. Khaptain Silver badge

        Re: Why Linux could trigger a bug that Windows might not

        Guys, calm down

        I am not knocking anyone, neither Linux nor Windows developers. That is not my intention, I have obviously been misunderstood from the beginning or I have badly worded my comments.

    4. Anonymous Coward
      Anonymous Coward

      Re: Why Linux could trigger a bug that Windows might not

      I'd actually say it is more like this.

      1. PCs are so massively varied, there are so many possible configurations it is impossible to put a number on how many there could be. So testing is tricky.

      2. Linux distros are so massively varied. Someone can change the code of the kernel to create their own unique version.

      While Windows has lots of different versions and patch levels, there are generally a lot less possible configurations than Linux.

      1. Tom 13

        Re: generally a lot less possible configurations than Linux.

        Infinity vs Infinity squared arguments bore me.

        I'd say this is one where MS's larger money pool and deployed base gave them a slight advantage. I wouldn't be surprised to learn MS found the bug, and worked around it, and never reported it to anybody because that's the way the rock. Because they have such a varied install base and the money to back it, they get to test (and frankly HAVE to) on a lot more hardware than the Linux devs do. On the other hand the Linux devs are more nimble, and patched it quickly.

  8. messele
    Mushroom

    So let's see if I understand this...

    Shamsung rip off somebody else's BIOS. Make a dog's dinner of the programming leaving massive flaws then blame this on innocent users and innocent Linux developers.

    Just checking some things never change.

    1. Anonymous Coward
      Anonymous Coward

      Re: So let's see if I understand this...

      Samsung licenses their UEFI BIOS from another vendor, and then tailors it as needed for their hardware implementation. The faulty Variable Store implementation was almost certainly provided by the original vendor, although it would be interesting to know if Samsung has kept up with maintenance releases from their vendor.

      1. Phil W

        Re: So let's see if I understand this...

        Regardless of whether Samsung got the original firmware from a third party the problem remains their responsibility. If the brakes failed on your car you wouldn't let BMW/VW/Ford/whoever get away with blaming a third party who manufactured the brake discs.

        If you assemble and sell a product you are responsible for the quality of it no matter what's in it or who manufacturers the components.

        1. amanfromMars 1 Silver badge
          Big Brother

          Re: So let's see if I understand this ... because it is really important*

          Re: So let's see if I understand this…

          Regardless of whether Samsung got the original firmware from a third party the problem remains their responsibility. If the brakes failed on your car you wouldn't let BMW/VW/Ford/whoever get away with blaming a third party who manufactured the brake discs.

          If you assemble and sell a product you are responsible for the quality of it no matter what's in it or who manufacturers the components. …. Phil W Posted Monday 11th February 2013 23:54 GMT

          Morning, Phil W,

          It will be interesting to see how that theory/opinion pans out in the real world with the burning Boeing 787 Dreamliner battery issue, which has grounded the entire fleet.

          * Typical pretentious politically inept Newspeak as obviously taught to wannabe leading TV politicians. Without media are they powerless, and this is not a question .... ergo media tales and trails rule?

          Wanna explore that Novel and Noble when Nobel Live Operational Virtual Environment, El Reg, with AIMaster Pilot ProgramMING? Satisfaction is Guaranteed. Of that can you be Assured.

          1. Danny 14
            Mushroom

            Re: So let's see if I understand this ... because it is really important*

            Troll makes sense? AI getting better? Seems to copy from his own back catalog though :(

            It will pan out exactly as stated. Boeing are carrying the can. I assume boeing will sue whoever supplied them but as far as things go boeing will take the hit. I imagine Samsung will also beast their supplied -assuming Samsung followed their vendors specs (in the boeing part assuming boeing followed all their sub contractor specs too etc).

            1. Anonymous Coward
              Anonymous Coward

              Re: So let's see if I understand this ... because it is really important*

              Boeing will inevitably carry the can because they won't sell some aeroplanes for a bit. I doubt that Samsung laptop sales will be much affected, because bricked laptops don't make people think of falling out of the sky screaming.

              Whether Boeing sues the supplier is going to depend on specifications, specifications, specifications. I remember a very nasty "you are going to have to compensate us" meeting at a customer once going very quiet as we wheeled out (a) the original specification and (b) the evidence that we adhered to it and (c) the evidence that the operating envelope had been exceeded by the customer.

              The customer's engineers took me out to lunch because they knew that the original design had been compromised at the behest of the product designers. And no, it wasn't an Apple aerial.

  9. tempemeaty

    If it isn't broken...fix it until it is....

    Yay for UEFI !

    Now can we have our clunky old fashioned, was working okay before, BIOS back in our computers again please.

    1. yossarianuk

      Re: If it isn't broken...fix it until it is....

      Yes you can, you can disable UEFI on most devices...

      Apart from ANY ARM based Windows 8 device, its mandated (for anti fair competition reasons) that you cannot disable Secure boot (which uses UEFI).

      ANY Windows 8 ARM device you have no choice... (but its your fault for buying such a piece on unusable crap.) As well as preventing you run Linux wil also prevent you running any older version of Windows.

      1. Danny 14
        Stop

        Re: If it isn't broken...fix it until it is....

        W8 ARM tablets are far from unusable. There is a difference between unusable and stupidly expensive for what they are. Also UEFI ARM tablets are a far cry from a laptop. As long as the tablet works then who cares if someone bricks it by trying to jailbreak/root/homebrew an OS on there - it will be the same if you brick an ipad or android tab.

        The samsung laptop is a different story and inexcusable as these are designed to have multiple OS choices. Obviously when W8 ARM laptops are out the same criteria would apply.

      2. Nuke
        Thumb Down

        @yossarianuk - Re: If it isn't broken...fix it until it is....

        Wrote :- "Apart from ANY ARM based Windows 8 device, its mandated .. that you cannot disable Secure boot (which uses UEFI)."

        I think you meant that it is mandated that PC makers should not disable the Secure boot SWITCH (assuming there is such a switch) - ie it is mandated that that the user should be able to disable Secure Boot. That is true. However it is also mandated (just as an example) that lorries on UK single carriageway roads are llimited to 40mph; but hw often do you see that being obeyed?

        From www.theregister.co.uk/2013/02/11/linux_foundation_uefi_workaround/

        "Linux enthusiasts observed that some OEMs were actually disabling the Secure Boot switch in their firmwares"

        1. Will Godfrey Silver badge

          Re: @yossarianuk - If it isn't broken...fix it until it is....

          Ummm, actually I think you'll find it is 55MPH

        2. Dave Lawton
          Boffin

          Re: @yossarianuk - If it isn't broken...fix it until it is....

          That article doesn't provide any citations for OEMs doing this, can you ?

          Microsoft were forced to change certification requirements for W8 after all the hooha when the original implementation was announced.

          The current requirement is - 'To be branded as W8 compliant, one requirement is that it MUST be possible for the end user to DISABLE secure boot'

          I'm not going to provide the link, plenty of references on ElReg to it.

          And, no I'm not a Windows fan, as anyone who knows me can attest.

  10. Euripides Pants
    Windows

    Well,

    Samsung's UEFI is definitely secure....

  11. amanfromMars 1 Silver badge

    It is not a hacked machine issue, it is a virtual machine user space crack

    Garrett, who works as a power management, mobile and firmware developer on Linux, said more work is being done to figure out the full details.

    Meanwhile, on the dark side of such matters is much work in full swing to take fuller silent advantage of the stealthy opportunities presented by such as are sublime vulnerabilities, existent in all smarter operating systems [Enabled and Enabling SOSystems] with overlording information overlode facilities/capabilities.

    Be careful out there, CyberSpace is not IT for Dummies, it is a place for genii free of the Fool and their Follies for LOLly and heavy laden to XSSXXXX in MetaDataBase Codes …. which is Enigmatic Treasure Trove for AIdDanegeld Virtual Supply to Offices of Cyber Security with ZeroDay Trader Protection. ……. Sp00Key IntelAIgent Space Services for Bonded Ware Houses in Rich Intelligence Communities/OSINT Environments.

    It seems that the bug we've been seeing is simultaneously simpler in some ways and more complicated in others than we'd previously realised. ….. providing a proof-of-concept program

    When that bug be a quantum trojan, is there no defence against IT in the Great Game that humans play so badly.

    1. Brewster's Angle Grinder Silver badge

      Re: It is not a hacked machine issue, it is a virtual machine user space crack

      "When that bug be a quantum trojan, is there no defence against IT in the Great Game that humans play so badly."

      Profound.

      And I apologise for the meatsack that downvoted you.

    2. Anonymous Coward
      Anonymous Coward

      It provides an interesting virus vector..

      If exist <plugged in USB stick> then

      rewrite USB stick with brick code

      reboot

      I'm not touching Samsung laptops for a while.

      Having said that, if that is a licensed UEFI implementation I'd love to know who the supplier is, and which other machines this has been implemented. This issue could be bigger than just Samsung.

    3. tony2heads
      FAIL

      Re: It is not a hacked machine issue, it is a virtual machine user space crack

      You didn't give the full link

      http://www.codon.org.uk/~mjg59/scratch/brick_samsung.txt

      I am surprise how few lines of C are needed

  12. Duffaboy
    FAIL

    QA whats that then

    Slap yourselves on the back fellas job well done.

    1. Silverburn

      Re: QA whats that then

      Easy as it might be to call this a QA issue, it probably wasn't in their spec to test LINUX installs on this hardware. They would have been given a number of official scenarios, and tested those and a few secondary scenaros as well. Anything else would not "be supported" so no testing.

      And even then, not all found issues are fixed; sometimes they generate a helpline script to be followed, and just accept it as "a feature". Dell, Apple and HP all have history here.

      However, if this is indeed exploitable via one of the "supported" OS'es, and all it takes is a different install vector (eg: verbose install from DVD? boot from SD card?), then Samsung really do have some QA questions to answer.

      1. Annihilator
        Stop

        Re: QA whats that then

        Easy as it might be to call this a QA issue, it probably wasn't in their spec to test LINUX installs on this hardware.

        However, if this is indeed exploitable via one of the "supported" OS'es,

        Ah, excellent, *still* trying to suggest that a bad or unsupported OS could be to blame. This isn't about an OS, it's about conforming to the UEFI spec. QA at this level doesn't involve an operating system, the test harness around this level of hardware interaction is and always should be OS independent.

        Even if this was a case of an OS making a bad or malformed UEFI call (it wasn't), the laptop shouldn't be damaged by it. This is basic bounds checking, and falls firmly into the category of QA. In this particular instance, it appears to be a buffer overrun, which has been bad programming since forever.

  13. Robin Bradshaw

    Is it only samsung???

    There are only a handful of companys who write firmware for for PC's off hand i can think of phoenix, award, AMI and insyde and i think the first 3 might all be the same company now, oh and dell but thats just a phoenix bios mangled beyond all recognition.

    I had a quick google and it appears the NP700Z5C is using a phoenix efi bios, I know the bios is customised by samsung for their particular machine and with UEFI apparently being designed to have loads of crap shovelled in to it I hope it was something stupid samsung did, but im intrigued as to if this is just samsung thats affected and if it is how have they managed to take code that many other manufacturers are also using and break it so spectacularly.

  14. Anonymous Coward
    Anonymous Coward

    Reminds me of Futaba..

    .the well known maker or radio control equipment, who stolidly maintained that their equipment, being digital and with each packet signed by a unique code flashed in at manufacture, simply couldn't interfere with another receiver 'bound' to a different transmitter.

    Except it was rapidly discovered that if you did - as was often done - the simple 'switch on, check battery level is OK, switch off (before boot completed)' routine it was entirely possible to zero the code in the flash. thereby ensuring that - after rebinding your receiver - you were on the same virtual channel as anyone else who had done the same.

    The egg on the corporate face was not lessened by months of refusal to admit the problem..

  15. TeeCee Gold badge
    Meh

    I stand by what I said last time.

    If it's writeable, it must be recoverable. Anything else is a one way ticket to Fuckup City.

    1. Fred Flintstone Gold badge

      Re: I stand by what I said last time.

      If it's writeable, it must be recoverable

      Only if you can read it first..

      1. Loyal Commenter Silver badge

        Re: I stand by what I said last time.

        Only if you can read it first..

        Ah yes, good old write only memory.

  16. Anonymous Coward
    Anonymous Coward

    Oh oh!

    Samsung got so blinded by staring at shiny MacBook's whilst creating their clonetops, they forgot to write their UEFI code properly.

  17. Bob Camp

    But you're still missing the point

    Windows COULD do this but does NOT do this because it's been tested by Samsung. I'm pretty sure they would have noticed all their notebooks bricking with Windows and would work with Microsoft to get it fixed before they shipped. That's because Samsung declares Windows as a supported OS.

    Linux COULD do this and unfortunately DID do it, and the bug made it all the way into a release because no one bothered to (i.e. got paid to) test it. That's the problem with running an unsupported OS. Samsung didn't want to test it, so it's up to the highly organized well-paid OS test team to catch critical bugs like this. For Linux, this team of people is called "end users." Now the bug has been detected and worked-around quickly, but at the unfortunate demise of a few customers' notebooks. With Linux (like any other OS), you get the good with the bad sometimes.

    1. Loyal Commenter Silver badge

      Re: But you're still missing the point

      The UEFI, however, shouldn't be tested against the OS, it should be tested against the specification. That's the only way to test that it meets the specification. It didn't, so it wasn't, so it's Samsung's fuck up, whatever the end user decides to throw at it (within the bounds of the spec, obviously).

    2. dajames
      Facepalm

      Re: But you're still missing the point

      Windows COULD do this but does NOT do this because it's been tested by Samsung. I'm pretty sure they would have noticed all their notebooks bricking with Windows and would work with Microsoft to get it fixed before they shipped.

      You'd hope so, yes ... but did you read what actually causes the bricking?

      It apparently happens when data is written to a diagnostic log that's maintained by the UEFI Firmware. If you write too much you brick the PC. It appears that when Windows boots normally it doesn't have enough diagnostic information to write for this limitation to cause a problem ... but there may be circumstances in which there is more to report, in which case the PC will get bricked under Windows.

      This could get triggered by something quite routine ... perhaps an error caused by trying to boot from a non-bootable USB Flash drive or SD card that had accidentally been left plugged in.

    3. Jason Bloomberg Silver badge

      Re: But you're still missing the point

      Windows COULD do this but does NOT do this because it's been tested by Samsung.

      Actually I think you'll find Windows did not do this because it didn't 'randomly throw data at the UEFI' as the Linux driver did. This article suggests Windows - and anything - can do the same in the same way and have the same adverse outcome.

      The problem seems two fold; Samsung's UEFI should not have allowed the failure to happen, and OS's and other programs should not be causing it to happen. It was just bad luck in some ways that Linux caused the house of cards to come tumbling down. Not entirely bad luck though, because it was doing something that it could not explicitly guarantee the success of. Had Samsung successfully protected against that it wouldn't have been a problem but unfortunately it wasn't the case.

      If you deliberately drive a car at a wall expecting the air bag to protect you from injury, when the air bag doesn't inflate and you hurt yourself then whose fault is that; yours, the air bag manufacturer, or both?

      1. Uffish

        Re: But you're still missing the point

        For me the point is that I now have no confidence in Samsung's testing of their own products.

  18. Anonymous Coward
    Anonymous Coward

    Finally, after 20 years..

    .. someone improves on the Terminate & Stay Resident (TSR) software we had under DOS by making it more efficient. It's now just Terminate..

  19. Will Godfrey Silver badge
    Unhappy

    I had great hopes for coreboot, but it looks like this has been completely elbowed out now. How could it be written over secureboot?

  20. Stevie

    Sweet Jesus H Christ On A Bike

    are you saying that this problem is when all is said and done just another stupid buffer overrun issue? As used to assault Windows for lo these many years? I thought engineers were supposed to be clever enough to learn from someone else's stupid mistakes.

    1. Annihilator
      Go

      Re: Sweet Jesus H Christ On A Bike

      Yup, it's retro, therefore cool to code badly like that I suspect.

      Unless you're a raving anti-Linux type, in which case it's all Linux's fault for existing. :-)

    2. robin48gx
      FAIL

      Re: Sweet Jesus H Christ On A Bike

      Ah I see, the BIOS detects an `overrun', thinks its under attack, and then self destructs.

      Bit like a Japanese WWII soldier, rather commit suicide than be captured.

      I pity the poor owners of these machines...

  21. Fred Flintstone Gold badge

    Ah, the irony..

    UEFI was supposed to make machines safer, despite many questioning the point.

    Instead, it appears it has simply become another mechanism by which to establish a Denial of Service attack.

    I would have much preferred it if someone would have taken the opportunity to speed up the boot cycle. I know some BIOSes were written that booted so fast it didn't even give the hard disk time to properly spin up - THAT I would have called an improvement. Not this idiocy.

  22. Anonymous Coward
    Anonymous Coward

    I put off buying a laptop for bloody years...

    ...because they're expensive and go obsolete too fast.

    And then this shit happens. :(

    Any word from Samsung on a new BIOS yet?

  23. Anonymous Coward
    Trollface

    Ha Ha Wintards!

    The laugh's on the other boot now

  24. robin48gx
    FAIL

    Samsung loosing the plot

    Lots of their tellys are failing (replace the "sam young" capacitors they start working again), now their laptops brick. Sounds like they are putting profit b4 reliability...

    1. Will Godfrey Silver badge

      Re: Samsung loosing the plot

      Is there a manufacturer these days that does NOT do that?

  25. Andy Watt
    FAIL

    This, the exynos Galaxy ram device security hole debacle...

    http://www.theregister.co.uk/2012/12/17/samsung_exynos_flaw/

    Any more?

    Do Samsung indulge in software quality at all? Tch. "release and be damned" appears to be their mantra...

This topic is closed for new posts.

Other stories you might like