6 ms·

Booting Linux using UEFI can brick Samsung laptops

103 points by fuzzix 14y ago

RexRollman 14y ago
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.
- xmodem 14y ago
  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 the Surface Pro would have bugs anything like this, for example.
  - ygra 14y ago
    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.
    - demetris 14y ago
      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 firmware setup without possession of PKpriv. A Windows Server may also disable Secure Boot remotely using a strongly authenticated (preferably public-key based) out-of-band management connection, such as to a baseboard management controller or service processor. Programmatic disabling of Secure Boot either during Boot Services or after exiting EFI Boot Services MUST NOT be possible. Disabling Secure Boot must not be possible on ARM systems. QUOTATION END 0. http://msdn.microsoft.com/en-US/library/windows/hardware/jj128256 http://msdn.microsoft.com/en-US/library/windows/hardware/jj1...
      - beerscout 14y ago
        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.
    - xmodem 14y ago
      Quite likely it will be locked down. Even if it's not, however, I don't think Microsoft's EFI implementation will be so crap that drivers can brick the device.
    - RexRollman 14y ago
      It's sad that everybody wants to lock everything down. It's like no one learned anything from the success of the PC.
      - aw3c2 14y ago
        sadly the success of locked down.apple devices stands orthogonal to it.
      - tinco 14y ago
        The PC was only a success for the market as a whole. The setters of the standards did not profit from it at all and even went (close to) bankruptcy because of it. Contrast this closed hw architectures like Nintendo and Apple produce. No consumer freedom but incredible profit margins. Note that modern macs are in fact PC's with just minor modifications so they profit from the PC economies of scale while still locking their customers into their hardware platform.
      - davidp 14y ago
        What if lockdown worked in such a way that you could lock it down to only run your Linux kernels? E.g. load up your own certificate in the TPM and use that for signing when you build. In that case it would be a security feature -- another line of defense against bootloader malware and/or adversaries in physical possession of your machine. (I don't know how technically feasible that is; I know Canonical and others are looking at having their own cert so at least their unmodified kernels can run, but I don't know the mechanism for how that interacts with already-released UEFI machines.) The point is that technologies like this are a double-edged sword, not evil in themselves. A similar argument is made by Linus himself for sticking with GPL v2 instead of moving to GPL v3, which outlaws certain DRM-related uses; he's more interested in providing a functioning mechanism, and leaving the policy-setting to others.
      - rbanffy 14y ago
        The PC was a success mostly for Microsoft. With the commoditization of hardware around a single software option, PC makers were squeezed and their margins are exceedingly thin. It's the "thin slice of a larger pie" metaphor. It's just that Microsoft has the whole OS pie, while every hardware maker has a vanishingly thin slice of it.
  - meaty 14y ago
    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.
- daeken 14y ago
  I am completely and utterly baffled by this statement. Do you realize how many man-years have been spent working around BIOS bugs over the years? Get any kernel developer a drink, then just say the word 'BIOS'; your opinion of UEFI will change pretty rapidly. I've dealt with kernel dev for BIOS systems, CSM development for UEFI, etc etc. I'll stick with UEFI, even if it does still have some growing pains.
  - nathell 14y ago
    > Do you realize how many man-years have been spent working around BIOS bugs over the years? Get any kernel developer a drink, then just say the word 'BIOS'; your opinion of UEFI will change pretty rapidly. Isn't it the case that once the kernel is fully booted, up and running, it bypasses BIOS entirely and talks directly to the hardware? Have all those bugs you mention been related to the booting process itself (constituting a relatively tiny part of the kernel)?
    - gizmo686 14y ago
      I do not know to what extent the OS bypasses the BIOS, but it is not completly. If you look in the linux kernel config, you will see an option to control how much RAM is reserved for BIOS. Also, on (many?) Dells, Fn+Shift+15324 followed by Fn+r brings up BIOS thermal controls [1]. I have verified this on an Inspiron 1420, in Windows 7 and Ubuntu 12.10 (kernel 3.5.0-21-generic). [1]http://ubuntuforums.org/showthread.php?t=1684657 http://ubuntuforums.org/showthread.php?t=1684657
  - Locke1689 14y ago
    daeken is absolutely right. BIOS is a fucking nightmare. Real mode (or the lack of it in Intel VT-x) still wakes me up in a cold sweat at night.
