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