mjg59 | Microsoft aren't forcing Lenovo to block free operating systems

Entry tags:

advogato,
fedora

Microsoft aren't forcing Lenovo to block free operating systems

Update: Patches to fix this have been posted

There's a story going round that Lenovo have signed an agreement with Microsoft that prevents installing free operating systems. This is sensationalist, untrue and distracts from a genuine problem.

The background is straightforward. Intel platforms allow the storage to be configured in two different ways - "standard" (normal AHCI on SATA systems, normal NVMe on NVMe systems) or "RAID". "RAID" mode is typically just changing the PCI IDs so that the normal drivers won't bind, ensuring that drivers that support the software RAID mode are used. Intel have not submitted any patches to Linux to support the "RAID" mode.

In this specific case, Lenovo's firmware defaults to "RAID" mode and doesn't allow you to change that. Since Linux has no support for the hardware when configured this way, you can't install Linux (distribution installers will boot, but won't find any storage device to install the OS to).

Why would Lenovo do this? I don't know for sure, but it's potentially related to something I've written about before - recent Intel hardware needs special setup for good power management. The storage driver that Microsoft ship doesn't do that setup. The Intel-provided driver does. "RAID" mode prevents the Microsoft driver from binding and forces the user to use the Intel driver, which means they get the correct power management configuration, battery life is better and the machine doesn't melt.

(Why not offer the option to disable it? A user who does would end up with a machine that doesn't boot, and if they managed to figure that out they'd have worse power management. That increases support costs. For a consumer device, why would you want to? The number of people buying these laptops to run anything other than Windows is miniscule)

Things are somewhat obfuscated due to a statement from a Lenovo rep:This system has a Signature Edition of Windows 10 Home installed. It is locked per our agreement with Microsoft. It's unclear what this is meant to mean. Microsoft could be insisting that Signature Edition systems ship in "RAID" mode in order to ensure that users get a good power management experience. Or it could be a misunderstanding regarding UEFI Secure Boot - Microsoft do require that Secure Boot be enabled on all Windows 10 systems, but (a) the user must be able to manage the key database and (b) there are several free operating systems that support UEFI Secure Boot and have appropriate signatures. Neither interpretation indicates that there's a deliberate attempt to prevent users from installing their choice of operating system.

The real problem here is that Intel do very little to ensure that free operating systems work well on their consumer hardware - we still have no information from Intel on how to configure systems to ensure good power management, we have no support for storage devices in "RAID" mode and we have no indication that this is going to get better in future. If Intel had provided that support, this issue would never have occurred. Rather than be angry at Lenovo, let's put pressure on Intel to provide support for their hardware.

Threaded | Top-Level Comments Only

Intel could do better from a technical point, but one buys a Lenovo product, it is their responsibility to have the right pieces of hardware into place.
So they should be blamed for choosing an hardware with windows-only drivers.
They could also have added an option in the BIOS/UEFI that, once the secure boot has been disabled, allows the user to also disable this RAID mode.

I fought a similar system on a server board once, and actually got a system to install treating it as a RAID 0 with a single disk. It did not boot properly though. Since these are notebook systems with a single disk anyway, is that what they are treating the system as? (i.e. RAID 0 with a single disk) Is there any way to update GRUB to boot off of such a thing?

All that said, I think Intel absolutely should be held responsible, they certainly push themselves as a Linux friendly company, and disk controllers should be a basic device I should always be able to access.

So this is just an educated guess?

But then you insist that it's not Lenovo trying to lock out other operating systems. How do you know that? Did they give you the scoop?

