(Thanks for obliging, Henrik. ;-) On Sun, Sep 8, 2013 at 5:34 PM, Henrik Ahlgren <pa...@seestieto.com> wrote: > On Sun, Sep 08, 2013 at 08:00:12AM +0900, Joel Rees wrote: >> (1) This requires enabling two repositories that I have been avoiding >> enabling, contrib and non-free. That means I have to watch the >> repository more carefully when using >> >> apt-cache search >> >> or synaptic to look for new tools, right? Or can we just enable those >> two repositories long enough to load Henrique's tool and the microcode >> updates, then disable them again? > > Why do you feel that you even need to ask? You are free to handle the > situation with your machines in any way you wish. Perhaps just > download and install the .deb packages directly without even using > apt, or simply ignore the microcode update as shipped by Debian or as > BIOS upgrades by your computer manufacturer.
I'm thinking like a newbie. (Relative to debian, I am. :-/) I know there is a tendency to send newbs to Ubuntu. I don't think that's a good idea any more, for reasons you may not agree with, but I am sure you are aware of. I am subconsciously thinking about starting a new re-mix of debian that will focus on people who just want to replace MSWindows and MacOSX.whatever with something that doesn't try to own them, but don't have them time/confidence to learn how to do a manual install of a .deb package. And as long as Intel is so not-forthcoming, there is no point in doing so for x86/amd64 CPUs. >> (2) Are there any CPU manufacturers who are not plagued by this >> ultimate refusal to let computer owners actually own their computers? > > At least Intel openly admits that their modern CPUs have the ability > to change the microcode by uploading an encrypted binary blob. This > universal backdoor is publicly documented[1]. You mean, the existence and location are publicly documented, but nothing else. > Other manufacturers may > claim otherwise, but what else can we do except trust them? It is a > very fundamental problem. And at least the mob admits they want to influence you. Ken Thompson pointed out the problems inherent in trusting machines as complex as computers. He also made some mis-targeted assertions about culpability that are very relevant. He did not provide a solution. We know the solution, but we don't want to admit that Stallman was right. We don't think we know where to go from where he takes us. (Why is decentralization so hard to understand?) > Also, it is hard to argue that it is useful to have the ability to fix > bugs in the CPU without replacing the chip. I think you mean, hard to argue with the usefulness? But, you see, I'm arguing that complex CPUs are evil. Somewhere in my arguments is the idea that you could produce a CPU simple enough that field upgrades would be unnecessary. > After all, you will face > the same dilemma of trusting the CPU manufacturer when offered a new > revision of the physical CPU with bugfixes. Actually, the dilemma goes back farther than that. How can you trust the CPU manufacturer when (1) you can't see the masks and you couldn't read them if you could, (2) you can't see the manufacturing processes and you wouldn't know where to look if you could, (3) no single engineer can understand a modern CPU (and you probably aren't one of the group that could get close), (4) etc. That's more than two lemmas. Darn. > It simply is not feasible > for the majority of people to reverse engineer the silicon for any > evil features like NSA backdoors in any hardware crypto features. And that's another set of problems. > Does anyone know if the microcode shipped by Intel is always > encrypted? Jack provided a link. (And Henrique brought it into this thread.) > Their nasty licence prohibits "everse engineering, > decompilation, or disassembly" of the blob, but even if you ignored > that, (See said link, and kudos to someone for going that far down the road.) > or even if you had the source code (whatever that means in the > context of microcode, it is not normal X86 code after all), could you > make any sense of it without having the whole silicon design > available? Microcode source code is only a little harder to read than ordinary machine code. Sometimes it's easier. It's machine code, after all, even if it isn't the machine code the user usually works with. The problem is access to the machine that executes the microcode. Gate arrays and such are not programmed with a machine language, per se, and are significantly harder to reverse engineer. But if Intel publicly documented the gate arrays and microcoded machines used in their CPUs, the updates would not be beyond the reach of some engineers not employed by Intel. Provision of the gate array definitions and the microprogramming would add eyeballs to the job of finding bugs, as well. That leaves the manufacturing processes opaque, but even those would be more subject to probing if Intel were more forthcoming. > [1] > http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.html Yep. The say the update method is there, they tell how to call it and pass in the update, and nothing else. "At least, ... ." As Henrique points out, even AMD does better than Intel on documenting this kind of stuff. Not much better, but better. -- Joel Rees -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAr43iPkhjPh4Q2UNP_yj0Tpk=TDcjorfVUnWw=xzhchopc...@mail.gmail.com