Sorry it’s NOT enough. Don’t worry I trust Intel for changing Intel CPUs; I trust AMD for changing AMD CPUs, etc. NO problem with that! - But
SIMPLYFYED: How can Firefox 57.0.4 change the Intel CPU/MMU - Microcode if such change need a secret code signature and don’t know anything secured from my CPU? If a Browser-SW can change it (I hope this SW is running in user-mode), a "tarned Hacker-SW" can change it to !!! For me this is NOT a trustful way for such an important change and need to be addressed very seriously to the HW manufactories. If your org can help for this, it’s great. P.S: Linus Torvalds is also very unhappy with this actual situation! http://www.pcgameshardware.de/CPU-Hardware-154106/News/Meltdown-Spectre-Linux-Linus-Torvalds-1247248/ <http://www.pcgameshardware.de/CPU-Hardware-154106/News/Meltdown-Spectre-Linux-Linus-Torvalds-1247248/> Kind regards Patrik ifs³ Consulting+Engineering Patrik Lori CTO, cert. Computer Engineer & MAS-BA Panoramastr. 6, 5625 Kallern, Switzerland Web: http://www.ifs3.com <http://www.ifs3.com/> Email: patrik.l...@ifs3.com <mailto:patrik.l...@ifs3.com> Mobile: +41 79 326 75 97 CONFIDENTIALITY NOTICE: This e-mail message including attachments, if any, is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any unauthorised review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. If you are the intended recipient but do not wish to receive communications through this medium, please do advise the sender immediately. > Am 08.01.2018 um 19:43 schrieb Felix Winterhalter <fe...@audiofair.de>: > >> Second: I’m not willing to accept, that CPU/MMU - Microcode can be changed >> just by some OS/SW-Updates without any physical and local interventions or >> with a secret „ONE WAY“ passwords/ticket directly coming from the >> manufacture company. Otherwise "very bad hackers" are able to change the >> critical CPU/MMUs - Microcode to prepare some „spyglass-situation|attacks“, >> which NO uper-layered "Security-SW or OS“ ever can detect. >> This is a very bad situation (even if this exist many years ago). >> > > You appear to have the impression that microcode updates are completely > unsigned code that anyone can modify. You might find this an interesting read: > > http://inertiawar.com/microcode/ <http://inertiawar.com/microcode/> > > It explains how microcode updates work in general and specifically how they > work on Intel chips. You cannot simply perform arbitrary microcode updates on > a system. And microcode updates will only load if they are newer than the one > already applied. So you cannot just load an older insecure version of > microcode if an update has already been applied by either the bios or the > kernel. Microcode updates only increase security, they could only decrease it > if Intel released a microcode update that introduced a weakness and signed > that. At the point where you don't trust your vendor on that level anymore > you might as well give up on any sort of proprietary hardware that needs any > sort of binary blobs, which some decide to do. > >> INFO: >> It looks HPE has realized this serious security thread and developed a >> special ILO-Chip hat help to solve this real problem. >> siehe: >> http://www.zdnet.de/88300819/schutz-vor-firmware-attacken-hpe-sichert-proliant-server-ab/?_ga=2.128992076.1543857168.1515237773-947033226.1515237773&inf_by=5a50b18d671db879058b47d8 >> >> <http://www.zdnet.de/88300819/schutz-vor-firmware-attacken-hpe-sichert-proliant-server-ab/?_ga=2.128992076.1543857168.1515237773-947033226.1515237773&inf_by=5a50b18d671db879058b47d8> >> 👍 >> >> >> >> I hope other HW manufactures (DELL, IBM, CISCO, Oracle, etc.) are asap. also >> have/providing some solution for this problem. >> > The link you have provided shows that HPE wants to make sure its firmware, > i.e. UEFI and components are secured. They do not talk about preventing > microcode updates, which I don't think this provides as those are CPU > features directly. I'm not sure if those can be disabled by the > chipset/mainboard as its basically just a special instruction sent to the CPU > (pretty sure they can't be prevented by that). >