- UnoriginalGuy 14y ago
  Everyone understood BIOS? Really? I thought one of the issues with BIOS that almost nobody understood how it actually worked any more. Large chunks of it are tens of years old and the people who created them have moved on...
albertzeyer 14y ago
Just disabling the driver doesn't seem like the ultimate solution... Have they even identified the problem itself? Why aren't they just fixing it? Is it on the hardware site or in the driver software? They should fix that.
Breakthrough 14y ago
I was about to pick one of these laptops up late last year until I happened to stumble across that very bug report myself: https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557?comments=all https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557?comme... Everyone seems to have it working fine with UEFI disabled, and several people have noted the vendor or Samsung has provided a replacement in the cases where it was bricked. At least in their darkest hours, Linux users can still put on a smile: "[...] they changed the motherboard and it's working again now. I won't try to install Ubuntu again though. The whole process took about 2 weeks."
UnoriginalGuy 14y ago
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.
- keeperofdakeys 14y ago
  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.
  - UnoriginalGuy 14y ago
    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.
    - keeperofdakeys 14y ago
      It's always said "hardware is expensive, software is cheap; so do as much as you can in software". When you also remember that we give an OS full control of all hardware, it's the natural conclusion that things like this can happen. Although, this is changing, subtly. Now you have harddrives and SSDs that run their own software that can't be controlled by the OS. The firmware may even lie to the OS, for example harddrives might tell the OS "I've written this data", when it might actually be caching it for more efficient writing. Unfortunately computes are nearly infinitely complex these days, with so many layers developed by many people.
guilloche 14y ago
Bios is outdated, but UEFI is even worse and became such a mess. It did not fix BIOS's issues and is unnecessary complicated. The efforts are regretfully wasted on UI.
- keeperofdakeys 14y ago
  Sorry, but the BIOS had many issues, and UEFI provided a solution to them, even if it wasn't an inherently good system. 1.The BIOS isn't portable, you can compile UEFI for any platform by porting a small base module. Everything uses this module, so the compiler will take care of the rest. 2. BIOS was a heap of 16bit assembly code, with a small memory space. It was quite hard to add any kind of complex functionality. 3. You couldn't use a boot volume greater than 2TB due to MBR. A new one wasn't added because of number 2. 4. UEFI is more like a micro kernel then a generic BIOS, and provides the functionality for vendors to write 'better' interfaces. Here the interfaces aren't actually provided in the official UEFI sample implementation, and most can be arguably called worse then an average BIOS interface. However, you have to acknowledge the capability is there. 5. It added a framework for kernel verification (unlike what some people think, it only verifies the UEFI firmware and the kernel/boot loader it loads directly). The direction that Microsoft is taking it is quite unfortunate, but it's actually a good feature. 6. It has a limited capability as a boot loader, allowing multiple operating systems to be started directly. These are all features that aren't present in the BIOS, that UEFI has fixed. Unfortunately the current implementation has many bugs, and many features are arguably implemented badly. However is was created to fix real problems, and has been undeniably successful at that. At a linux conference there was a talk about all this, from someone quite involved with the UEFI creation process. If you are interested, the recording will probably be released in a few weeks. There is also a talk from the previous year by Matthew Garrett (the guy who does UEFI stuff in Linux), talking about all the bugs present in UEFI, which is an entertaining watch, https://www.youtube.com/watch?v=V2aq5M3Q76U https://www.youtube.com/watch?v=V2aq5M3Q76U.
  - RexRollman 14y ago
    It sounds like UEFI is over-engineered. All I want is for something to initialize the hardware and hand over for booting.
speeder 14y ago
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.
nextparadigms 14y ago
Why can't they just use Google's method for the Chromebooks? I think it allows to easily install any other OS as soon as you physically disable the bootloader with a switch on your laptop.
- wmf 14y ago
  Because they're not as smart as Google. Most hardware vendors budget as little as possible for firmware, and the result is predictable.
