If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rate Thread | Display Modes |
#16
|
|||
|
|||
Microcode Update?
....w¡ñ§±¤ñ wrote:
Pat wrote: Anyone here know how microcode updates work with modern processors? Over the last few weeks, we have all seen the discussion of the microcode bug that can be mitigated by OS updates which have the side effect of slowing the processor. That, I understand. However, I have also seen references to microcode updates released by, for example, Intel for their processors. How do those get installed? How can software running on a processor update the very microcode being used to run the software? I must be missing something. Pat The general rule for Spectre/Meltdown Intel releases the microcode update The OEM(pc manufacturer) or mobo manufacturer releases the UEFI/BIOS or BIOS update accommodating the microcode update The system end-user installs/updates the UEFI/BIOS or BIOS Bottom line - Not all devices will receive or be able to update UEFI/BIOS or BIOS for all Intel released microcode updates for two simple reasons - Firmware updates is not an in perpetuity support requirement and OEM or Mobo manufacturers' are not going to attempt to update all impacted(Spectre/Meltdown vulnerable) hardware on the planet. Microsoft, in fact, may not release firmware updates for all of its own released hardware using Intel, ARM or Atom chipsets(e.g. Surface, XBox, etc. products) This will give you some idea what Intel patched recently. The word Linux should not throw you off here - these updates apply to any platform. Intel does not pick favorites or anything, neither does Intel keep multiple streams. This release note is a "diff", and indicates only CPUs that have changed since the last release. In other words, these Branch Target Buffer patches, are all for relatively modern processors. No gubbins for the P4 for example. Intel Processor Microcode Package for Linux 20180108 Release -- Updates upon 20171117 release -- IVT C0 (06-3e-04:ed) 428-42a === my CPU barely made the list (Launch Date Q3'13) SKL-U/Y D0 (06-4e-03:c0) ba-c2 BDW-U/Y E/F (06-3d-04:c0) 25-28 HSW-ULT Cx/Dx (06-45-01:72) 20-21 Crystalwell Cx (06-46-01:32) 17-18 BDW-H E/G (06-47-01:22) 17-1b HSX-EX E0 (06-3f-04:80) 0f-10 SKL-H/S R0 (06-5e-03:36) ba-c2 HSW Cx/Dx (06-3c-03:32) 22-23 HSX C0 (06-3f-02:6f) 3a-3b BDX-DE V0/V1 (06-56-02:10) 0f-14 BDX-DE V2 (06-56-03:10) 700000d-7000011 KBL-U/Y H0 (06-8e-09:c0) 62-80 KBL Y0 / CFL D0 (06-8e-0a:c0) 70-80 KBL-H/S B0 (06-9e-09:2a) 5e-80 CFL U0 (06-9e-0a:22) 70-80 CFL B0 (06-9e-0b:02) 72-80 SKX H0 (06-55-04:b7) 2000035-200003c GLK B0 (06-7a-01:01) 1e-22 Microcode can be injected by the BIOS/UEFI or by the OS microcode loader. Both Windows and Linux have OS microcode loaders. Normally, Windows silently pushes out microcode. But, in a departure from that policy, at the moment, Microsoft is not pushing out 42a for my processor. I get "42a" if I boot Linux 16.04 patched up to date. I get "428" in Win10 16299.192 Meltdown patched up to date. And that's because Microsoft has not chosen to do a 42a push yet. My machine reports "416" if running older software. That implies that Windows 10 is putting "428" on my machine, but Microsoft has chosen to not push "42a" for the machine. Asus does not have a "42a" BIOS for my computer. I cannot force the issue that way. Other people, with X99 or later motherboards, may get the equivalent of the "42a" mine could use. But at the moment, only the Linux OS gave me an end result of "42a" microcode. Not that this is "important" or "critical". This crap will be dribbling out for the next year. Best advice I can give at the moment. 1) Patch to 16299.192 (or equivalent for older revisions of Windows 10. This includes Meltdown coverage. As well as a pretty basic form of Spectre coverage for IE11 and MSEdge. 2) If you use a third-party browser, patch it too. Firefox offers 57.0.4 with timing attack protection for Javascript arrays. Presumably Chrome has one of those patches too. This microcode stuff, covers the next level. The microcode method may make a better blanket protection. But at the moment, the (2) above is our best protection. The black hats are still working on (2) exploit. They will eventually make new exploits, and that's part of what the microcode thing is for. On older hardware, there is no BTB refinement. And the older hardwares are going to rely on a patchwork of other methods. My most modern computer, barely has any BTB (Branch Target Buffer) features at all. All the rest of my computers, will be patchwork material. Every time I use a web browser (even Firefox 57.0.4), I will never know what to expect. It will be up to Mozilla and the AV products, to mitigate these Spectre attacks as they arrive. Paul |
Ads |
#17
|
|||
|
|||
Microcode Update?
Andy Burns wrote:
...w¡ñ§±¤ñ* wrote: Not all devices will receive or be able to update UEFI/BIOS or BIOS for all Intel released microcode updates Firmware updates (being hardware specific) aren't required in order to get "sticky" microcode updates, the O/S can directly update the microcode at every boot instead. True..and some may follow that route, but doubtful that will be normal behavior. That's a route(update at boot) only because the CPU doesn't have non-volatile memory thus the general rule and implied earlier OEM/Mobo UEFI/BIOS or BIOS updates remain the preferred route and why not all devices will receive or be able to update UEFI/BIOS updates - they won't be available (or ignored [1]) [1] Look at it another way....the majority of end-users on the planet will never update microcode or UEFI/BIOS - never have, never will. -- ...w¡ñ§±¤ñ msft mvp windows experience 2007-2016, insider mvp 2016-2018 |
#18
|
|||
|
|||
Microcode Update?
....w¡ñ§±¤ñ wrote:
Andy Burns wrote: ...w¡ñ§±¤ñ wrote: Not all devices will receive or be able to update UEFI/BIOS or BIOS for all Intel released microcode updates Firmware updates (being hardware specific) aren't required in order to get "sticky" microcode updates, the O/S can directly update the microcode at every boot instead. True..and some may follow that route, but doubtful that will be normal behavior. That's a route(update at boot) only because the CPU doesn't have non-volatile memory thus the general rule and implied earlier OEM/Mobo UEFI/BIOS or BIOS updates remain the preferred route and why not all devices will receive or be able to update UEFI/BIOS updates - they won't be available (or ignored [1]) [1] Look at it another way....the majority of end-users on the planet will never update microcode or UEFI/BIOS - never have, never will. The end-users will automatically update microcode, without their knowledge. You probably don't even know how many microcode updates you've received, and when. And because of the quality of Intel testing, you'll probably never know. The OS microcode loader makes sure that prompt delivery of microcode updates arrives. The BIOS microcode only has to be good enough for the boot loader to finish, whereas the OS microcode loader version is there to ensure correct operation under all conditions after that point. That's why yesterday, when I booted an older Linux LiveCD, the microcode was 418. When I booted Windows 10, it was 428. This means that Microsoft did deliver microcode some time in the last year or two. Then, when I installed Ubuntu 17.10 for testing yesterday (as it's the only OS loader I have that has the most recent microcode), the /proc/cpuinfo says 42a for that one. Microsoft is "holding back" on the 2018 Jan8 microcode release. Intel would have told them in plenty of time. Microsoft made a judgment call that they weren't ready. Code must be present in the OS to handle both the "before" and the "after" condition, so it's their call as to whether they are ready for the Jan.8 microcode or not. I don't think Microsoft holding back, is related to the issue Lenovo detected. But it might be. Paul |
#19
|
|||
|
|||
Microcode Update?
On 1/15/2018 11:54 AM, Andy Burns wrote:
mike wrote: Exactly what is microcode in this context? Recent intel processors don't natively execute x86 or x86_64 instructions that compilers or humans produce, they use a lower level internal microcoded instruction set. So to a limited degree they can issue new microcode (which the CPU will only accept if it recognises a signature on it) that alters how the processor actually runs. It appears that there's a new class of microcode that can directly change persistent code within the microprocessor itself??? No intel CPU microcode needs to be loaded into the CPU at every reboot (by the BIOS, or by the O/S) Perhaps that's the confusion. Loaded at boot is volatile. The word "update" implies, to me, a non-volatile fix/patch that needs to be done once. So, we're overlaying the the microcode that the BIOS loaded at power up with microcode that the OS provides?? That gives me more confidence that the "update" won't bork my BIOS. It shouldn't have to do anything with the BIOS. all this really any big deal? If it ain't broke... You don't regard meltdown and/or spectre as evidence of breakage? I'd use the word, "unfortunate". The black hats found a way to do bad stuff to a design that's been working ok for decades. I had an old car that ran fine for decades. It was decreed that you could no longer get leaded gasoline. It seems that the lead served some needed function. Later, I had a car that didn't like gas with alcohol in it. Both still got me from point a to point b. Is the vendor of the old car responsible for legislated changes in gasoline composition? Intel is not the villain here...the black hats are. It's unfortunate, but bitching about Intel won't do any good. S#|T happens. You make the best of what you've got and move forward. Given the mind-boggling complexity of computer hardware and software, I'm amazed that it works at all. |
#20
|
|||
|
|||
Microcode Update?
On 2018-01-16, Boris wrote:
Melzzzzz wrote in news On 2018-01-16, Andy Burns wrote: ...w¡ñ§±¤ñ wrote: Not all devices will receive or be able to update UEFI/BIOS or BIOS for all Intel released microcode updates Firmware updates (being hardware specific) aren't required in order to get "sticky" microcode updates, the O/S can directly update the microcode at every boot instead. That is what I do... Now I'm lost. I thought I understood all this. So it's ok not to update the BIOS (firmware). Rather, just update the OS? OS already has microcode loader. On linux it's just a file as on windows, probably same file... -- press any key to continue or any other to quit... |
#21
|
|||
|
|||
Microcode Update?
Boris wrote:
Melzzzzz wrote in news On 2018-01-16, Andy Burns wrote: ...w¡ñ§±¤ñ wrote: Not all devices will receive or be able to update UEFI/BIOS or BIOS for all Intel released microcode updates Firmware updates (being hardware specific) aren't required in order to get "sticky" microcode updates, the O/S can directly update the microcode at every boot instead. That is what I do... Now I'm lost. I thought I understood all this. So it's ok not to update the BIOS (firmware). Rather, just update the OS? There are (at least) two microcode loaders. The BIOS has one. The OS has one. (Linux has an "early" and a "late" loader method). ******* They operate by revision number. If a higher revision update is available, it bumps out the other revision. Processor at T=0 microcode revision = 00 BIOS microcode loader microcode revision = 07 OS microcode loader microcode revision = 42 If the BIOS had revision 42 (by using a fresh BIOS you got a couple days ago), then the BIOS one would "win" and the OS microcode loader would fail to apply one with a higher revision number. (If both loaders offer 42, the first one injecting it, wins.) All that matters, is the system gets the highest revision possible, one way or another. Because Microsoft is not pushing out the Jan.8, 2018 microcode update right now, the BIOS is one way to "beat Microsoft at this game" and install it yourself. But is that necessary ? The Microsoft kernel has to be ready for both situations. Whether the version is 07 or 42. Conditional code in the Patch Tuesday in January, would be ready to handle both cases. For the time being, Microsoft is making the OS microcode update optional, and not following normal procedure to just deliver the Intel file like they always have in the past. If you want to "rush" the process, if your home computer is actually a part of Amazon AWS and must be ready for every eventuality, then you would want to update the BIOS right away. Since the software in your PC is under your control, and you already got the Firefox 57.0.4 patch, there's no rush to be pumping in microcode in the next five minutes. And remember that the vast majority of computer users, no hardware company is offering them a new BIOS right now. They don't have the staff to do 500 of these on the same day. There might only be one or two engineers working on that aspect of hardware maintenance (injecting microcode, a high school student could do that). I've disassembled BIOS files before, extracted the microcode, and read the family code and so on from the header of each one. And given people a list of processors supported by a BIOS. But to do that, I need an up-to-date BIOS manipulation tool (MMTOOL?). Anyone who hacks BIOS, collects tools like this, and I'm a rank amateur at this stuff. But it's pretty easy to do the analysis. Or for that matter, to inject a new microcode into a BIOS and make a new update file. The legacy BIOS, is like a miniature file system, and the microcode is just a 16KB file in it (back in the year 2000 it was about that size). A typical BIOS file has room for eight different processor types. OK, here's an MMTOOL example. Fourth line down is the microcode. I can remove the one shown in the screen, do a File : Open and plunk in a new one. There is a particular format, and I have to put the image together before injecting it. The scary part when I was doing this, is I was getting a lot of bogus size fields in the file I was working on, so I didn't dare burn that image into my BIOS chip. I would have bricked the computer. But some other USENET people were working in parallel with me, and they managed to finish the exercise and get the result they wanted. I didn't have the guts :-) I don't mind trying, if the "screen looks sane", but mine was buggered up somehow. It's like going for a walk in the woods, if you know bears are in there waiting for you :-) Sometimes it's better not to try. http://s21.postimg.org/d53zkb35z/mmt1.png Paul |
#22
|
|||
|
|||
Microcode Update?
Paul wrote:
...w¡ñ§±¤ñ wrote: Pat wrote: Anyone here know how microcode updates work with modern processors? Over the last few weeks, we have all seen the discussion of the microcode bug that can be mitigated by OS updates which have the side effect of slowing the processor.* That, I understand.* However, Ihave also seen references to microcode updates released by, for example, Intel for their processors.* How do those get installed?* How can software running on a processor update the very microcode being used to run the software?* I must be missing something. Pat The general rule for Spectre/Meltdown *Intel releases the microcode update *The OEM(pc manufacturer) or mobo manufacturer releases the UEFI/BIOS or BIOS update accommodating the microcode update *The system end-user installs/updates the UEFI/BIOS or BIOS Bottom line - Not all devices will receive or be able to update UEFI/BIOS or BIOS for all Intel released microcode updates for two simple reasons - Firmware updates is not an in perpetuity support requirement and OEM or Mobo manufacturers' are not going to attempt to update all impacted(Spectre/Meltdown vulnerable) hardware on the planet. Microsoft, in fact, may not release firmware updates for all of its own released hardware using Intel, ARM or Atom chipsets(e.g. Surface, XBox, etc. products) This will give you some idea what Intel patched recently. The word Linux should not throw you off here - these updates apply to any platform. Intel does not pick favorites or anything, neither does Intel keep multiple streams. This release note is a "diff", and indicates only CPUs that have changed since the last release. In other words, these Branch Target Buffer patches, are all for relatively modern processors. No gubbins for the P4 for example. * Intel Processor Microcode Package for Linux 20180108 Release * -- Updates upon 20171117 release -- * IVT C0*********** (06-3e-04:ed) 428-42a* === my CPU barely made the list (Launch Date Q3'13) * SKL-U/Y D0******* (06-4e-03:c0) ba-c2 * BDW-U/Y E/F****** (06-3d-04:c0) 25-28 * HSW-ULT Cx/Dx**** (06-45-01:72) 20-21 * Crystalwell Cx*** (06-46-01:32) 17-18 * BDW-H E/G******** (06-47-01:22) 17-1b * HSX-EX E0******** (06-3f-04:80) 0f-10 * SKL-H/S R0******* (06-5e-03:36) ba-c2 * HSW Cx/Dx******** (06-3c-03:32) 22-23 * HSX C0*********** (06-3f-02:6f) 3a-3b * BDX-DE V0/V1***** (06-56-02:10) 0f-14 * BDX-DE V2******** (06-56-03:10) 700000d-7000011 * KBL-U/Y H0******* (06-8e-09:c0) 62-80 * KBL Y0 / CFL D0** (06-8e-0a:c0) 70-80 * KBL-H/S B0******* (06-9e-09:2a) 5e-80 * CFL U0*********** (06-9e-0a:22) 70-80 * CFL B0*********** (06-9e-0b:02) 72-80 * SKX H0*********** (06-55-04:b7) 2000035-200003c * GLK B0*********** (06-7a-01:01) 1e-22 Microcode can be injected by the BIOS/UEFI or by the OS microcode loader. Both Windows and Linux have OS microcode loaders. Normally, Windows silently pushes out microcode. But, in a departure from that policy, at the moment, Microsoft is not pushing out 42a for my processor. I get "42a" if I boot Linux 16.04 patched up to date. I get "428" in Win10 16299.192 Meltdown patched up to date. And that's because Microsoft has not chosen to do a 42a push yet. My machine reports "416" if running older software. That implies that Windows 10 is putting "428" on my machine, but Microsoft has chosen to not push "42a" for the machine. Asus does not have a "42a" BIOS for my computer. I cannot force the issue that way. Other people, with X99 or later motherboards, may get the equivalent of the "42a" mine could use. But at the moment, only the Linux OS gave me an end result of "42a" microcode. Not that this is "important" or "critical". This crap will be dribbling out for the next year. Best advice I can give at the moment. 1) Patch to 16299.192 (or equivalent for older revisions ** of Windows 10. This includes Meltdown coverage. ** As well as a pretty basic form of Spectre coverage ** for IE11 and MSEdge. 2) If you use a third-party browser, patch it too. ** Firefox offers 57.0.4 with timing attack protection ** for Javascript arrays. Presumably Chrome has one ** of those patches too. This microcode stuff, covers the next level. The microcode method may make a better blanket protection. But at the moment, the (2) above is our best protection. The black hats are still working on (2) exploit. They will eventually make new exploits, and that's part of what the microcode thing is for. On older hardware, there is no BTB refinement. And the older hardwares are going to rely on a patchwork of other methods. My most modern computer, barely has any BTB (Branch Target Buffer) features at all. All the rest of my computers, will be patchwork material. Every time I use a web browser (even Firefox 57.0.4), I will never know what to expect. It will be up to Mozilla and the AV products, to mitigate these Spectre attacks as they arrive. *** Paul Hi Paul. Read the same article or similar as you. We agree on the best approach at this time - Update Windows to the latest build level[1] - Update Browser to current available Asus Sabertooth Z87, i7-4770 on Win7 Pro and Win10 Pro(same device, replacable HD, i.e. not dual boot) [1] Note: With 1709 now CBB/S-AC as of Jan. 12 2018 that effectively means only 1709 and 1703 are the foreseeable supported versions (i.e. 1607 will fall out of support) -- ...w¡ñ§±¤ñ msft mvp windows experience 2007-2016, insider mvp 2016-2018 |
#23
|
|||
|
|||
Microcode Update?
mike wrote:
Intel is not the villain here... Well, actually, they are. This is Intels "Takata Airbag" moment. Did you get a new Intel airbag ? No ? The only people who will be compensated, are the cloud companies of the world, who will be getting a good discount on their next server purchase. Because all the ones they own now, are suddenly suffering from "CPU stress". Intel is too big to fail. They have the arrogance (look at how Management Engine issues have been handled - why does Management Engine even exist???). They have the Rolex watches (Intel salesmen wear Rolex watches - they took pains to explain this to me when I met the staff from the local office). I think it's great, that they also make a product called "the Itanic" which is immune to some of these problems. How did AMD manage to dodge this bullet better than Intel ? The processors are binary compatible. Yet the AMD one isn't as affected. AMD has one-tenth the staff of Intel. Takata made airbags using a propellant guaranteed to cause problems. When another material was discussed for the job, they decided not to use it, because it cost a bit more. They thought the issue was "manageable". As for Intel, we'll probably never hear the history of this one, and how they ended up where they are today. I'm sure their architecture-class staff could tell a story or two, over a beer. Paul |
#24
|
|||
|
|||
Microcode Update?
mike wrote:
Perhaps that's the confusion. Loaded at boot is volatile. Technically I suppose microcode loaded by BIOS is volatile too, the CPU wakes up with the factory microcode, the BIOS immediately updates it the microcode stored in flash, and possibly the O/S updates the microcode again if it has a later version than the BIOS does. The CPU is never permanently updated with newer microcode. The word "update" implies, to me, a non-volatile fix/patch that needs to be done once. So, we're overlaying the the microcode that the BIOS loaded at power up with microcode that the OS provides?? That gives me more confidence that the "update" won't bork my BIOS. It shouldn't have to do anything with the BIOS. If you somehow end up with bad microcode in your BIOS flash, which the BIOS always gives to the CPU at power-on, you've no way out unless you start removing flash chips and replacing them. At least if the microcode is updated by the O/S you can boot from different media if you need to ... |
#25
|
|||
|
|||
Microcode Update?
Andy Burns wrote:
Ant wrote: microcode: CPU0 sig=0x10677 revision=0x705 which seems to be from 2008-04-28 Whatever CPU that is, I think the latest microcode update was 2010-09-29 rev 0x070a CPU: Intel Core 2 Q8200 (quad-core; default clock speeds; Socket 775 LGA) Mobo: MSI P43 NEO3-F (MSI-7514) -- Quote of the Week: "Did the ant fall off the toilet seat because she was ****ed off?" --unknown Note: A fixed width font (Courier, Monospace, etc.) is required to see this signature correctly. /\___/\ Ant(Dude) @ http://antfarm.home.dhs.org / /\ /\ \ Please nuke ANT if replying by e-mail privately. If credit- | |o o| | ing, then please kindly use Ant nickname and URL/link. \ _ / ( ) |
#26
|
|||
|
|||
Microcode Update?
Andy Burns wrote:
Pat wrote: Anyone here know how microcode updates work with modern processors? They can be installed from the BIOS, or failing that the O/S can update it after being booted by the BIOS. I have an ASRock motherboard that no longer seems to receive BIOS updates, but the Linux kernel replaces the microcode (every time it starts, it isn't stored permanently in the CPU), I recently got a new microcode for the spectre mitigation # dmesg | grep -i microcode [ 0.000000] microcode: microcode updated early to revision 0x23, date = 2017-11-20 [ 0.718520] microcode: sig=0x306c3, pf=0x2, revision=0x23 [ 0.718669] microcode: Microcode Update Driver: v2.2. Maybe some manufacturers will start re-releasing BIOS updates for older motherboards purely with updated microcode in them? There's no point patching 2008 motherboards, if Intel is only patching 2013 or later processors. I only have one CPU which is on the list, and mine barely made it to the microcode file. My motherboard for that CPU, will definitely not be receiving a new BIOS. It's about two years too late for that. The only constructive patches mentioned, were for processors with BTB with PCID feature (that allows purging the BTB on a per-process basis), which causes less upset. And I haven't read a description of what Intel fixed there or what behavior changed. These are easiest to distribute through your OS microcode loader. Intel Processor Microcode Package for Linux 20180108 Release -- Updates upon 20171117 release -- === delta, since this date IVT C0 (06-3e-04:ed) 428-42a === my Q3'13 processor SKL-U/Y D0 (06-4e-03:c0) ba-c2 BDW-U/Y E/F (06-3d-04:c0) 25-28 HSW-ULT Cx/Dx (06-45-01:72) 20-21 Crystalwell Cx (06-46-01:32) 17-18 BDW-H E/G (06-47-01:22) 17-1b HSX-EX E0 (06-3f-04:80) 0f-10 SKL-H/S R0 (06-5e-03:36) ba-c2 HSW Cx/Dx (06-3c-03:32) 22-23 HSX C0 (06-3f-02:6f) 3a-3b BDX-DE V0/V1 (06-56-02:10) 0f-14 BDX-DE V2 (06-56-03:10) 700000d-7000011 KBL-U/Y H0 (06-8e-09:c0) 62-80 KBL Y0 / CFL D0 (06-8e-0a:c0) 70-80 KBL-H/S B0 (06-9e-09:2a) 5e-80 CFL U0 (06-9e-0a:22) 70-80 CFL B0 (06-9e-0b:02) 72-80 SKX H0 (06-55-04:b7) 2000035-200003c GLK B0 (06-7a-01:01) 1e-22 A 6c3 or a 677 aren't in that list. If the motherboard socket spanned a wide enough epoch, then your motherboard *might* get a new BIOS, but since those processors aren't getting patched, you'd get nothing of value for your processor, with regard to generic/future Spectre attacks. Like, say a BIOS was released, and it looked like this for the eight processor types supported old 677 (same microcode as in the last BIOS update) old 6c3 (same microcode as in the last BIOS update) old new 63e (new microcode with revision 42a) ... Then installing that BIOS for your 677 or 6c3 achieves nothing. Each microcode is signed, and the processor only "accepts" such submissions, if the "signing" matches. A 63e microcode will be ignored by a 677 processor. And vice versa. The revision field is likely only a byte wide. When you see a lead digit, you should ignore it. The CPU starts at 00, and the microcode in my case (42a for 63e), that would be 2a. Previously in Linux, I got 28, and when testing yesterday, the 28 changed to 2a when Linux booted. Windows 10 is still running 28. And some other Linux CD I tried, resulted in 16, just to give some idea that multiple microcode updates have been received in the past. They normally patch timing or logic issues, not security. Say a processor doesn't return the right condition code when doing arithmetic - that might be more suited to microcode. Changing the behavior of functional units, is way way out in left field. I don't know how they can systematically leave "adjustment knobs" all over the place to change branch target buffers, translation lookaside buffers, page table mechanisms, all sorts of complicated stuff. If you know something is going to break, surely it's as easy to fix it right away, as to leave some "knob" dangling off the side of the black box function. and when you put "knobs" on things, you also have to design test benches in your simulator, to make sure you didn't break the primary function while implementing the change. Paul |
#27
|
|||
|
|||
Microcode Update?
Bob F wrote in news
Remember, the actual hardware natively only executes instructions like compare, add/subtract, move, etc. The kinds of things one would load by hand in binary back in the old days. CPU designers have layered microcode on top of that to allow compilers to issue more complex instructions that the microcode will then break down into the atomic instructions the hardware recognizes. I don't know how old some of you are, but back around the turn of the century there was a big foofurah about RISK (reduced instruction set) processors. What those did was reduce or eliminate the microcode, so that the compilers were forced to actually output atomic instructions that could be run immediately without microcode. The thought was that there were times when the microcode was executing instructions that weren't really needed. The Holy Grail of RISK processors was 'one instruction, one clock cycle', as opposed to the multiple cycles most microcode instructions took. It made the compiler do more work, but that was seen as a one time thing, and was counter-balanced by faster execution. At the time, this was early Pentium days, it did make a difference. Now that the hardware has gotten so fast, there really is no advantage to using the RISK architecture, so for the most part it has gone by the wayside. What I am trying to show here is that the actual hardware can only execute the few atomic instructions designed into the die. Most of the complete processor instructions set is actually executed in microcode that breaks each complex instruction down into multiple atomic instructions for execution. So yes, microcode is loaded every time the processor resets/powers up, and can thus be upgraded by a new BIOS version. On 1/15/2018 11:54 AM, Andy Burns wrote: mike wrote: Exactly what is microcode in this context? Recent intel processors don't natively execute x86 or x86_64 instructions that compilers or humans produce, they use a lower level internal microcoded instruction set.Â* So to a limited degree they can issue new microcode (which the CPU will only accept if it recognises a signature on it) that alters how the processor actually runs. It appears that there's a new class of microcode that can directly change persistent code within the microprocessor itself??? No intel CPU microcode needs to be loaded into the CPU at every reboot (by the BIOS, or by the O/S) Part of the BIOS is microcode for each processor it can handle. I have gone through the process of modifying the BIOS for motherboards to allow them to handle processors they were not designed for. I would think this is the microcode they are talking about. |
#28
|
|||
|
|||
Microcode Update?
Tim wrote:
Bob F wrote in news Remember, the actual hardware natively only executes instructions like compare, add/subtract, move, etc. The kinds of things one would load by hand in binary back in the old days. CPU designers have layered microcode on top of that to allow compilers to issue more complex instructions that the microcode will then break down into the atomic instructions the hardware recognizes. I don't know how old some of you are, but back around the turn of the century there was a big foofurah about RISK (reduced instruction set) processors. What those did was reduce or eliminate the microcode, so that the compilers were forced to actually output atomic instructions that could be run immediately without microcode. The thought was that there were times when the microcode was executing instructions that weren't really needed. The Holy Grail of RISK processors was 'one instruction, one clock cycle', as opposed to the multiple cycles most microcode instructions took. It made the compiler do more work, but that was seen as a one time thing, and was counter-balanced by faster execution. At the time, this was early Pentium days, it did make a difference. Now that the hardware has gotten so fast, there really is no advantage to using the RISK architecture, so for the most part it has gone by the wayside. What I am trying to show here is that the actual hardware can only execute the few atomic instructions designed into the die. Most of the complete processor instructions set is actually executed in microcode that breaks each complex instruction down into multiple atomic instructions for execution. So yes, microcode is loaded every time the processor resets/powers up, and can thus be upgraded by a new BIOS version. RISC is still around. And MIPS "isn't dead yet", because chips based on it, are used in routers and the like. A venture capital firm bought the MIPS group. So if new MIPS chips are to be spun, there is a body to help. https://en.wikipedia.org/wiki/MIPS_Technologies The CISC instruction set doesn't have to take multiple cycles for every instruction. Some instructions (especially ones register to register), should execute in a single cycle. They wouldn't need microcode. More complex instructions may require microcoding, to save on dedicated resources to make the instruction work. Most of the instruction store will be non-volatile (ROM). The Writeable Control Store (Microcode) allows trapping an instruction, and replacing it with a sequence of simpler operations. And that's how a "bad" instruction can be patched. I could replace a "bad" 4 cycle instruction, with a repaired 4 cycle instruction. I could trap a bad single cycle instruction, and replace it with a 3 cycle sequence. Generally, the replacement should not be faster. If the instruction is infrequently used, nobody notices this. Instruction trapping has been around for a long time. When you added a FPU to your CPU back in the old days, an "F line" instruction would trap, and the FPU would do the work instead of the CPU. If the FPU was not present on the motherboard, the operation could be emulated in some (very slow) stream of instructions by the CPU. Almost like "taking an interrupt". This allowed computer owners to pony up some $$$ for an FPU chip, if they wanted the equivalent of Excel to run faster. In current times, you can have two FPUs on the CPU die, and no tricks are needed. Even an FPU doesn't complete complex math instructions in one clock cycle. Every FPU is a space/time tradeoff, and the slower they make it, the fewer square mm it takes to implement. And then you have room for multiple of them, and can retire two floating point operations in the same tick. An FPU is microcoded in a sense, as you have normalize and denormalize as part of the sequence. https://electronics.stackexchange.co...-point-numbers If I use Booths Algorithm, I can cut the multiply part of the Mantissa by a factor of two. http://www.cs.cornell.edu/courses/cs314/2004fa/l12.pdf https://en.wikipedia.org/wiki/Booth%...tion_algorithm Handling the exponent, normalizing and so on, comes after that. On 1/15/2018 11:54 AM, Andy Burns wrote: mike wrote: Exactly what is microcode in this context? Recent intel processors don't natively execute x86 or x86_64 instructions that compilers or humans produce, they use a lower level internal microcoded instruction set. So to a limited degree they can issue new microcode (which the CPU will only accept if it recognises a signature on it) that alters how the processor actually runs. It appears that there's a new class of microcode that can directly change persistent code within the microprocessor itself??? No intel CPU microcode needs to be loaded into the CPU at every reboot (by the BIOS, or by the O/S) Part of the BIOS is microcode for each processor it can handle. I have gone through the process of modifying the BIOS for motherboards to allow them to handle processors they were not designed for. I would think this is the microcode they are talking about. The BIOS typically has room for 8 microcodes (the ones I dissected were like that). Since a particular socket ("LGA775") only supports a limited range of CPUs, that's "complete coverage" as far as the motherboard maker is concerned. An example of a failure, would be my Tualatin on the P2B-S. The BIOS used to call it a "Pentium II", because it didn't know any better. By manually installing a 2KB microcode for the Tualatin, in the Award BIOS microcode cache (a storage area outside of microcode.dat), I was able to patch the P2B-S so that it said "Pentium III" when it booted :-) That's an example of a situation, where a user didn't need the motherboard maker, to fix stuff. I doubt you can do this any more, as microcode lengths now are variable length, in multiples of 2KB. And I don't know if the Award-specific API exists any more. Whereas the microcode loader for the OS, has microcode for *hundreds* of CPUs. All the way back to the dawn of time. I doubt they even bother trimming off the irrelevant ones, as the file from Intel is relatively small, and can just be pumped into the loader sight-unseen. Each microcode is signed and has a family code in the header, and as long as Intel has unique identifiers for processors, there's no danger a "P5" microcode will go into a "Coffee Lake" by accident. Paul |
#29
|
|||
|
|||
Microcode Update?
Paul wrote in news
Whereas the microcode loader for the OS, has microcode for *hundreds* of CPUs. All the way back to the dawn of time. I doubt they even bother trimming off the irrelevant ones, as the file from Intel is relatively small, and can just be pumped into the loader sight-unseen. Each microcode is signed and has a family code in the header, and as long as Intel has unique identifiers for processors, there's no danger a "P5" microcode will go into a "Coffee Lake" by accident. Paul That sounds kinda like what IBM did with their OSs for the /370 line of mainframes. I took an IBM assembler class one time in the late 80s, and the instructor was great. He told us about how IBM would add new functions to the CPU by writing another layer of code that would combine several operations from the current code into one instruction, and that they had done that for several layers of code, so that a single instruction from the user program could wind up executing twenty or more intermediate instructions on its way down to the metal. His take was that every new itteration of hardware was enough faster that it wouldn't pay for IBM to go back and code the OS from scratch this time. There was a Japanese company that came out with a code-compatible mainframe that was supposed to be bigger, better, faster, etc. One of the selling points given to the techies was that they HAD gone back and provided compatability without all that overhead because they had started from scratch so much later in the design cycle of the /370s. I want to say Fujitsu, but can't say for certain. |
#30
|
|||
|
|||
Microcode Update?
On Fri, 19 Jan 2018 04:50:03 GMT, Tim wrote:
There was a Japanese company that came out with a code-compatible mainframe that was supposed to be bigger, better, faster, etc. One of the selling points given to the techies was that they HAD gone back and provided compatability without all that overhead because they had started from scratch so much later in the design cycle of the /370s. I want to say Fujitsu, but can't say for certain. I seem to recall that Fujitsu was the parent company and the computer division was named FACOM . |
Thread Tools | |
Display Modes | Rate This Thread |
|
|