Debian Warns Of Hyper Threading Issue With Intel Sky/Kaby Lake CPUs

[Ardje]

Yeah, let's not update freely redistributable microcodes claiming it's user subjugation (when it's not by a long shot), and ignore the reality of modern electronics that can't come out perfect and fully functional from fab.

Really, it's when ethics is applied without any regard for the actual reality that it becomes fundamentalist bullshit.

I think sometimes people are taking Richard Stallmans principles much further than Richard ever would.
Anyway: Some things can only be fixed using bios updates. Dell servers had a lot of bugs in the memory management department which could only be fixed with bios upgrade. I think Richard would have no problem with that.
I think Richard would object to the spying device that intel CPU's have these days: management CPU's without any real security checks, which already have been compromised.
In that case I wonder what is in that "microcode" update.

[starshipeleven]

In that case I wonder what is in that "microcode" update.

It's usually very low-level stuff like how to actually execute x86 instructions in that specific hardware, how to operate the memory controller, and other stuff like that.
Far too low-level to be malicious, it's done in microcode because if it was not then any mistake in that area would require people to throw away the CPU and ask for a replacement from Intel, which would be a catastrophe.

[chithanh]

Yeah, let's not update freely redistributable microcodes claiming it's user subjugation (when it's not by a long shot), and ignore the reality of modern electronics that can't come out perfect and fully functional from fab.

Really, it's when ethics is applied without any regard for the actual reality that it becomes fundamentalist bullshit.

I don't necessarily agree with the FSF position, but you cannot say that they ignore the reality here.

If you get microcode updates from your hardware vendor, these are definitely software, and you do not have three of the the four freedoms.

Freedom 0 - to use the program for any purpose as you wish (typical firmware/microcode license forbids reverse engineering)
Freedom 1 - to be able to study how the program works, and change it as you wish (no source code)
Freedom 2 - distribute the program (you have that one)
Freedom 3 - distribute modified versions (no source code again)

So the user subjugation through closed source microcode/firmware is as real as the one through proprietary and closed source operating systems, drivers, and applications.

I think sometimes people are taking Richard Stallmans principles much further than Richard ever would.
Anyway: Some things can only be fixed using bios updates. Dell servers had a lot of bugs in the memory management department which could only be fixed with bios upgrade. I think Richard would have no problem with that.

The FSF position is endorsed by Richard Stallman as far as I know.

I think Richard would object to the spying device that intel CPU's have these days: management CPU's without any real security checks, which already have been compromised.
In that case I wonder what is in that "microcode" update.

The spying device (I assume you mean Intel ME/AMT) would be ethical if it came with source code, and let users run, examine, modify as they wish. But it doesn't, so it isn't.

[moilami]

That's a big conceptual leap. CPU microcode has been changeable during boot for at least 40 years, maybe 50.

I wrote that thinking CDRW drives. But good information anyway.

Are you saying that because you can replace your graphics card or network adapter it should be considered as software as well ?

No

Let's say the graphics card has microcode stored on the board somewhere (perhaps a socketed ROM). If you plug in a ROM containing a new version of hardware microcode does that mean it should now be considered as software ? How about if the ROM is not socketed but you plug in a new graphics adapter identical to the old one but with newer microcode in the ROM ?

Microcode should be considered as "software", if it is binary data or data in whatever form. It is not "art", like some picture can be, or "content", like some text can be. It is not "media". Accessibility to microcode does not define what it is So microcode is "code"

How about if the microcode is stored in flash on the graphics card. You update the flash with new hardware microcode - does that magically make it become software ? Is there some "threshold of convenience" which, when crossed, turns microcode from part of the hardware design to "obviously software" ?

Hackers should have access to microcode, if microcode can be changed, and especially so if microcode can be changed easily like CPU/GPU microcode can be changed.

Last time we talked about this you somehow made me accept your PoW. I wonder how it was possible, maybe I was in too lazy mood to argue or your arguments were so well and funnily argued I overlooked the content.

May I ask why this microcode is like the last treasured fortress of proprietary software, being defended like Stalingrad was in 1942

[moilami]

Huh? It's possible to reflash it in the BIOS too, so why SPI chips are treated differently from internal storage?
Now with UEFI it's tehcnically not possible anymore as most of that stuff is signed by hardware manufacturer, but with BIOS it was as easy as finding where it was on flash and use flashrom.

There is no real reason why it should be treated differently. There are practical reasons. Microcode in some random CDRW drive is not that major thing as is microcode in current GPUs/CPUs, where for example with AMD cards 3D acceleration does not work at all without microcode. So I guess there is no microcode inside those cards to begin with, henceforth the microcode is not changed, it is injected, and needs to be injected for the card to function properly. The card needs microcode like computer needs kernel (from end user PoW). Why should microcode be left out as secret mystery code? Why

[ext73]

This will not affected my kernels builds > netext73.pl

[dungeon]

Review of Debian 9: Broken Broken Broken Stupid Stupid Stupid. Full Stop.

You can say same thing for Debian 6, 7 and 8... because there is nothing new there for 9 specially, as since last 7 years Debian kernel defaults like linux-libre kernel

With major difference that linux-llbre kernel totally disable blob firmwares/microcodes and even infrastucture to load them, basically it is only one who is not fake free software kernel While Debian kernel is the same like that by default, but instead with an option to enable them.

You can call it as stupid because of this, but it is not... it is actually just middle ground design between two extremes, one side say you must not at all do this and another side say you must do it all the time... In that situation well as one group wants it like this and another wants it like that, so let user choose this instead

[bridgman]

Microcode should be considered as "software", if it is binary data or data in whatever form. It is not "art", like some picture can be, or "content", like some text can be. It is not "media". Accessibility to microcode does not define what it is So microcode is "code"

Hackers should have access to microcode, if microcode can be changed, and especially so if microcode can be changed easily like CPU/GPU microcode can be changed.

OK, so let's say my hardware product is built around one or more FPGAs and the hardware design is loaded into the chip as a binary image at power-on. Does the fact the HW can be changed by loading a new binary file (which is the same as the microcode case) mean that my entire hardware design becomes "software" and must be opened up ?

If not, how is that different from our case where HW is designed as a state machine and behaviour is completed by a microcode image ?

Last time we talked about this you somehow made me accept your PoW. I wonder how it was possible, maybe I was in too lazy mood to argue or your arguments were so well and funnily argued I overlooked the content.

Maybe you're just in a bad mood this time

May I ask why this microcode is like the last treasured fortress of proprietary software, being defended like Stalingrad was in 1942

Sure... early on we had a choice between heavily restricting the programming information we released for driver development (which would have meant no video acceleration among other things) or moving functionality into HW+microcode and restricting them instead. We have to keep some secrets in one place or another to maintain content protection (and hence the ability to sell into most of our markets), and chose the HW+microcode since that allowed better and faster driver development.

[BaronHK]

content protection

DRM doesn't work. That doesn't stop evil corporations that are stuck smelling each others farts from pretending that it does though.

[BaronHK]

I think sometimes people are taking Richard Stallmans principles much further than Richard ever would.
Anyway: Some things can only be fixed using bios updates. Dell servers had a lot of bugs in the memory management department which could only be fixed with bios upgrade. I think Richard would have no problem with that.
I think Richard would object to the spying device that intel CPU's have these days: management CPU's without any real security checks, which already have been compromised.
In that case I wonder what is in that "microcode" update.

Stallman objects to any computer that is using proprietary uEFI firmware, so whether or not you run Debian in its default configuration, you're running proprietary software, according to Stallman. In fact, the FSF has only ever endorsed two laptops and the newest one is a refurbished Lenovo from 2008 that has had its boot firmware replaced.

It has a 9 year old Core 2 Duo processor.

Not that you'll be running any high performance software with it. The FSF-approved operating system removed the firmware that enables the 3d engine on the GMA 950.

http://www.pcworld.com/article/2879086/the-free-software-foundation-loves-this-laptop-but-you-wont.html