Even if the device would get worse battery life (which we don't know that it would, and nobody who booted up Linux on the ISK model or Live on the ISK2 reported their laptop "melting"), it should be up to the user.

You say that if your guess is right, it's a cheap hack to work around crappy power management in Windows. Do we know Linux has crappy power management like Windows does?

Also,

If it was to prevent a clueless user from ending up in that situation where Windows wouldn't boot if they toggled it to AHCI mode, then why did Lenovo write code to make sure that if you used an EFI variable to set it, that it would switch it back to RAID? Is a user that doesn't know what they're doing likely to be in the EFI shell?

> So this is just an educated guess?

The change only prevents Linux being installed because Linux doesn't support modern hardware. It's easier to fix that than it is to get a vendor to push a firmware update.

> But then you insist that it's not Lenovo trying to lock out other operating systems. How do you know that? Did they give you the scoop?

Because they're not locking out other operating systems? Linux boots fine.

> Even if the device would get worse battery life (which we don't know that it would, and nobody who booted up Linux on the ISK model or Live on the ISK2 reported their laptop "melting"), it should be up to the user.

Why should it be up to the user? Should the user be able to program every memory timing option, even if by doing so they introduce occasional crashes? Should they be able to set every thermal threshold, even if by doing so they're reducing their hardware life expectancy? All hardware vendors restrict the options available to users.

> You say that if your guess is right, it's a cheap hack to work around crappy power management in Windows. Do we know Linux has crappy power management like Windows does?

It's a hack to work around the fact that Intel won't tell anyone else how to make power management work properly on Intel platforms, including Microsoft. Linux certainly does the wrong thing here.

You're attaching intent where there's no evidence of intent. If they only support RAID, the easiest way to implement that is just to force set it on boot

> So they should be blamed for choosing an hardware with windows-only drivers.

And when exactly did you discover you were a pre-cog?

"This system has a Signature Edition of Windows 10 Home installed. It is locked per our agreement with Microsoft."

You forgot another interpretation where Lenovo has signed an agreement with Microsoft that prevents installing free operating systems.

This is why when I build PCs I tend to use older hardware, e.g. the home server I just built is Haswell and not Skylake.

Bleeding edge hardware often takes a little time before the drivers in Linux are quality, especially when using enterprise distributions like CentOS.

For Linux laptops I always buy used, used means getting Linux to work on the model I choose is well documented.

"In this specific case, Lenovo's firmware defaults to "RAID" mode and doesn't allow you to change that. Since Linux has no support for the hardware when configured this way, you can't install Linux (distribution installers will boot, but won't find any storage device to install the OS to)."

This is a lie, you're obviously a schill.

Non-RAID settings were intentionally removed from the BIOS, and the RAID format used is non-standard.

A policy that would be entirely ineffective if we actually bothered to support the hardware.

Why would any manufacturer even consider isolating users? Your notion implies Lenovo went out of their way to screw the userbase. Regardless of how you feel, how can you see a decision like that being made?

This does not have a malicious intent. It's probably an oversight by engineering that didn't realistically see this as a plausible scenario on a consumer system, especially an ultrabook. Heck, I even install linux in VMs now rather than overwrite the host OS / dual-boot.

Yeah, sure. The guy who was employed by Red Hat and worked (and continues to discuss) on getting UEFI secure boot and is fully aware of the ways vendors can "lock out" free operating systems is a shill.

Lenovo made sane (although disagreeable as far as the Linux community is concerned) decisions with regards to supporting a consumer device, Intel has drivers for the RAID mode in their storage controller on Windows and that's what Lenovo ships and supports on the device. Manufacturers not giving a damn about Linux support and using hardware and configurations that isn't supported under anything but Windows at launch is hardly new (remember when Dell launched the updated XPS13 that moved a bunch of stuff to an I2C bus that wasn't supported by the Linux kernel for some time?)

This isn't the first time a "RAID" controller hasn't been supported under Linux, it's been less frequent because most of the time these were in workstation or server gear where there was incentive to provide support for something other than Windows. This is a consumer device, the vast majority of consumers just use Windows on their systems and OEM's have no reason to support anything else 99% of the time. Go yell at Intel and get them to either provide drivers or specifications so someone who wants to can do it.

Yes, I'm sure Matthew is just raking in those sweet shill dollars from MS, they obviously pay kernel developers to infiltrate Linux and invent over-complicated lies that placate the >1% of people who use Linux on their laptops.

It couldn't be that a support rep from Lenovo has no idea how to respond to a question that's 10,000 metres above their pay grade, and therefore got it wrong. Nope, must be a conspiracy.

When WILL he discover he's a pre-cog, rather.

Thanks a lot for doing this write-up, this clarifies things greatly. After arguing with a friend, I was wondering though where the requirement 'the user must be able to manage the key database' originates. Is this part of the Secure Boot specs or is this only required for Microsoft's Windows certification? Thanks!

I have skylake Dell XPS 15 Infinity Edge. It came with NVMe hard drive configured in a RAID setting which was not recognised by the Ubuntu installer. In the BIOS settings I was able to change that to something normal instead (it was listed as AHCI or some such), after that NVMe based installation worked with Ubuntu, but Windows 10 failed to boot. To resolve that, I had to reboot Windows 10 in safety mode, switch from raid to AHCI, boot into safety mode again, which I guess regenerated the "kernel modules included in the Windows boot process" or some such. After that, both Ubuntu and Windows 10 boot happily ever after. This is unfortunately well documented https://en.wikipedia.org/wiki/Advanced_Host_Controller_Interface#Boot_issues I wish windows would always include AHCI driver and/or the OEMs/Vendors did. Are we sure that it's not just the standard Intel Matrix Raid configuration which is supported by MDADM? Ubuntu Desktop installer doesn't support Intel Matrix RAID configuration out of the box at the time.

So much misinformation on a single page.

It's not even the wrong hardware, though. This hardware from Intel supports AHCI. However, the Lenovo BIOS has RAID selected as default (for single-drive, believe it or not!), and not only that -- it locks you out of changing it back to AHCI.

The option to do so is on the Advanced page of the BIOS, which was locked out by a small modification Lenovo made (adding two lines of code -- a conditional goto/jmp).

I agree that the blame falls squarely on Lenovo, but for very different (and more correct) reasons.

GRUB can certainly boot off the thing, but the problem is that the kernel itself cannot detect the drive at all while it's in RAID mode (and it's currently STUCK in RAID mode, even though the Intel hardware fully supports run-of-the-mill vanilla AHCI, because of Lenovo's short-sighted and quite intentional BIOS modification that locks users out from changing their BIOS setting).

> The real problem here is that Intel do very little to ensure that free operating systems work well on their consumer hardware

This seems a little extreme. As hardware vendors go, Intel do more to get their hardware supported upstream than a lot of others. Sure, there are areas they could do better, but still.

Lenovo's decision to disable the standard BIOS/UEFI options that allow changing the disk controller mode is the real blocker to having the hardware work. Few people would want to use fakeraid on Linux given the choice anyway.

The BIOS that has locked the AHCI is currently cryptographically signed by Lenovo.

Currently, one user had successfully installed Linux on their device by manually flashing their BIOS by soldering a chip programmer onto the actual chip.

They flashed a version they manually modified the BIOS by reverse engineering and hacking the code to get around Lenovo's goto stmt, restoring uesr access to the Advanced settings page.

So, is this your idea of supporting it ourselves?

It wasn't even an oversight though, Lenovo had to intentionally modify the BIOS themselves to lock themselves out of the option that allows Intel's hardware to be supported by Linux (as it stands, Intel's RAID controller _does_ support Linux out of the box, BEFORE Lenovo mucked with it and locked everybody out).

> The BIOS that has locked the AHCI is currently cryptographically signed by Lenovo.

Cryptographically signed firmwares are an Intel requirement and have been since Sandy/Ivy Bridge. Go look at Dell or HP and you'll find the exact same requirements for UEFI updates.

> Currently, one user had successfully installed Linux on their device by manually flashing their BIOS by soldering a chip programmer onto the actual chip.

Yes, this is the only way to bypass the firmware update signature check. Because by flashing the actual SPI EEPROM the check is not executed.

> So, is this your idea of supporting it ourselves?

Where on earth did the author ever imply or state that?

Flashing a modified firmware via SPI is the only known method for newer Intel platforms due to the signature checks performed during a normal firmware update.

Sometimes vendors are careless/lazy and people find other ways to flash modified firmwares. In cases where vendors don't screw up the reference firmware enough to nullify the security checks, you need to flash it manually.

Go read about this yourself (free eBook on Intel platform security): www.apress.com/9781430265719

Vendor Lock-in.

>Why should it be up to the user? Should the user be able to program every >memory timing option, even if by doing so they introduce occasional crashes? >Should they be able to set every thermal threshold, even if by doing so >they're reducing their hardware life expectancy? All hardware vendors >restrict the options available to users.

Of course, the user should be able to do all that. Whose machine is it, anyway?

Threaded | Top-Level Comments Only

Page 1 of 4

Microsoft aren't forcing Lenovo to block free operating systems

Shared blame

RAID level?

no subject

no subject

no subject

no subject

Re: Shared blame

no subject

Linux certainly does the wrong thing here.

Liar.

no subject

Re: Liar.

Re: Liar.

Re: Liar.

Re: Shared blame

Microsoft's Secure Boot requirements

Dell XPS 15 InfinityEdge

Re: Shared blame

Re: RAID level?

no subject

DIY support

Re: Liar.

Re: DIY support

Re: Liar.

easy answer