Asahi Linux progress report [LWN.net]

Asahi Linux progress report

Posted Mar 12, 2021 0:10 UTC (Fri) by mss (subscriber, #138799)
In reply to: Asahi Linux progress report by flussence
Parent article: Asahi Linux progress report

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.

to post comments

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.