Re: Microcode update conundrum (was Re: ANNOUNCEMENT: Intel processor microcode security update)
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. (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]. Other manufacturers may claim otherwise, but what else can we do except trust them? It is a very fundamental problem. Also, it is hard to argue that it is useful to have the ability to fix bugs in the CPU without replacing the chip. After all, you will face the same dilemma of trusting the CPU manufacturer when offered a new revision of the physical CPU with bugfixes. 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. Does anyone know if the microcode shipped by Intel is always encrypted? Their nasty licence prohibits everse engineering, decompilation, or disassembly of the blob, but even if you ignored that, 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? [1] http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.html -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130908083400.ga30...@seestieto.com
Re: Microcode update conundrum (was Re: ANNOUNCEMENT: Intel processor microcode security update)
On Sun, 08 Sep 2013, Henrik Ahlgren wrote: 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 Indeed. And if you're not going to use the repositories to get automated updates, you should at least use the Debian PTS (packages.qa.debian.org) to track package upload-source events so that you will get an email when the package is updated. Also, it is hard to argue that it is useful to have the ability to fix bugs in the CPU without replacing the chip. After all, you will face Indeed. Look at the errata lists for the x86 processors of any vendor... Does anyone know if the microcode shipped by Intel is always encrypted? Their nasty licence prohibits everse engineering, Yes, it is. And it is not a half-baked job either. http://inertiawar.com/microcode/ decompilation, or disassembly of the blob, but even if you ignored that, 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? See here: http://en.wikipedia.org/wiki/Microcode You really need a lot of low-level information about the core (and maybe even the uncore) to do anything useful with the full microcode. And there is no reason why a microcode update would have the full microcode inside, either. It could well be just a patch that only describes changed sections of the microcode, or even a runtime behaviour change table (something like a hardware breakpoint + microcode that should run when the breakpoint is activated, or even a table of internal processor state change that should be applied when the breakpoint is activated, to fix issues that are not implemented in microcode). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130908154200.ga5...@khazad-dum.debian.net
Re: Microcode update conundrum (was Re: ANNOUNCEMENT: Intel processor microcode security update)
On Sun, 08 Sep 2013, Joel Rees wrote: I was hoping that AMD was not going to have the license and non-visibility issue that plagues the Intel processor microcode updates. But I find this original announcement from when Henrique made the updater tool available: http://lists.debian.org/debian-devel/2012/11/msg00109.html AMD is better than Intel at telling the general public what a microcode update fixes. AMD does publish to the general public the errata each microcode update fixes. What each erratum means is also published in the AMD processor Revision Guides, which are also public. Not that it will help you much. Really. Most of the errata worth fixing through a microcode update causes either unpredictable system behaviour, data corruption, or system hangs/reboots. Only a few fixes are for minor issues such as power management, performance, or optional features. And most of the time, it is very very difficult to access how difficult it is to hit a given erratum. So it is a update or else deal, because it always fixes something horrible (even when the chances of you hitting the issue are very remote -- but you won't be able to know that, you'll have to update just in case anyway) AFAIK, Intel does publish the same kind of information but it is not available to the general public. Intel does publish to the general public the list of errata in their processor specification updates documentation, it just almost never writes down in public documentation what errata a microcode update fixes. And you could also have internal/non-public errata and fixes, nothing forces Intel, AMD, or any other vendor to disclose (even to their hardware partners) the full list of errata and behaviour changes (fixes, etc). Note that even the internal errata/fix information is bound to be really uninteresting anyway. Backdoors would not be documented anywhere, heck, it is very likely that only the one or two engineers that had to implement them even know about it. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130908155505.gb5...@khazad-dum.debian.net
Re: Microcode update conundrum (was Re: ANNOUNCEMENT: Intel processor microcode security update)
On Sun, Sep 08, 2013 at 12:55:05PM -0300, Henrique de Moraes Holschuh wrote: Note that even the internal errata/fix information is bound to be really uninteresting anyway. Backdoors would not be documented anywhere, heck, it is very likely that only the one or two engineers that had to implement them even know about it. Next problem: security is about trusting other people. If you don't trust Intel or AMD, better don't use their products. I see a lot of things which are destroyed now – it is not only the “cloud”. This game is over anyways. It's about the base we're all standing on. The US government and the NSA are eliminating that, and nothing less. If we cannot trust in the manufacturers of the CPUs, we don't have computers any more we can use. Yours, VB. -- pibit AG, Oberer Graben 4, 8400 Winterthur mailto:v...@pibit.ch Mobile +41 (79) 292 88 87 pgp9T7vDblP0i.pgp Description: PGP signature
Re: Microcode update conundrum (was Re: ANNOUNCEMENT: Intel processor microcode security update)
On 9/09/2013 2:18 AM, Volker Birk wrote: On Sun, Sep 08, 2013 at 12:55:05PM -0300, Henrique de Moraes Holschuh wrote: Note that even the internal errata/fix information is bound to be really uninteresting anyway. Backdoors would not be documented anywhere, heck, it is very likely that only the one or two engineers that had to implement them even know about it. Next problem: security is about trusting other people. If you don't trust Intel or AMD, better don't use their products. I see a lot of things which are destroyed now – it is not only the “cloud”. This game is over anyways. It's about the base we're all standing on. The US government and the NSA are eliminating that, and nothing less. If we cannot trust in the manufacturers of the CPUs, we don't have computers any more we can use. This is absolutely a problem, I have no doubt that the NSA has hooks in as well as requirements to hinder user security. This article [2], points to the Intel Secure Key technology [3] (in newer Intel CPUs). The first intro line of the Intel link says: Intel Secure Key, was previously code-named Bull Mountain Technology. The NYT article [0] mentions Bullrun as a program , that neatly fits with Bull Mountain Technology So, if we have a new enough [later I7?, 3rd gen or later] Intel CPU, then chances are that the random number generator will bring in issues that will interfere with the security of GPG when generating keys, due to NSA requirements. And here is a quote about /dev/random . (from another mailing list that I participate on): I'm glad Ted Ts'o also understands the need to avoid opaque instruction sets that can't be independently audited, and has resisted pressure from Intel engineers to allow /dev/random to rely solely on the RDRAND instruction. You can't trust the random number generator in Intel CPUs, the special function. If crypto key generation relies on proper random number generation, then crypto is busted ... just ask CryptoCat what happens when there is a flaw in random number generation [4], since fixed by the way. So, all in all, I can see how /any/ microcode update could be the result of NSA requirements and it throws a whole can of worms on trust, particularly with ANY business that is US based or has links to US based companies which may exert pressure to force issues. Furthermore, do we update microcode for older CPUs and potentially allow them to /own/ us too? Do we only use CPUs that pre-date this issue? There are loads of questions, what hope do we have? And this [5] is something that I'll probably end up using to harden my GPG keys. [0] http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html?_r=1; [1] http://www.theguardian.com/world/interactive/2013/sep/05/nsa-project-bullrun-classification-guide [2] http://blog.cryptographyengineering.com/2013/09/on-nsa.html [3] http://software.intel.com/en-us/blogs/2012/05/14/what-is-intelr-secure-key-technology [4] http://tobtu.com/decryptocat.php https://duckduckgo.com/?q=cryptocat%20random%20number%20issue (for more links) [5] http://gagravarr.livejournal.com/137173.html?nojs=1 (Creating a 8192 bit GPG key to replace my 1024 bit one) Cheers AndrewM signature.asc Description: OpenPGP digital signature
Re: Microcode update conundrum (was Re: ANNOUNCEMENT: Intel processor microcode security update)
(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]
Re: Microcode update conundrum (was Re: ANNOUNCEMENT: Intel processor microcode security update)
On Mon, Sep 9, 2013 at 12:55 AM, Henrique de Moraes Holschuh h...@debian.org wrote: On Sun, 08 Sep 2013, Joel Rees wrote: I was hoping that AMD was not going to have the license and non-visibility issue that plagues the Intel processor microcode updates. But I find this original announcement from when Henrique made the updater tool available: http://lists.debian.org/debian-devel/2012/11/msg00109.html AMD is better than Intel at telling the general public what a microcode update fixes. AMD does publish to the general public the errata each microcode update fixes. What each erratum means is also published in the AMD processor Revision Guides, which are also public. Not that it will help you much. Really. Most of the errata worth fixing through a microcode update causes either unpredictable system behaviour, data corruption, or system hangs/reboots. Only a few fixes are for minor issues such as power management, performance, or optional features. And most of the time, it is very very difficult to access how difficult it is to hit a given erratum. So it is a update or else deal, because it always fixes something horrible (even when the chances of you hitting the issue are very remote -- but you won't be able to know that, you'll have to update just in case anyway) X/ or else ..., when there are secrets being kept always bugs me. AFAIK, Intel does publish the same kind of information but it is not available to the general public. I don't really call that publishing. Publishing privately is one of the conceits introduced at Berne that undermine the principle of copyrights in free countries. Intel does publish to the general public the list of errata in their processor specification updates documentation, it just almost never writes down in public documentation what errata a microcode update fixes. And you could also have internal/non-public errata and fixes, nothing forces Intel, AMD, or any other vendor to disclose (even to their hardware partners) the full list of errata and behaviour changes (fixes, etc). Note that even the internal errata/fix information is bound to be really uninteresting anyway. Backdoors would not be documented anywhere, heck, it is very likely that only the one or two engineers that had to implement them even know about it. Still, secrecy about the microcode and about the updating machinery makes it that much harder to probe for back doors. Ken Thompson didn't mention it in his essay, but it is possible to probe library code for stuff that isn't in the source code. And it is possible to probe a CPU for backdoors, if you have enough documentation about their correct behavior. Modern CPUs (particularly x86 and AMD64) are like MSWindows -- too complex, not accessible to review, no guard rails. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- Joel Rees -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caar43ipy2opcbg-8ntnvwu5zeyyam4zonya+pkbxdwt514k...@mail.gmail.com
Microcode update conundrum (was Re: ANNOUNCEMENT: Intel processor microcode security update)
(I kind of hope this starts a flame war large enough to embarrass the corporate culprits into behaving themselves about this. Apologies in advance when I step on toes.) I was hoping that AMD was not going to have the license and non-visibility issue that plagues the Intel processor microcode updates. But I find this original announcement from when Henrique made the updater tool available: http://lists.debian.org/debian-devel/2012/11/msg00109.html And that shoots that dream. So, (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? (2) Are there any CPU manufacturers who are not plagued by this ultimate refusal to let computer owners actually own their computers? How do the ARM manufacturers do? (2a) Is debian running on any of the open core CPUs? (I don't remember any evidence of such, but maybe I just missed it?) -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caar43in8fkrxshhzjdehgfkep2htycwjoxexewrfayrrvzm...@mail.gmail.com
