Asahi Linux progress report [LWN.net]

Asahi Linux progress report

Posted Mar 11, 2021 16:22 UTC (Thu) by darwi (subscriber, #131202)
Parent article: Asahi Linux progress report

Oh, if that's the future of laptop computing, I don't want to be part of it :(

With all the faults of Microsoft and Intel, at least they worked hard in making PC computing a (relatively) open standard. They also pushed for standard hardware/firmware interfaces (UEFI, ACPI, USB hardware classes, standardized hardware interface for audio, PCI before that, etc. etc.)

to post comments

Asahi Linux progress report

Posted Mar 11, 2021 18:30 UTC (Thu) by mss (subscriber, #138799) [Link] (21 responses)

These standard interfaces (and hiding platform details behind them) were required in part because otherwise older Windows versions would not run properly on newer hardware.

Asahi Linux progress report

Posted Mar 11, 2021 23:03 UTC (Thu) by flussence (guest, #85566) [Link] (20 responses)

...and also partly so newer Windows versions had an excuse to not run properly on older hardware (DRM).

Asahi Linux progress report

Posted Mar 12, 2021 0:10 UTC (Fri) by mss (subscriber, #138799) [Link] (19 responses)

What kind of DRM you have on mind?

As far as I know Windows 10 runs fine without TPM or Secure Boot on open-source UEFI implementation.

Asahi Linux progress report

Posted Mar 12, 2021 16:07 UTC (Fri) by ledow (guest, #11753) [Link] (8 responses)

Windows Server requires TPM and Secure Boot.

It won't be long before that's rolled down to consumer versions.

Asahi Linux progress report

Posted Mar 12, 2021 17:02 UTC (Fri) by mss (subscriber, #138799) [Link] (4 responses)

> Windows Server requires TPM and Secure Boot.

Which specific Windows Server versions require them to run?

Microsoft has sait it will require TPM and Secure Boot for the *hardware to be certified* for the next (not yet retail) version of Windows Server (2022), but there hasn't been any announcement that it will require these features to actually run.

And Windows Server 2019 certainly doesn't require either.

> It won't be long before that's rolled down to consumer versions.

Most consumer "enthusiast" motherboards offered today lack TPM chip, some (many?) don't even have the necessary LPC bus connector.

Asahi Linux progress report

Posted Mar 13, 2021 5:56 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

> Which specific Windows Server versions require them to run?
It's a new requirement that will be enforced starting next month for new installations of WS. It can be overridden if necessary.

Asahi Linux progress report

Posted Mar 13, 2021 13:04 UTC (Sat) by mss (subscriber, #138799) [Link] (2 responses)

> > Which specific Windows Server versions require them to run?
> It's a new requirement that will be enforced starting next month for new installations of WS. It can be overridden if necessary.

Which specific Windows Server versions you have on mind?

Do you have any link to Microsoft annunciation of the policy change next month?

Asahi Linux progress report

Posted Mar 13, 2021 14:48 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

I think all of them. https://cloudblogs.microsoft.com/windowsserver/2020/06/11... - there is now a requirement for new Windows Server hardware to include TPMs and they are automatically used by the installer.

You can disable the TPM after the installation.

Asahi Linux progress report

Posted Mar 13, 2021 15:15 UTC (Sat) by mss (subscriber, #138799) [Link]

> there is now a requirement for new Windows Server hardware to include TPMs and they are automatically used by the installer.

They are required for new Windows Server *certified* hardware, that is, for hardware to be specifically blessed by Microsoft.

As I have said in the comment above:
> Microsoft has sai[d] it will require TPM and Secure Boot for the *hardware to be certified* for the next (not yet retail) version of Windows Server (2022),
> but there hasn't been any announcement that it will require these features to actually run.

Nothing in the article you mentioned says that Windows Server will run only on hardware certified by Microsoft.

That is, you can run Windows on hardware that lacks these features.
Just the hardware will not get "blessed by Microsoft" badge.

Asahi Linux progress report

Posted Mar 13, 2021 5:55 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Microsoft has a very serious stake in keeping Windows Server secure, so a TPM requirement is a good idea and it costs pretty much nothing for the server-class hardware.

It simply won't work for foreseeable future on commodity hardware, because TPM chips are not standard and are not present on a lot of hardware. My brand-new gaming PC doesn't have one, for example.

Asahi Linux progress report

Posted Mar 15, 2021 0:28 UTC (Mon) by zlynx (guest, #2285) [Link] (1 responses)

Pretty much any CPU made in the last three years supports "fTPM" which is implemented via the secure compute element in the CPU itself. That goes for Intel and AMD Ryzen.

Asahi Linux progress report

Posted Mar 15, 2021 1:21 UTC (Mon) by mjg59 (subscriber, #23239) [Link]

Not quite - the Intel implementation runs on the ME, which is on the chipset for non-SoC devices. AMD's implementation is on the PSP, which *is* on the CPU package. But yes, assuming the system vendor has wired it up, you don't need a physical TPM for TPM functionality these days. In some ways, it's even preferable - the LPC bus that discrete TPMs are attached to is extremely easy to interpose, which is far less true for fTPMs.

Asahi Linux progress report

Posted Mar 14, 2021 20:19 UTC (Sun) by flussence (guest, #85566) [Link] (9 responses)

The OP mentioned audio interfaces, and it's common knowledge Intel's HDA interface was crippled compared to AC97 at the behest of the music industry.

Asahi Linux progress report

Posted Mar 15, 2021 17:11 UTC (Mon) by ttuttle (subscriber, #51118) [Link] (5 responses)

Whoa, I would love to hear more about this. Do you have a link?

Asahi Linux progress report

Posted Mar 18, 2021 20:56 UTC (Thu) by flussence (guest, #85566) [Link] (4 responses)

It happened in the Windows Vista era, so nope. The main change was completely removing any hardware ability to capture raw data being sent to line out, which was more or less standard by the end of AC97. Pretty much useless at stopping casual piracy but it hurt a lot of legitimate use cases.

Asahi Linux progress report

Posted Mar 18, 2021 23:08 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

This is likely a result of Vista completely overhauling the audio stack. It basically stopped supporting anything complex for output.

Asahi Linux progress report

Posted Mar 19, 2021 0:00 UTC (Fri) by flussence (guest, #85566) [Link] (1 responses)

The base OS removed that ability, but I've heard enough irritated tales of having to “reboot into ASIO mode” that high end sound cards apparently didn't die out entirely.

Asahi Linux progress report

Posted Mar 19, 2021 0:06 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

There was nothing stopping you from talking with audio cards directly, you just needed a driver for that. Some "pro" audio cards tried that approach, but it just wasn't worth it. Floating point software mixing just became way superior to any fixed DSP magic, especially at the pro level.

Asahi Linux progress report

Posted Mar 19, 2021 11:51 UTC (Fri) by farnz (subscriber, #17727) [Link]

That ability was not removed by Intel HDA - in the HDA spec, you have Selectors which can be controlled by the host software to route audio signals in any fashion the codec designer chooses to allow.

Some codecs allow you to route audio in a loopback fashion, some don't - those with processing tend to. Same as AC'97 - some AC'97 devices allow loopback, some don't. The difference is that Windows Vista doesn't expose a full set of controls - just the minimal set they want for "consumer" audio - on HDA, whereas it can't do that on AC'97 devices.

Nothing to do with hardware, and everything to do with the choice of software you run on that hardware. Linux never had this issue :)

Asahi Linux progress report

Posted Mar 16, 2021 11:41 UTC (Tue) by farnz (subscriber, #17727) [Link] (2 responses)

I can't find documentation of this anywhere, and having spent a lot of time in past jobs with HDA and AC97 devices, I can't see anything different about HDA that enables DRM as compared to AC97 - from the CPU side, the distinctions are that HDA supports higher bit rates than AC97, and more complex analogue codec configurations (e.g. an 8 channel audio output that can be split into 4 stereo outs, or used as 7.1 channel surround, where AC97 has only fixed setups).

Do you have a reference listing the features of HDA that make it crippled as compared to AC97?

Asahi Linux progress report

Posted Mar 16, 2021 12:32 UTC (Tue) by pizza (subscriber, #46) [Link] (1 responses)

Well, HDA does provide an interface to set the "protected bit" of SP/DIF outputs.

But so did every AC97 codec that supported SP/DIF output, so that's hardly a regression.

(I think my first kernel contribution was a patch enabling that feature for various Crystal Semi codecs -- The receiver I was trying to use refused to accept data that didn't have that bit set, and forcing it on was enough to get it working...)

Asahi Linux progress report

Posted Mar 16, 2021 12:52 UTC (Tue) by farnz (subscriber, #17727) [Link]

It also has a set of verbs defined to confirm HDCP is in place before sending audio, but there's no standard way to encrypt the audio on a HDA link, just as there's no standard way to encrypt the audio on an AC97 link. And there's no standard way to do HDMI audio on AC97 at all, so the fact that HDCP can be checked in a standard fashion on HDA is neither here nor there - any AC97 audio implementation would do the same.

Asahi Linux progress report

Posted Mar 12, 2021 6:26 UTC (Fri) by hrw (subscriber, #44826) [Link]

Arm architecture has standards. Properly designed hardware with standard firmware boots normal Linux, BSD or MS Windows out of the box.

Just there are many vendors who chosen own way. Apple being one of them.

Asahi Linux progress report

Posted Mar 12, 2021 10:15 UTC (Fri) by rsidd (guest, #2582) [Link] (3 responses)

When Compaq and others created the IBM PC clone market, it became a necessity to push standardised hardware, because people wanted to run MS-DOS (later Windows) on all these machines. Microsoft and the hardware makers had an interest in interoperable hardware, and Linux benefited. Meanwhile, Apple sold its own hardware and did not need to follow any standards.

Same story today, except it's not so easy to install what OS you like on most ARM hardware (can be done, but not by just booting off a floppy or USB drive.) But, for what it's worth, Android (therefore Linux) is the OS compatible with a vast range of hardware, whose manufacturers must follow some standards if porting Android is not to be a complete nightmare. While iOS (and now macOS) are specific to Apple hardware which need not follow any standards. In this picture, Microsoft has been replaced by Google, otherwise nothing has changed since the 1980s.

Asahi Linux progress report

Posted Mar 12, 2021 10:47 UTC (Fri) by geert (subscriber, #98403) [Link] (2 responses)

In Android, Linux has overtaken the role of the BIOS in the IBM PC?

Asahi Linux progress report

Posted Mar 14, 2021 18:19 UTC (Sun) by WolfWings (subscriber, #56790) [Link] (1 responses)

In some cases, essentially yes. Even some niche x86 hardware are booting Linux as the "bios" and then that in turn can kexec a final Linux image, or failing that you're already in a 'rescue shell' instead of having to explicitly reboot into one. And in some distros they do likewise so you can end up passing through 2 Linux kernel's before reaching your actual login prompt in the 3rd layer. CoreBoot -> Linux Payload -> Linux as a Bootloader -> Linux Desktop

Asahi Linux progress report

Posted Mar 19, 2021 9:36 UTC (Fri) by geert (subscriber, #98403) [Link]

I didn't mean any of the solutions using kexec (milo/kboot/petitboot/...) to boot Linux from Linux, but Linux really being the common ground.
MS-DOS ran on anything providing the PC BIOS API.
Android runs on anything providing (a specific) Linux userspace API.

Asahi Linux progress report

Posted Mar 13, 2021 4:03 UTC (Sat) by BirAdam (guest, #132170) [Link]

I don’t think that’s just the future of laptop computing. Locked down devices that you do not own seems to be the future of all devices: phones, tablets, TVs, laptops, desktops, SBCs, etc.

I hope that some group like Pine64 can make something on truly open hardware and be the Compaq of the new era, but we shall see.