Intel Kabylake Will Still Require Firmware Blobs

[phoronix]

Phoronix: Intel Kabylake Will Still Require Firmware Blobs

Beginning with Skylake and Broxton hardware, Intel began requiring firmware blobs as part of their open-source graphics driver stack. This binary firmware is continuing forward with the next-generation Kabylake processors...

http://www.phoronix.com/scan.php?page=news_item&px=Intel-Kabylake-GuC-Firmware

[quaz0r]

requiring firmware blobs as part of their open-source

no comment

necessitated

no comment

[Nille_kungen]

no comment


no comment

I'm a bit confused did you leave a comment or were there no comment.

[sabun]

I'm a bit confused did you leave a comment or were there no comment.

It's a paradox.

[uid313]

Why did Intel regress here?
With Haswell and Broadwell no binary blobs were needed, and since Skylake now binary blobs are needed.
Why?
Shouldn't they strive for more openness?
Why did they regress and go from something open to something closed?

[Nille_kungen]

Why did Intel regress here?
With Haswell and Broadwell no binary blobs were needed, and since Skylake now binary blobs are needed.
Why?
Shouldn't they strive for more openness?
Why did they regress and go from something open to something closed?

actually there's no regression IIUC they moved somethings from hardware to software so it's easier to update.
This kind of microcode has always been there but you didn't see it before.
It's not better if it's hidden in hw rather then the software side, one can actually argue that it's more open now since it's not hidden away even if it's blobs.

[_r00t-]

That's not good for Linux....

[c117152]

actually there's no regression IIUC they moved somethings from hardware to software so it's easier to update.
This kind of microcode has always been there but you didn't see it before.
It's not better if it's hidden in hw rather then the software side, one can actually argue that it's more open now since it's not hidden away even if it's blobs.

No. Microcode that initializes hardware that then executes machine code instructions is fine. This magic DRM stew that performs RSA authentication isn't fine.

[hahahafr]

actually there's no regression IIUC they moved somethings from hardware to software so it's easier to update.
This kind of microcode has always been there but you didn't see it before.
It's not better if it's hidden in hw rather then the software side, one can actually argue that it's more open now since it's not hidden away even if it's blobs.

Do you know what size is this GuC firmware we are talking about ?

No. Microcode that initializes hardware that then executes machine code instructions is fine. This magic DRM stew that performs RSA authentication isn't fine.

So basically, we are pushing code (RSA, etc.) to execute on this CPU/GPU and we don't know what it does ? This sounds very much like a "pico-OS" is already running by itself on the Intel chip and is waiting for input.

Maybe I'm just paranoïd though.

[Luke]

So one of the blobs is for proprietary H265 support and requires authentication. The question is can the chip be run without this particular blob and without hardware support for H265? The demands from the patent holder for per-video file payments from media serving websites for this codec will probably limit it to paid or "premium" content. Those most concerned with avoiding proprietary software usually do not use premium content. If a non-premium H265 file comes across via bitorrent or some such thing, so long as it is not 4K it should be possible to play it purely in software on any 4-core processor or transcode it to something less CPU intensive.

Other question is this: Is that a blob that requires authentication by an on-chip key, or are we talking REMOTE authentication here? The latter would require filtering all network access though a non-Intel machine blocking the servers in question.