Microsoft aren't forcing Lenovo to block free operating systems

[mjg59]

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.

Comments

Re: Storm in a teacup

[cowbutt]

"There's nothing in the kernel that binds to the PCI device when in this mode."

Hmm, maybe that's for the NVMe SSD - certainly the last time I booted a Linux distro on my X99 system with RST RAID0 and RAID1 arrays, they were picked up and assembled (to my mild surprise). No SRT, though.

[(Anonymous)]

How does it prevent reinstallation?

Its not hard to add a disk driver from a second usb stick or bake it into the install media.

What does "RAID" actually do?

[(Anonymous)]

Does anyone have concrete information about what "RAID" does. For example, lspci -vvvnn output from an affected system might be nice.

--luto

[(Anonymous)]

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?

Uh, yes?
"Hell yes", even?
It's the user's bloody machine. They have every right to smash it with a sledgehammer, should they desire.

Making a conscious decision to trade off a small amount of life expectancy for the ability to use it the way they want to during that life? Why would you even question that?

[(Anonymous)]

intel, lenovo, nvidia - the wold can safely ignore all of such dumb companies. I do not see any reason wasting time to the problems with their hardware.

Re: What does "RAID" actually do?

[mjg59]

It should be exactly the same as you get when you enable "RAID" on the Skylake XPS 13s.

Re: Microsoft's Secure Boot requirements

[(Anonymous)]

Windows on ARM flopped. Nobody is making those systems anymore. So they decided to lock us out of our PCs instead. Not with Secure Boot, but with other means.

Re: What does "RAID" actually do?

[(Anonymous)]

https://forums.lenovo.com/t5/Linux-Discussion/Yoga-900-13ISK2-BIOS-update-for-setting-RAID-mode-for-missing/m-p/3436876#M8406

Someone compared outputs with a system that one person was able to mod to go into AHCI mode.

Re: What does "RAID" actually do?

[(Anonymous)]

Hi, this is copy/paste from my post on the Lenovo forum; apologies in advance for my being clueless about dreamwidth post formatting...

nb:

• by "patched" and "unpatched" I mean with/without the BIOS mod - the "patched" one being in "AHCI" mode.
  
• systems were running different distros/versions of lspci, so minor formatting and naming differences
  
• some "randomly" assigned stuff like interrupts and memory locations also differ.
  
• this is the "diff"; I can post a full patched/unpatched lspci if you really want.
  

In the unpatched stock dump a 'RAID' controller appears:


00:17.0 RAID bus controller [0104]: Intel Corporation 82801 Mobile SATA Controller [RAID mode] [8086:282a] (rev 21)
Subsystem: Lenovo 82801 Mobile SATA Controller [RAID mode] [17aa:381c]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 16
Region 0: Memory at a12a8000 (32-bit, non-prefetchable) [size=32K]
Region 1: Memory at a12be000 (32-bit, non-prefetchable) [size=256]
Region 2: I/O ports at 3080 [size=8]
Region 3: I/O ports at 3088 [size=4]
Region 4: I/O ports at 3060 [size=32]
Region 5: Memory at a1200000 (32-bit, non-prefetchable) [size=512K]
Capabilities: [d0] MSI-X: Enable+ Count=10 Masked-
Vector table: BAR=0 offset=00000000
PBA: BAR=1 offset=00000000
Capabilities: [70] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a8] SATA HBA v1.0 BAR4 Offset=00000004
Kernel driver in use: ahci
Kernel modules: ahci



that "slot" (00:17.0) doesn't appear in the patched system.



conversely, in the patched system there is a PCI bridge that doesn't appear in the unpatched system:


00:1d.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #9 [8086:9d18] (rev f1) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 124
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: 00003000-00003fff
Memory behind bridge: a1000000-a10fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 256 bytes, PhantFunc 0
ExtTag- RBE+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #9, Speed 8GT/s, Width x4, ASPM L1, Exit Latency L0s <1us, L1 <16us
ClockPM- Surprise- LLActRep+ BwNot+ ASPMOptComp+
LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 8GT/s, Width x4, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
Slot #8, PowerLimit 25.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet- LinkState+
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range ABC, TimeoutDis+, LTR+, OBFF Not Supported ARIFwd+
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR+, OBFF Disabled ARIFwd-
LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete+, EqualizationPhase1+
EqualizationPhase2+, EqualizationPhase3+, LinkEqualizationRequest-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee00278 Data: 0000
Capabilities: [90] Subsystem: Lenovo Device [17aa:3805]
Capabilities: [a0] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [100 v0] #00
Capabilities: [140 v1] Access Control Services
ACSCap: SrcValid+ TransBlk+ ReqRedir+ CmpltRedir+ UpstreamFwd- EgressCtrl- DirectTrans-
ACSCtl: SrcValid- TransBlk- ReqRedir- CmpltRedir- UpstreamFwd- EgressCtrl- DirectTrans-
Capabilities: [220 v1] #19
Kernel driver in use: pcieport
Kernel modules: shpchp