josteink 14y ago
The biggest problem with UEFI was that someone decided to mess it up and complicate it by adding DRM and signing-requirements. It's the result of computing following designs mandated by the MPAA/RIAA. Who on earth thought that could turn out OK?
- Locke1689 14y ago
  None of this is accurate.
- dmm 14y ago
  UEFI has _NOTHING_ to do with DRM.
telent 14y ago
As stories go, this one would be a lot better if it actually linked to some technical information about the bug. Does anyone have a reference for what the samsung_laptop driver's doing that is so bad? The kernel bugzilla link (#47121) that someone has speculated is related is a boot panic, not a complete bricking, so while it _may_ be the same thing ... https://bugzilla.kernel.org/buglist.cgi?quicksearch=samsung-laptop https://bugzilla.kernel.org/buglist.cgi?quicksearch=samsung-... # but nothing else in there looks to be any closer either
protomyth 14y ago
I do so miss OpenFirmware (forth and all).
noonespecial 14y ago
Looks like a roadmap for some truly nasty malware. This should not be possible in any circumstance. It's like having a history eraser button on your spaceship.
mixmastamyk 14y ago
U/EFI is an interesting subject. Yes, of course better than the primitive bios it replaced. Interesting in that you can can play with a new OS. But, Intel went out and invented another operating system? Why, when embedded Linux (&coreboot) already existed? with a full stack of software? Would be nice to have a web browser available from the firmware for downloading drivers, etc. I ran Linux on an Itanium at work circa 2003 so it was definitely doable. Is the answer that MS wouldn't allow it? Or is there another reason?
spyder 14y ago
Just fixing the driver doesn't seems a safe solution, because then malwares still can do the same to brick the hardware, isn't? Sure nowadays most malwares don't want to brick your hardware because ads are more profitable but it can still happen. It's understandable that new technologies have more serious bugs than decades old ones and hopefully it will be fixed in UEFI soon, but this shows why you have too be careful with new technologies if you are an early adpoter.
nogoodnik 14y ago
In a few weeks, "Don't buy Samsung laptops" is what I will remember from this.

103 points by fuzzix 14y ago

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.

xmodem 14y ago
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 the Surface Pro would have bugs anything like this, for example.
- ygra 14y ago
  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.
  - demetris 14y ago
    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 firmware setup without possession of PKpriv. A Windows Server may also disable Secure Boot remotely using a strongly authenticated (preferably public-key based) out-of-band management connection, such as to a baseboard management controller or service processor. Programmatic disabling of Secure Boot either during Boot Services or after exiting EFI Boot Services MUST NOT be possible. Disabling Secure Boot must not be possible on ARM systems. QUOTATION END 0. http://msdn.microsoft.com/en-US/library/windows/hardware/jj128256 http://msdn.microsoft.com/en-US/library/windows/hardware/jj1...
    - beerscout 14y ago
      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.
  - xmodem 14y ago
    Quite likely it will be locked down. Even if it's not, however, I don't think Microsoft's EFI implementation will be so crap that drivers can brick the device.
  - RexRollman 14y ago
    It's sad that everybody wants to lock everything down. It's like no one learned anything from the success of the PC.
    - aw3c2 14y ago
      sadly the success of locked down.apple devices stands orthogonal to it.
    - tinco 14y ago
      The PC was only a success for the market as a whole. The setters of the standards did not profit from it at all and even went (close to) bankruptcy because of it. Contrast this closed hw architectures like Nintendo and Apple produce. No consumer freedom but incredible profit margins. Note that modern macs are in fact PC's with just minor modifications so they profit from the PC economies of scale while still locking their customers into their hardware platform.
    - davidp 14y ago
      What if lockdown worked in such a way that you could lock it down to only run your Linux kernels? E.g. load up your own certificate in the TPM and use that for signing when you build. In that case it would be a security feature -- another line of defense against bootloader malware and/or adversaries in physical possession of your machine. (I don't know how technically feasible that is; I know Canonical and others are looking at having their own cert so at least their unmodified kernels can run, but I don't know the mechanism for how that interacts with already-released UEFI machines.) The point is that technologies like this are a double-edged sword, not evil in themselves. A similar argument is made by Linus himself for sticking with GPL v2 instead of moving to GPL v3, which outlaws certain DRM-related uses; he's more interested in providing a functioning mechanism, and leaving the policy-setting to others.
    - rbanffy 14y ago
      The PC was a success mostly for Microsoft. With the commoditization of hardware around a single software option, PC makers were squeezed and their margins are exceedingly thin. It's the "thin slice of a larger pie" metaphor. It's just that Microsoft has the whole OS pie, while every hardware maker has a vanishingly thin slice of it.
