Linux 5.8 Has The Bits Needed To Begin Booting POWER10 Processors

[phoronix]

Phoronix: Linux 5.8 Has The Bits Needed To Begin Booting POWER10 Processors

POWER10 is the forthcoming IBM + OpenPOWER processor expected to be shipping in 2021 and manufactured on a 7nm process and offer big improvements over the existing POWER9 microarchitecture...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-5.8-Booting-POWER10

[ssokolow]

On the POWER9 front, the Linux 5.8 kernel does bring support for exposing the hardware's GZIP accelerator to user-space. This allows modified user-space programs to submit requests directly to the on-chip accelerator for GZIP offload.

Can anyone confirm that this is actually general enough to also accelerate other formats based on Deflate compression like PNG, Zip, and Zip-based file formats like ODF and JAR?

I wasn't able to find much information on it, but this AIX Knowledge Base article seems to suggest that it's a hardware zlib implementation that's referred to as a GZIP accelerator for marketing reasons but is accessed through a frontend library named zlibNX which will use hardware if available.

Likewise, the README of this GitHub repo seems to indicate that it's featurful enough to be used as a drop-in replacement for regular zlib to the extent that you can replace the libz.so file system-wide.

If that's true, it should function generally, since libpng relies on zlib for PNG compression and the zipfile module in Python's standard library relies on the zlib module in the standard library for Deflate support.

[Guest]

Will there be POWER10 based laptops?

[BwackNinja]

Can anyone confirm that this is actually general enough to also accelerate other formats based on Deflate compression like PNG, Zip, and Zip-based file formats like ODF and JAR?

I wasn't able to find much information on it, but this AIX Knowledge Base article seems to suggest that it's a hardware zlib implementation that's referred to as a GZIP accelerator for marketing reasons but is accessed through a frontend library named zlibNX which will use hardware if available.

Likewise, the README of this GitHub repo seems to indicate that it's featurful enough to be used as a drop-in replacement for regular zlib to the extent that you can replace the libz.so file system-wide.

If that's true, it should function generally, since libpng relies on zlib for PNG compression and the zipfile module in Python's standard library relies on the zlib module in the standard library for Deflate support.

The supported functions list at the bottom of the README lists what it supports (but that list is incomplete), but as for what it doesn't you can look at the symbols exported by the regular libz.so. The easiest way to see which functions it supports is to look for "ZLIB_API" in the source code.

Missing are:

• crc32_z (nx_crc32_z exists, but no alias)
• deflateCopy, deflateGetDictionary, deflateParams, deflatePending, deflatePrime, deflateResetKeep (nx_deflateResetKeep exists, but no alias), deflateTune
• get_crc_table (nx_get_crc_table exists, but no alias)
• All of the gz* functions (gzopen, gzclose, gzread, etc)
• inflateBack, inflateBackEnd, inflateBackInit_ inflateBackInit2_, inflateCodesUsed, inflateCopy, inflateGetDictionary, inflateGetHeader, inflateMark, inflatePrime, inflateReset2 (nx_inflateReset2 exists, but no alias), inflateResetKeep (nx_inflateResetKeep exists, but no alias), inflateSync, inflateSyncPoint, inflateUndermine, inflateValidate

So as long as you aren't relying on those functions, it'll work replacing libz.so with this library.

[WolfpackN64]

Will there be POWER10 based laptops?

If someone builds one.

[elatllat]

Will POWER10 hardware have speculative execution vulnerabilities like every other powerful hardware?

[ssokolow]

Will POWER10 have speculative execution vulnerabilities like every other powerful SOC?

It's not an SoC. That aside, probably. They're an emerging area of research. It's hard to prevent types of bugs that haven't yet been discovered.

[ssokolow]

The supported functions list at the bottom of the README lists what it supports (but that list is incomplete), but as for what it doesn't you can look at the symbols exported by the regular libz.so. The easiest way to see which functions it supports is to look for "ZLIB_API" in the source code.

Missing are:

• crc32_z (nx_crc32_z exists, but no alias)
• deflateCopy, deflateGetDictionary, deflateParams, deflatePending, deflatePrime, deflateResetKeep (nx_deflateResetKeep exists, but no alias), deflateTune
• get_crc_table (nx_get_crc_table exists, but no alias)
• All of the gz* functions (gzopen, gzclose, gzread, etc)
• inflateBack, inflateBackEnd, inflateBackInit_ inflateBackInit2_, inflateCodesUsed, inflateCopy, inflateGetDictionary, inflateGetHeader, inflateMark, inflatePrime, inflateReset2 (nx_inflateReset2 exists, but no alias), inflateResetKeep (nx_inflateResetKeep exists, but no alias), inflateSync, inflateSyncPoint, inflateUndermine, inflateValidate

So as long as you aren't relying on those functions, it'll work replacing libz.so with this library.

I was more wondering about the capabilities of the hardware, not the library built around it. (It's always possible to have a library transparently switch to a software fallback for unsupported combinations of parameters.)

[elatllat]

...It's hard to prevent types of bugs that haven't yet been discovered.

It's not hard to prevent entire classes of bugs, there is older non-speculative hardware that is imune, hardware based memory protection could be leveraged to secure speculation, quality hardware prevents rowhammer, rust/etc can solve memory problems, Elon can get us to a backup planet... someone will fix the hardware vulnerabilitys, it's just a matter of who/when.

[milkylainen]

Will POWER10 hardware have speculative execution vulnerabilities like every other powerful hardware?

I don't know if you're trying to be ironic or not.

All complex hardware implementations are likely to have bugs, just as complex software is.
A lax security focus led Intel to where they are today.
This does not mean that all other implementations are shit nor does it mean that they are perfect.

So is it going to have bugs? Probably.
Is it going to have speculation class bugs? Probably.
Is it fixable? Probably.