8 ms·

Samsung laptop bug is not Linux specific

106 points by Danieru 14y ago

drucken 14y ago
His solution at the end for Microsoft Windows is interesting. Are all UEFI PC-compatible systems required by some specification to support BIOS/legacy booting?
- mjg59 14y ago
  No, but hardware vendors still tend to want to support older operating systems.
joe_the_user 14y ago
I'm really not sure why Linux driver-creator spend effort trying to access laptop-specific feature. Most of these are somewhere between worthless and annoying. I had compaq where Ubuntu support twenty unwanted hotkey features that kept me from using standard function keys and popped-up the calculator with one false twitch. Took a few days to remove. Manufacturers should pay developers and support the features if they want them in Linux - especially since I Manufacturers actually benefit more than end-users. IE, it's useless except for the rare few who like the features and gain BRAND LOYALTY, the most valuable commodity of the modern era.
- keeperofdakeys 14y ago
  Many features have no standard api, which includes screen brightness. My samsung laptop a keyboard backlight, which requires the samsung module to use. There are also various other options in the BIOS that can be accessed through this interface. Unfortunately they are required.
- steevdave 14y ago
  Well typically the driver is written by the manufacturer or, more commonly, someone who DID want access to those features. What may be useless to you, or I, may be immensely useful to someone else.
- rogerbinns 14y ago
  Note that what you talk about has nothing to do with the underlying bug. UEFI provides a mechanism where any installed operating system can store and use named variables. The Samsung firmware fails if the size is more than trivial but not unreasonable amount. Linux just happened to be first to hit the problem because on a kernel panic, it writes diagnostic information to UEFI variables (only 10kb - well within the spec). The panic happened to be caused by Samsung driver written to Samsung's specs, but that is coincidental. Microsoft panics can be minidump format which are up to 64kb in size (also within the spec) so if they did the same thing then they'd hit the same issue. Or if Microsoft decided to throw some other stuff in there (eg information during upgrades, recovery information) they could cause exactly the same problem.
- buster 14y ago
  I'd rather have the calculator pop up for you, then myriads of Linux Newbies complaining that their Laptop doesn't fully "work" out of the box in Linux and thus Linux sucks. Also, as mentioned by others, there are all those special buttons for volume and screen brightness, for stamina/power mode and what not that are actually useful!
  - mich41 14y ago
    I'd rather have noobs complaining that Linux sucks than a calculator popping up whenever I hit FN instead of CTRL.
    - buster 14y ago
      I don't get how you making a mistake (pressing the wrong button) is the problem of the Operating System. It's just you doing the wrong thing.
0x0 14y ago
This is exactly what I thought of when I first read the stories about "linux bricking Samsung laptops": "Hmmm... what if a malware author ported the 'linux driver' to windows and embedded it in a drive-by download?" Hopefully this will push vendors to fix bugs like this instead of unfairly causing a PR disaster for Linux.
- pilif 14y ago
  Bricking your victims machines is a very bad decision from an economical standpoint as you can't use bricked machines any more to, say send spam or hijack online banking applications via a keylogger. Sure. Someone could be doing this for fun, but getting wide enough distribution of your malware is expensive (especially when you can't use your victims machines to spread out further). This wouldn't even work for ransomware because that too would require the machine to run well enough to display the ransom note. As such I personally find the scenario you described quite unlikely. Still possible of course, but also unlikely.
  - 0x0 14y ago
    It's happened before: http://en.wikipedia.org/wiki/CIH http://en.wikipedia.org/wiki/CIH
    - pilif 14y ago
      I know. But back then malware was still nearly exclusively done for "fun". Nowadays it's all about money
      - 0x0 14y ago
        Like Stuxnet?
        gus_massa 14y ago
        Stuxnet was not a virus designed to break random computers for "fun" (or "proof of concept"). It was a targeted weapon designed to break a specific place. Unless someone pays to cause the destruction, it's economically better for the malware authors people to create a inconspicuous botnet.