- meaty 14y ago
  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.
daeken 14y ago
I am completely and utterly baffled by this statement. Do you realize how many man-years have been spent working around BIOS bugs over the years? Get any kernel developer a drink, then just say the word 'BIOS'; your opinion of UEFI will change pretty rapidly. I've dealt with kernel dev for BIOS systems, CSM development for UEFI, etc etc. I'll stick with UEFI, even if it does still have some growing pains.
- nathell 14y ago
  > Do you realize how many man-years have been spent working around BIOS bugs over the years? Get any kernel developer a drink, then just say the word 'BIOS'; your opinion of UEFI will change pretty rapidly. Isn't it the case that once the kernel is fully booted, up and running, it bypasses BIOS entirely and talks directly to the hardware? Have all those bugs you mention been related to the booting process itself (constituting a relatively tiny part of the kernel)?
  - gizmo686 14y ago
    I do not know to what extent the OS bypasses the BIOS, but it is not completly. If you look in the linux kernel config, you will see an option to control how much RAM is reserved for BIOS. Also, on (many?) Dells, Fn+Shift+15324 followed by Fn+r brings up BIOS thermal controls [1]. I have verified this on an Inspiron 1420, in Windows 7 and Ubuntu 12.10 (kernel 3.5.0-21-generic). [1]http://ubuntuforums.org/showthread.php?t=1684657 http://ubuntuforums.org/showthread.php?t=1684657
- Locke1689 14y ago
  daeken is absolutely right. BIOS is a fucking nightmare. Real mode (or the lack of it in Intel VT-x) still wakes me up in a cold sweat at night.
UnoriginalGuy 14y ago
Everyone understood BIOS? Really? I thought one of the issues with BIOS that almost nobody understood how it actually worked any more. Large chunks of it are tens of years old and the people who created them have moved on...

albertzeyer 14y ago

Just disabling the driver doesn't seem like the ultimate solution... Have they even identified the problem itself? Why aren't they just fixing it? Is it on the hardware site or in the driver software? They should fix that.

Breakthrough 14y ago

I was about to pick one of these laptops up late last year until I happened to stumble across that very bug report myself: https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557?comments=all https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557?comme... Everyone seems to have it working fine with UEFI disabled, and several people have noted the vendor or Samsung has provided a replacement in the cases where it was bricked. At least in their darkest hours, Linux users can still put on a smile: "[...] they changed the motherboard and it's working again now. I won't try to install Ubuntu again though. The whole process took about 2 weeks."

UnoriginalGuy 14y ago

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.

keeperofdakeys 14y ago
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.
- UnoriginalGuy 14y ago
  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.
  - keeperofdakeys 14y ago
    It's always said "hardware is expensive, software is cheap; so do as much as you can in software". When you also remember that we give an OS full control of all hardware, it's the natural conclusion that things like this can happen. Although, this is changing, subtly. Now you have harddrives and SSDs that run their own software that can't be controlled by the OS. The firmware may even lie to the OS, for example harddrives might tell the OS "I've written this data", when it might actually be caching it for more efficient writing. Unfortunately computes are nearly infinitely complex these days, with so many layers developed by many people.

guilloche 14y ago

Bios is outdated, but UEFI is even worse and became such a mess. It did not fix BIOS's issues and is unnecessary complicated. The efforts are regretfully wasted on UI.