And, of finally, here's the bad boy we all want - the Samsung drive on a PCI bus that doesn't appear in the unpatched system:


03:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller [144d:a802] (rev 01) (prog-if 02 [NVM Express])
Subsystem: Samsung Electronics Co Ltd Device [144d:a801]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 16
NUMA node: 0
Region 0: Memory at a1000000 (64-bit, non-prefetchable) [size=16K]
Region 2: I/O ports at 3000 [size=256]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable- Count=1/8 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [70] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ SlotPowerLimit 25.000W
DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed 8GT/s, Width x4, ASPM L1, Exit Latency L0s <4us, L1 <64us
ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 8GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR+, OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR+, OBFF Disabled
LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete+, EqualizationPhase1+
EqualizationPhase2+, EqualizationPhase3+, LinkEqualizationRequest-
Capabilities: [b0] MSI-X: Enable+ Count=9 Masked-
Vector table: BAR=0 offset=00003000
PBA: BAR=0 offset=00002000
Capabilities: [100 v2] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [148 v1] Device Serial Number 00-00-00-00-00-00-00-00
Capabilities: [158 v1] Power Budgeting <?>
Capabilities: [168 v1] #19
Capabilities: [188 v1] Latency Tolerance Reporting
Max snoop latency: 3145728ns
Max no snoop latency: 3145728ns
Capabilities: [190 v1] L1 PM Substates
L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
PortCommonModeRestoreTime=10us PortTPowerOnTime=10us
Kernel driver in use: nvme
Kernel modules: nvme


So my completey unfounded speculation at this point is that that "RAID/AHCI" BIOS switch is changing the mode of whatever chip that PCI bridge lives in for some reason... to aggregate attached NVMe devices as a RAID?? dunno.

your efforts to shed lights are welcome.

cheers,
HH

[(Anonymous)]

Someone on Reddit suggested that since Linux doesn't use BIOS calls for anything and addresses the hardware in native mode, and the hardware still supports AHCI native mode, that someone should "teach GRUB read-only RAID support" and then have the kernel set to switch the hardware out of RAID and into AHCI native mode as soon as it is loaded.

Is this an option? Sorry if this is obviously not an answer.

As for the power management thing, Dell lets you turn off the same "RAID" mode and boot Linux. What kind of runtime loss are we talking here? Can't be that bad or someone would have said something. SSDs use like 2 watts? Even if it never goes into power saving mode, it's about like turning your backlight up 5%, right?

[mjg59]

If you wanted to try that, the best place to do it would be the UEFI setup code in the kernel under arch/x86/boot/compressed/eboot.c - that way you can do it independent of bootloader. Grub's able to read files anyway since it's using the firmware calls to do that.

The power management thing isn't about the SSD itself, it's about ensuring that the controller is programmed correctly so that the entire CPU package can enter deep sleep states. Modern systems should idle at around 4W at most, so small amounts make abig difference here.

[(Anonymous)]

Is this something that can be put in the mainline kernel so that at least it does _work_ at least as well as the XPS while we're waiting for a better solution?

[mjg59]

If the firmware hasn't locked the control bit and if the hardware is ok with suddenly being reconfigured, sure, that ought to work. Doing it in eboot.c means you're doing it before any PCI enumeration has occurred, which makes it more likely that things will work out well.

[(Anonymous)]

Is there a way you could get this upstream so we can try it out? I'm sorry, but it's above my head. :)

[mjg59]

I'll take a quick look at the 10-series chipset docs to see if it's documented, and if so I'll throw a quick patch together - but I'm probably not going to try pushing it upstream, I'm afraid. If it does work, I'm fine with anybody else doing so.

[(Anonymous)]

