Re: yawn

"This is the 3rd time this issue has been covered here"

Yes, it's a _developing_ story.

"the problem's ramifications have been clear from the outset."

To some, yes (or at least probably). This story provides provides evidence for what had heretofore been an assumption (ie that it is generic problem).

Are you really suggesting that El Reg should not waste our time reporting it ?

@ mods

Why delete the OP ? He didn't seem to violating posting guidelines, and it make my comments look a little one sided !

Re: @ mods

It also makes the "discussion" look like one from any hypersensitively-moderated news outlet rather than our dear old Reg.

Nope, can't have criticism of the site no matter how idiotic and ill-informed... deellllllete.

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.

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

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

"@Tim

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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.

Re: I stand by what I said last time.

If it's writeable, it must be recoverable

Only if you can read it first..

Re: I stand by what I said last time.

Only if you can read it first..

Ah yes, good old write only memory.

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

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?

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.