raverbashing 14y ago
And there you go, another proof that Bios/Uefi developers are incompetent And this is the unfortunate truth. Yes, I have worked for manufacturers, talking to the 'Bios developers' is useless (and see, this was for something much simpler) Intel (and AMD, and others) should simply cut the middle man. Instead, they're coming with overengineered solutions and too wide specifications that only cause trouble (UEFI, Acpi, etc) You can't have the manufacturer do this, the time of 'PC compatible' is over. They can keep UEFI, etc, but here's the thing: Intel should provide the main code for UEFI Intel should spec "to change screen brightness, write a value from 0 to 0xFF to this register" Much simpler and less error prone (I said less, not 100% error prone unfortunately) Edited: small mistakes
- ibotty 14y ago
  > Intel should provide the main code for UEFI i am not sure what "main code" is supposed to mean (i am no native speaker). but there is a reference implementation by intel and according to matthew garret most real-world implementations are only slightly changed.
  - Someone 14y ago
    Also, from the article: "We've seen similar bugs in Intel's reference code in the past, but they were all fixed early last year" So, this might actually be a bug written by Intel.
    - mjg59 14y ago
      Similar in that there are variable writes you can perform that break the system. Code-wise, entirely unrelated.
    - miahi 14y ago
      It could be one of those bugs actually, as I don't think the manufacturers use the latest version of the reference code. Probably they use whatever version was available when the project was started or whatever version the programmers are comfortable with.
  - 14y ago
gcb0 14y ago
Honest question: Do people in this forum do not disable safeboot as the first thing they do when they get a recent notebook? I just got mine this week, it was the very first thing i did. NONE of the arguments people had for it were implemented as they were hopping they would. That user password to disable? every time you disable it in the bios, bios ask you "type those 4 random digits i just generated to confirm"... how is this even called a password?! anyway, honest question. Do you disable it or do you actually use it? (not asking for opinion unless you actually have one, we had plenty of those before)

106 points by Danieru 14y ago

His solution at the end for Microsoft Windows is interesting. Are all UEFI PC-compatible systems required by some specification to support BIOS/legacy booting?

mjg59 14y ago
No, but hardware vendors still tend to want to support older operating systems.

joe_the_user 14y ago

I'm really not sure why Linux driver-creator spend effort trying to access laptop-specific feature. Most of these are somewhere between worthless and annoying. I had compaq where Ubuntu support twenty unwanted hotkey features that kept me from using standard function keys and popped-up the calculator with one false twitch. Took a few days to remove. Manufacturers should pay developers and support the features if they want them in Linux - especially since I Manufacturers actually benefit more than end-users. IE, it's useless except for the rare few who like the features and gain BRAND LOYALTY, the most valuable commodity of the modern era.

keeperofdakeys 14y ago
Many features have no standard api, which includes screen brightness. My samsung laptop a keyboard backlight, which requires the samsung module to use. There are also various other options in the BIOS that can be accessed through this interface. Unfortunately they are required.
steevdave 14y ago
Well typically the driver is written by the manufacturer or, more commonly, someone who DID want access to those features. What may be useless to you, or I, may be immensely useful to someone else.
rogerbinns 14y ago
Note that what you talk about has nothing to do with the underlying bug. UEFI provides a mechanism where any installed operating system can store and use named variables. The Samsung firmware fails if the size is more than trivial but not unreasonable amount. Linux just happened to be first to hit the problem because on a kernel panic, it writes diagnostic information to UEFI variables (only 10kb - well within the spec). The panic happened to be caused by Samsung driver written to Samsung's specs, but that is coincidental. Microsoft panics can be minidump format which are up to 64kb in size (also within the spec) so if they did the same thing then they'd hit the same issue. Or if Microsoft decided to throw some other stuff in there (eg information during upgrades, recovery information) they could cause exactly the same problem.
buster 14y ago
I'd rather have the calculator pop up for you, then myriads of Linux Newbies complaining that their Laptop doesn't fully "work" out of the box in Linux and thus Linux sucks. Also, as mentioned by others, there are all those special buttons for volume and screen brightness, for stamina/power mode and what not that are actually useful!
- mich41 14y ago
  I'd rather have noobs complaining that Linux sucks than a calculator popping up whenever I hit FN instead of CTRL.
  - buster 14y ago
    I don't get how you making a mistake (pressing the wrong button) is the problem of the Operating System. It's just you doing the wrong thing.

