Samsung laptop bug is not Linux specific | Hacker News Reader

Samsung laptop bug is not Linux specific

mjg59.dreamwidth.org

106 pointsDanieru37 comments

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

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

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.

Similar in that there are variable writes you can perform that break the system. Code-wise, entirely unrelated.

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.

Yes, this is what I meant

Problem is these 'slight changes' sometimes are what is wrong.

And this is not only about secure boot, but the whole UEFI infrastructure, which, as far as I know, is very complex.

> TianoCore – Open Intel reference UEFI reference implementation, 7061 files, >100MB of code, 10% of size of Linux kernel. Bigger than Linux core kernel

From Garrets linuxconf.au talk, year ago. As it is reference implementation, it is pretty much untested in the wild. So you can expect those "slight changes" to be mostly bugfixes.

Punchline is that Intel DOES provide pretty much all code for UEFI. And it is still bad.

I think both Intel [1] and Google [2] are working on some open source implementations of secure boot.

[1] http://www.phoronix.com/scan.php?page=news_item&px=MTI4O...

[2] http://www.phoronix.com/scan.php?page=news_item&px=MTI4O...

http://www.phoronix.com/scan.php?page=news_item&px=MTI3O...

> Intel should spec "to change screen brightness, write a value from 0 to 0xFF to this register"

There is already (mostly Intel made) spec for this kind of things. It's called ACPI. Which by the way Samsung started (partially) using not so long time a ago. Reason for that was that Microsoft was going to stop selling them Windows 7 OEM licenses unless Samsung starts using ACPI.

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.

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.

It's happened before: http://en.wikipedia.org/wiki/CIH

I know. But back then malware was still nearly exclusively done for "fun". Nowadays it's all about money

People still write malware for fun, there's just also lots of malware made to make money as well.

Like Stuxnet?

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.

Imagine if it turns out, in the future, such a "specific place" runs on Samsung laptops.

I'm not sure what the point of this exercise is. If the virus is as sophisticated as stuxnet it will only brick the Samsung laptops at that location, and it will have to do so only after spreading.

All the replies seemed to dismiss the issue as not a problem, because who would want to brick a computer?!

I'm just trying to highlight the many problems that appear when computers can be maliciously (or even accidentally) bricked by regular software.

Okay, but you should pick a more likely threat instead of making a shark attack argument.

I'm unfamiliar with that phrase, but are you saying CIH couldn't have happened in 2013?

Sure it could. So make your argument about something like that, a widespread threat, instead of something that is very scary and widely reported in the media but also very rare, akin to the chance of dying from a shark bite.

That WAS the original argument.

Okay I was unclear, let me try this again. pilif made an argument about times changing that you have not countered. You need something like that but modern. Stuxnet is too different of a beast to support you.

At this point I guess we'll have to agree to disagree, if you're convinced this is not a risk for Samsung laptop owners.

It's some risk, I guess. But I was interested specifically in what you had to counter pilif's most recent post. I guess either I was too unclear or you don't have a counter.

Bricking a laptop might be an efficient threat to extort a ransom.

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.

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.

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.

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.

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!

I'd rather have noobs complaining that Linux sucks than a calculator popping up whenever I hit FN instead of CTRL.

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.

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)

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?

No, but hardware vendors still tend to want to support older operating systems.

Reply on news.ycombinator.com