Live data from Hacker News

Booting Linux using UEFI can brick Samsung laptops

h-online.com

11–20 of 55 posts

Re: Booting Linux using UEFI can brick Samsung laptops

#11
post #4
post #3

Earlier quoted context omitted.

That's because it's a lot harder to fuck up a few kilobytes of assembly than it is to fuck up several MB of bootloaders, device drivers, filesystem drivers, code signature verification, etc, etc, all of which are required for a complete EFI implementation. What we are seeing here is solid evidence of the fact that software is hard - and a lot of companies just don't have the chops to do a good job. Somehow I doubt th…

I guess Surface Pro will be locked down via Secure Boot and won't ever boot Linux unless jailbroken. Whether that's inherently better is probably another question.

It's sad that everybody wants to lock everything down. It's like no one learned anything from the success of the PC.

Re: Booting Linux using UEFI can brick Samsung laptops

#12
So random academic question - Should it be literally possible for an OS to "brick" hardware even if the OS was intentionally designed to do just that?

Now I know in this particular case Samsung wrote both the driver and the firmware, so it is easy to point blame here.

But more broadly, should hardware be built/designed so it has a "fail safe" mode where it just won't allow its self to be damaged by OS/software instruction?

PS - Let's just assume BIOS/uEFI firmware updates are off the table for this discussion. Since many modern uEFIs allow you to disable user updates entirely.

Re: Booting Linux using UEFI can brick Samsung laptops

#13
post #3

Say what you will about the old BIOS systems but at least it worked and everyone understood it. EFI/uEFI seems to be a big clusterfuck.

That's because it's a lot harder to fuck up a few kilobytes of assembly than it is to fuck up several MB of bootloaders, device drivers, filesystem drivers, code signature verification, etc, etc, all of which are required for a complete EFI implementation. What we are seeing here is solid evidence of the fact that software is hard - and a lot of companies just don't have the chops to do a good job. Somehow I doubt th…

Hmm. Almost right, until they introduced ACPI which in itself is much more of a clusterfuck because most of the vendors actually do it all wrong.

Re: Booting Linux using UEFI can brick Samsung laptops

#15
I wish UEFI was designed more with the user in mind and less politics and corporate decisions.

To start, it should not possible to brick a hardware in any way...

Interestingly, the UEFI looks to me sufficiently complex to control the device graphics and input before the OS boots, I wonder if that can be used to abuse the system and do again some "on the metal" coding for high performance stuff (ie: games... and scientific things).

I think maybe that cannot be done because probably no UEFI comes with drivers for video hardware acceleration.

Re: Booting Linux using UEFI can brick Samsung laptops

#16
post #6
post #4

Earlier quoted context omitted.

I guess Surface Pro will be locked down via Secure Boot and won't ever boot Linux unless jailbroken. Whether that's inherently better is probably another question.

According to Microsoft’s own “Windows Hardware Certification Requirements for Client and Server Systems”,[0] on non-ARM systems it is obligatory to offer the ability to disable Secure Boot: QUOTATION START 18. Mandatory. Enable/Disable Secure Boot. On non-ARM systems, it is required to implement the ability to disable Secure Boot via firmware setup. A physically present user must be allowed to disable Secure Boot via…

This requirement is only for other vendors to get the certification from Microsoft. Microsoft itself does not need to conform to it, so it is still possible that their products will be locked.

Re: Booting Linux using UEFI can brick Samsung laptops

#17

So random academic question - Should it be literally possible for an OS to "brick" hardware even if the OS was intentionally designed to do just that? Now I know in this particular case Samsung wrote both the driver and the firmware, so it is easy to point blame here. But more broadly, should hardware be built/designed so it has a "fail safe" mode where it just won't allow its self to be damaged by OS/software instru…

The word is bugs. It's very hard, and almost impossible to fix all bugs. Code with no bugs is really code with no known bugs. Especially when dealing with C and assembly, different parts of the code can effect other parts in ways a programmer may not anticipate. You really need to get a 'safer' language to prevent certain types of bugs, especially with the "data and code share the same segments" model of C.

Re: Booting Linux using UEFI can brick Samsung laptops

#18
post #4

Earlier quoted context omitted.

I guess Surface Pro will be locked down via Secure Boot and won't ever boot Linux unless jailbroken. Whether that's inherently better is probably another question.

It's sad that everybody wants to lock everything down. It's like no one learned anything from the success of the PC.

sadly the success of locked down.apple devices stands orthogonal to it.

Re: Booting Linux using UEFI can brick Samsung laptops

#19

So random academic question - Should it be literally possible for an OS to "brick" hardware even if the OS was intentionally designed to do just that? Now I know in this particular case Samsung wrote both the driver and the firmware, so it is easy to point blame here. But more broadly, should hardware be built/designed so it has a "fail safe" mode where it just won't allow its self to be damaged by OS/software instru…

Yes - hardware should be designed to always provide a way to recover from any failure mode that can result from software that's running on that hardware. Even bad firmware updates should be recoverable - what happens if you lose power mid-update?

Re: Booting Linux using UEFI can brick Samsung laptops

#20

So random academic question - Should it be literally possible for an OS to "brick" hardware even if the OS was intentionally designed to do just that? Now I know in this particular case Samsung wrote both the driver and the firmware, so it is easy to point blame here. But more broadly, should hardware be built/designed so it has a "fail safe" mode where it just won't allow its self to be damaged by OS/software instru…

The word is bugs. It's very hard, and almost impossible to fix all bugs. Code with no bugs is really code with no known bugs. Especially when dealing with C and assembly, different parts of the code can effect other parts in ways a programmer may not anticipate. You really need to get a 'safer' language to prevent certain types of bugs, especially with the "data and code share the same segments" model of C.

It isn't /just/ bugs. It is also the way we think about the relationship between the underlying hardware and the kernel/OS.

There is an inherent level of "trust" there. Which makes sense. But the question is: should that "trust" extend to permanent damage to the hardware/firmware?

For example, a lot of GPUs allow the OS to control fan speed. You can literally set the fan speed so low the GPU will over-heat and damage its self. That isn't a "bug" that is a "feature."

Again, we come back the expectations/relationship.

Post reply on HN