You'd probably know the people to talk to, right? Could you point me in the right direction there?

[marahmarie]

"Should they have to" would've been better than "Should they be able to" unless Mat's suddenly against the very thing he does all the time - taking things apart/changing settings himself.

As someone who believes in tinkering with whatever we like, my mouth sort of dropped open at whether or not we should be able to. The day we can't is the day I will smash the very items that keep me from doing so with a sledgehammer.

This post reeks of hypocrisy and inaccuracy - or at least a total lack of editing.

installed Linux on about 15 laptops, only one failed: a Lenovo

[(Anonymous)]

I installed Linux on about 15 laptops, only one failed: a Lenovo. While this looks like an attention seeking headline, it's true.

The first laptop I installed Linux on was about 15 odd years ago - while I had some trouble I got it going eventually. Most follow up laptops where from a variety of suppliers (dell, toshiba, acer etc) and I never had a problem to get any of the hardware working.

The last two laptops are two rather new laptops, both with UEFI/LEGACY, both with AHCI, both with INTEL hardware and all INTEL hardware known to work.

One is a Lenovo Yoga, the other one is a Dell XPS 12.

It took me about 1 hour to get it to go on the Dell, I did that in a number of steps. I first made some space at the end of the drive creating a 30GB space, then tried Fedora 23 without UEFI in Legacy mode - it worked first go.
I then wiped that partition again, changed back to full UEFI, installed Fedora 23 with full UEFI enabled. Grub has taken over and I can easily switch between Linux and Windows 10, all hardware working albeit the touch pad being touchy - but that's the case too in Win10.

Not so the Lenovo - I tried everything for a week. I did RTFM, I read so many articles on the web, I followed every trick of the trade I have learned with myriads of kernel switches, debugging - you name it. I tried.

I have given up, my first failure to ever get a computer to work with Linux.

Luckily there is VmWare and Kali Linux.

Sorry, Lenovo sucks.

[mjg59]

There's "should this be possible" and there's "should this be presented in an easy to access way". Should machines be designed such that it's absolutely impossible for users to modify every single piece of software on them? No. Should machines be designed such that it's trivial for users to reconfigure them in ways that stop them from working? Also no. Nobody ships systems that offer the full range of chipset tweakables in their firmware setup, and that's the correct choice for vendors to make.

not sure

[(Anonymous)]

Not sure. Haswell power management in 4.6 is still very sucky.

Powering the secret: secret powers

[(Anonymous)]

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

Maybe Intel has something to hide (or not allowed to share) in this power management? Knowing it would allow people to not enable something that it's not supposed to be known by.. people? There is so much we can't trust in Intel.

Re: Dell XPS 15 InfinityEdge

[(Anonymous)]

Wouldn't that make the device slower? I haven't use the Ubuntu (or any other) installer for a while but maybe it runs an older kernel without the NVMe driver?

Lenovo Thnikpad x250 boots fine with at least 8 distro and power is fine

[unixbhaskar.wordpress.com]

From last August I don't feel any bigger trouble with it.All the installation went well. Power management ,well, we knew it. And we can live with it.In fact, did so many tweak and so many thing to get better battery time...still..

Anyway I have very little idea how to resolve that...

Lenovo.....

[(Anonymous)]

As far as I can tell? this isn't even an issue. Go out and buy LAST YEAR'S model of the damn machine, which should be able to install whatever it is you want on it. Then when sales of this "most recent" PC go way down?...then maybe they'll pull it from store shelves and online retailers, realizing that now more than ever? the one thing people want most? isn't flash, isn't bling, isn't cute names or matching headphones, the one thing that today's millennial consumer wants? Is choice. and along with choice comes freedom, why do you think it is that Microsoft has hitched itself to Linux with their "Microsoft Loves Linux" campaign? it's to make sure they stay in the public eye and relevant, because more and more people are CHOOSING to buy a Windows PC and install LINUX on it! Remember the old saying: "Keep Your Friends Close, And Your ENEMIES Closer".

Re: Lenovo.....

[(Anonymous)]

There's some problems with that.

Last year's machine had a significantly slower graphics chip. The HD 520 isn't really good for much more than displaying a spreadsheet. Especially not at the high resolutions the screen is capable of. The Iris 540 graphics chip...I've seen benchmarks that suggest it's about 60% faster.

So you could run the older model on Linux, if you never wanted to run anything more complicated than a web browser.