0x0 14y ago

This is exactly what I thought of when I first read the stories about "linux bricking Samsung laptops": "Hmmm... what if a malware author ported the 'linux driver' to windows and embedded it in a drive-by download?" Hopefully this will push vendors to fix bugs like this instead of unfairly causing a PR disaster for Linux.

pilif 14y ago
Bricking your victims machines is a very bad decision from an economical standpoint as you can't use bricked machines any more to, say send spam or hijack online banking applications via a keylogger. Sure. Someone could be doing this for fun, but getting wide enough distribution of your malware is expensive (especially when you can't use your victims machines to spread out further). This wouldn't even work for ransomware because that too would require the machine to run well enough to display the ransom note. As such I personally find the scenario you described quite unlikely. Still possible of course, but also unlikely.
- 0x0 14y ago
  It's happened before: http://en.wikipedia.org/wiki/CIH http://en.wikipedia.org/wiki/CIH
  - pilif 14y ago
    I know. But back then malware was still nearly exclusively done for "fun". Nowadays it's all about money
    - 0x0 14y ago
      Like Stuxnet?
      - gus_massa 14y ago
        Stuxnet was not a virus designed to break random computers for "fun" (or "proof of concept"). It was a targeted weapon designed to break a specific place. Unless someone pays to cause the destruction, it's economically better for the malware authors people to create a inconspicuous botnet.

raverbashing 14y ago

And there you go, another proof that Bios/Uefi developers are incompetent And this is the unfortunate truth. Yes, I have worked for manufacturers, talking to the 'Bios developers' is useless (and see, this was for something much simpler) Intel (and AMD, and others) should simply cut the middle man. Instead, they're coming with overengineered solutions and too wide specifications that only cause trouble (UEFI, Acpi, etc) You can't have the manufacturer do this, the time of 'PC compatible' is over. They can keep UEFI, etc, but here's the thing: Intel should provide the main code for UEFI Intel should spec "to change screen brightness, write a value from 0 to 0xFF to this register" Much simpler and less error prone (I said less, not 100% error prone unfortunately) Edited: small mistakes

ibotty 14y ago
> Intel should provide the main code for UEFI i am not sure what "main code" is supposed to mean (i am no native speaker). but there is a reference implementation by intel and according to matthew garret most real-world implementations are only slightly changed.
- Someone 14y ago
  Also, from the article: "We've seen similar bugs in Intel's reference code in the past, but they were all fixed early last year" So, this might actually be a bug written by Intel.
  - mjg59 14y ago
    Similar in that there are variable writes you can perform that break the system. Code-wise, entirely unrelated.
  - miahi 14y ago
    It could be one of those bugs actually, as I don't think the manufacturers use the latest version of the reference code. Probably they use whatever version was available when the project was started or whatever version the programmers are comfortable with.
- 14y ago

gcb0 14y ago

Honest question: Do people in this forum do not disable safeboot as the first thing they do when they get a recent notebook? I just got mine this week, it was the very first thing i did. NONE of the arguments people had for it were implemented as they were hopping they would. That user password to disable? every time you disable it in the bios, bios ask you "type those 4 random digits i just generated to confirm"... how is this even called a password?! anyway, honest question. Do you disable it or do you actually use it? (not asking for opinion unless you actually have one, we had plenty of those before)