keeperofdakeys 14y ago
Sorry, but the BIOS had many issues, and UEFI provided a solution to them, even if it wasn't an inherently good system. 1.The BIOS isn't portable, you can compile UEFI for any platform by porting a small base module. Everything uses this module, so the compiler will take care of the rest. 2. BIOS was a heap of 16bit assembly code, with a small memory space. It was quite hard to add any kind of complex functionality. 3. You couldn't use a boot volume greater than 2TB due to MBR. A new one wasn't added because of number 2. 4. UEFI is more like a micro kernel then a generic BIOS, and provides the functionality for vendors to write 'better' interfaces. Here the interfaces aren't actually provided in the official UEFI sample implementation, and most can be arguably called worse then an average BIOS interface. However, you have to acknowledge the capability is there. 5. It added a framework for kernel verification (unlike what some people think, it only verifies the UEFI firmware and the kernel/boot loader it loads directly). The direction that Microsoft is taking it is quite unfortunate, but it's actually a good feature. 6. It has a limited capability as a boot loader, allowing multiple operating systems to be started directly. These are all features that aren't present in the BIOS, that UEFI has fixed. Unfortunately the current implementation has many bugs, and many features are arguably implemented badly. However is was created to fix real problems, and has been undeniably successful at that. At a linux conference there was a talk about all this, from someone quite involved with the UEFI creation process. If you are interested, the recording will probably be released in a few weeks. There is also a talk from the previous year by Matthew Garrett (the guy who does UEFI stuff in Linux), talking about all the bugs present in UEFI, which is an entertaining watch, https://www.youtube.com/watch?v=V2aq5M3Q76U https://www.youtube.com/watch?v=V2aq5M3Q76U.
- RexRollman 14y ago
  It sounds like UEFI is over-engineered. All I want is for something to initialize the hardware and hand over for booting.

speeder 14y ago

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.

nextparadigms 14y ago

Why can't they just use Google's method for the Chromebooks? I think it allows to easily install any other OS as soon as you physically disable the bootloader with a switch on your laptop.

wmf 14y ago
Because they're not as smart as Google. Most hardware vendors budget as little as possible for firmware, and the result is predictable.

josteink 14y ago

The biggest problem with UEFI was that someone decided to mess it up and complicate it by adding DRM and signing-requirements. It's the result of computing following designs mandated by the MPAA/RIAA. Who on earth thought that could turn out OK?

Locke1689 14y ago
None of this is accurate.
dmm 14y ago
UEFI has _NOTHING_ to do with DRM.

telent 14y ago

As stories go, this one would be a lot better if it actually linked to some technical information about the bug. Does anyone have a reference for what the samsung_laptop driver's doing that is so bad? The kernel bugzilla link (#47121) that someone has speculated is related is a boot panic, not a complete bricking, so while it _may_ be the same thing ... https://bugzilla.kernel.org/buglist.cgi?quicksearch=samsung-laptop https://bugzilla.kernel.org/buglist.cgi?quicksearch=samsung-... # but nothing else in there looks to be any closer either

protomyth 14y ago

I do so miss OpenFirmware (forth and all).

noonespecial 14y ago

Looks like a roadmap for some truly nasty malware. This should not be possible in any circumstance. It's like having a history eraser button on your spaceship.

mixmastamyk 14y ago

U/EFI is an interesting subject. Yes, of course better than the primitive bios it replaced. Interesting in that you can can play with a new OS. But, Intel went out and invented another operating system? Why, when embedded Linux (&coreboot) already existed? with a full stack of software? Would be nice to have a web browser available from the firmware for downloading drivers, etc. I ran Linux on an Itanium at work circa 2003 so it was definitely doable. Is the answer that MS wouldn't allow it? Or is there another reason?

spyder 14y ago

Just fixing the driver doesn't seems a safe solution, because then malwares still can do the same to brick the hardware, isn't? Sure nowadays most malwares don't want to brick your hardware because ads are more profitable but it can still happen. It's understandable that new technologies have more serious bugs than decades old ones and hopefully it will be fixed in UEFI soon, but this shows why you have too be careful with new technologies if you are an early adpoter.

nogoodnik 14y ago

In a few weeks, "Don't buy Samsung laptops" is what I will remember from this.