A Windows XP help forum. PCbanter

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.

Go Back   Home » PCbanter forum » Windows 10 » Windows 10 Help Forum
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

Microcode Update?



 
 
Thread Tools Rate Thread Display Modes
  #16  
Old January 16th 18, 02:26 AM posted to alt.comp.os.windows-10
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default 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  
Old January 16th 18, 05:28 AM posted to alt.comp.os.windows-10
...w¡ñ§±¤ñ[_2_]
external usenet poster
 
Posts: 54
Default 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  
Old January 16th 18, 06:05 AM posted to alt.comp.os.windows-10
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default 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  
Old January 16th 18, 06:18 AM posted to alt.comp.os.windows-10
mike[_10_]
external usenet poster
 
Posts: 1,073
Default 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  
Old January 16th 18, 06:40 AM posted to alt.comp.os.windows-10
Melzzzzz[_3_]
external usenet poster
 
Posts: 119
Default 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  
Old January 16th 18, 07:11 AM posted to alt.comp.os.windows-10
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default 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  
Old January 16th 18, 07:20 AM posted to alt.comp.os.windows-10
...w¡ñ§±¤ñ[_2_]
external usenet poster
 
Posts: 54
Default 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  
Old January 16th 18, 08:11 AM posted to alt.comp.os.windows-10
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default 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  
Old January 16th 18, 12:12 PM posted to alt.comp.os.windows-10
Andy Burns[_6_]
external usenet poster
 
Posts: 1,318
Default 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  
Old January 17th 18, 02:09 AM posted to alt.comp.os.windows-10
Ant[_2_]
external usenet poster
 
Posts: 554
Default 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  
Old January 17th 18, 05:29 AM posted to alt.comp.os.windows-10
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default 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  
Old January 17th 18, 10:56 PM posted to alt.comp.os.windows-10
Tim[_10_]
external usenet poster
 
Posts: 249
Default 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  
Old January 18th 18, 02:01 AM posted to alt.comp.os.windows-10
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default 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  
Old January 19th 18, 05:50 AM posted to alt.comp.os.windows-10
Tim[_10_]
external usenet poster
 
Posts: 249
Default 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  
Old January 19th 18, 09:10 PM posted to alt.comp.os.windows-10
Monty
external usenet poster
 
Posts: 598
Default 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
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off






All times are GMT +1. The time now is 05:31 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 PCbanter.
The comments are property of their posters.