Intel's Skylake Prime Number Bug.

Jerry Stuckle wrote:

Obviously if it's a microcode bug, an update should be able to fix it.
Even if it's a hardware bug, there might be a way around the bug in
the microcode.

That's not so obvious unless the microcode is in flash. Isn't it a mask
ROM?

--

"Skybuck Flying" writes:
Apperently Intel's Skylake Processors can freeze up when calculating certain
Prime Numbers.

I am investigating this story further, for now here is a link about it:

https://communities.intel.com/mobile...nts%2F52 4553

Will people replying to this please remove any irrelevant newsgroups,
particularly comp.lang.c? Thanks.

--
Keith Thompson (The_Other_Keith) http://www.ghoti.net/~kst
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Tom Del Rosso wrote:
Jerry Stuckle wrote:
Obviously if it's a microcode bug, an update should be able to fix it.
Even if it's a hardware bug, there might be a way around the bug in
the microcode.

That's not so obvious unless the microcode is in flash. Isn't it a mask
ROM?


Try page 431 here, section 9.11.1 "Microcode Update".
Microcode updates are a part of the BIOS flash image, and a
file in the BIOS file system contains a set of updates.
A typical file in the past, might have contained
eight patches. I used to dissect these, so I could
tell people whether there was a patch for their
non-standard processor or not. (Maybe someone stuffs
a Xeon into a regular desktop socket.)

https://web.archive.org/web/20110516...ual/253668.pdf

Intel don't generally give information about the "encrypted
data" within a patch.

Some processors, the patch area is only 2KB in size.
Later processors, the patching format was made variable
length, in multiples of 2KB. I've taken apart a BIOS
module before, and found some of the slightly longer
patches (at least 4KB long, maybe slightly longer).

Some processors have as many as 1000 instructions, and
it's not clear that the patch actually contains an entire
microcode. But without a document describing the encrypted
section, we'll never know. It's encrypted presumably to
prevent some sort of hacking (bypassing security features
such as they are).

Intel provides a file suitable for usage by Linux, and
this is a text file for inclusion in compiled code.
Unpack the tar file, get the .dat out, change the
file extension to text and have a look. You can then
compare the samples in here, to the header format
in the above architecture book.

https://downloadmirror.intel.com/181...e-20090927.tgz

/* Sun Sep 27 10:52:54 CST 2009 */
/* 727-MU168313.inc */
0x00000001, 0x00000013, 0x02062001, 0x00000683,
0x2f0da1b0, 0x00000001, 0x00000001, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0xbf5ad468, 0xc79f5237, 0xbd53889e, 0x896bfd13,
0x7adc0c8f, 0x44e9e0bc, 0x1a331fc9, 0x00b0f479,
0x53e9ceb3, 0xb14131a4, 0x39fc8310, 0x6993ee0d,
0xdb0c59b4, 0x67f24fd0, 0x63e83516, 0x0a4d411d,
0xb86a4294, 0x72c2edc5, 0xc543c5df, 0x7f3dd290,
....

The only vaguely interesting part, is the bit at the beginning,
as the encrypted body, we can't look at that. I'm sure someone
has figured out by now, how that is encrypted, and it's even
possible that is a variant design as well (encryption became
stronger with time). Whatever encryption they used in the P6
era, probably isn't strong enough any more.

Both the BIOS and the OS have a patcher. Patches are only
accepted, if the version number of the patch is higher than
the current version number loaded. And you can check whether
a patch has "taken" later, by using Intel PIU or similar.
So if I checked the BIOS and the version was 07 for your
processor, Intel PIU should report at least 07, and if the
OS loaded 11, then Intel PIU would report 11 instead of 07.
The BIOS must be able to patch out egregious bugs well enough
to allow OS booting to finish. The OS may have a later
version than the crusty old BIOS file content you were
given.

If Asus provides say, eight different versions of BIOS images
for your downloading pleasure, perhaps four of those contain
no substantive changes, and they have the latest versions of
Intel microcode content. So when it says "supports new processors",
sometimes that includes new microcode with a higher version
number. Part of the BIOS support is "recognition" code,
and some is "new microcode patches". Without recognition
code, the BIOS may declare "you have a P6", when you actually
have a Core2, that sort of thing. I have at least one computer
here, where the recognition is wrong, and the thing still works.
That's because I patched the microcode by hand, so the microcode
is actually up to date, but the recognition section, I didn't
have a way to modify that.

The BIOS also used to include a "microcode cache" function.
At least the BIOS for Award, there is a way to load the
microcode yourself, it is stored in flash in the BIOS.
It's non-volatile until you pull the CPU out of the
socket, and plug in another CPU. Doing so would purge the
cache, and you'd have to do the manual loading operation
again if you put the original processor back. The machine I
manually patched, I haven't pulled the processor out of it
since that. I probably wouldn't remember how to repeat
the procedure now. I was putting a Tualatin in a motherboard
that wasn't intended for Tualatin.

HTH,
Paul

On 11/01/16 20:12, John Larkin wrote:
On Mon, 11 Jan 2016 13:42:57 -0500, Jerry Stuckle

Nowadays processors (from micro to mainframe) are run by microcode.

Not all. Some RISC machines are pure logic. ARM, Coldfire, maybe MIPS?

(When the microcode based 68K architecture was being redesigned into a
RISC structure with little or no microcode for the Coldfire, the
designers planned to keep the microcoded division instructions. But
then someone noticed that a pure software division routine ran faster
than the microcoded division hardware, so support was dropped.)

One of the driving forces of "RISC" compared to older "CISC" designs was
to get rid of microcode.

And since by far most modern cpus (both in terms of the numbers
produced, and the number of designs) are microcontrollers, which almost
never use microcode, it's fair to say that only a small proportion of
currently active processors have microcode - even though those
processors are rather important.


Intels are still microcode based.


Yes, both Intel and AMD's x86 processors have a lot of microcode. But
they are not really "microcode based". Some parts, such as the FPU
(especially multi-cycle functions) are microcoded - but many other parts
are handled directly in hard logic. The distinction between what is
microcoded and what is hard logic is not easy to guess, and details are
considered part of the design secrets.

Microcode lets Intel and AMD do some fixes by microcode patches, either
using the BIOS (needed for Windows) or loaded by the Linux kernel at
startup.

On 12/01/16 10:06, David Brown wrote:
One of the driving forces of "RISC" compared to older "CISC" designs was
to get rid of microcode.

David, you're posting to five newsgroups whose only common factor is one
of their subscribers. I know it's not your doing, but could you please
trim comp.lang.c from followups in future? Thanks.

snip

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

On 12/01/16 11:21, Richard Heathfield wrote:
On 12/01/16 10:06, David Brown wrote:
One of the driving forces of "RISC" compared to older "CISC" designs was
to get rid of microcode.

David, you're posting to five newsgroups whose only common factor is one
of their subscribers. I know it's not your doing, but could you please
trim comp.lang.c from followups in future? Thanks.

snip


My apologies - I was not paying attention to the newsgroups.

(I'll trim c.l.c and other off-topic groups if I post again in this
thread, but the apologies need to go to the right places.)

First of all comparing hardware to software is comparing apples to oranges.

To compare intel processors with operating systems would require intel's
processors to be mostly software so they can be fixed !

Second of all some success in the past is no garantee for the future.

Currently Intel's products are a big fat mess.

(Reminds me of my first 80486 which produces weird pixels on the screen...
never really figured out what caused that though ! for now I assume
memory or graphics card related or could be co-processors... yes that rings
a bell... so again here we are...
1. 80486 co-processor problem (fpu)
2. pentium co-processor problem (fpu)
3. skylake co-processor problem ? (fpu)
Seems very much like Intel up to its old bad tricks again ! HA-HA ! )

Anyway back to skylake, very worrieing reports are in that this processors
locks up randomly while gaming !

Also intel is being very secretive about what the exact problem is.

This can't be good.

Either they don't know... but then their fix would be bogus.

Or they do know and it's something serious and they ain't telling !

Bye,
Skybuck.

On Tue, 12 Jan 2016 11:06:45 +0100, David Brown
wrote:

On 11/01/16 20:12, John Larkin wrote:
On Mon, 11 Jan 2016 13:42:57 -0500, Jerry Stuckle

Nowadays processors (from micro to mainframe) are run by microcode.

Not all. Some RISC machines are pure logic. ARM, Coldfire, maybe MIPS?

(When the microcode based 68K architecture was being redesigned into a
RISC structure with little or no microcode for the Coldfire, the
designers planned to keep the microcoded division instructions. But
then someone noticed that a pure software division routine ran faster
than the microcoded division hardware, so support was dropped.)

Some CPU, maybe the HPPA Risc or something, didn't even have a
multiply instruction. It cluttered the pipeline so they eliminated it.



One of the driving forces of "RISC" compared to older "CISC" designs was
to get rid of microcode.

And since by far most modern cpus (both in terms of the numbers
produced, and the number of designs) are microcontrollers, which almost
never use microcode, it's fair to say that only a small proportion of
currently active processors have microcode - even though those
processors are rather important.

I think the fundamental RISC concept is to design an instruction set
that's compiler friendly and not people friendly. CISC attempted to
make assembly programming look like a programming language; RISC
pretty much assumes that binaries are created by compilers.






Intels are still microcode based.


Yes, both Intel and AMD's x86 processors have a lot of microcode. But
they are not really "microcode based". Some parts, such as the FPU
(especially multi-cycle functions) are microcoded - but many other parts
are handled directly in hard logic. The distinction between what is
microcoded and what is hard logic is not easy to guess, and details are
considered part of the design secrets.

They are stuck with a CISC instruction set that was originally
microcoded. They have to work very hard to butcher that to make it
fast.



Microcode lets Intel and AMD do some fixes by microcode patches, either
using the BIOS (needed for Windows) or loaded by the Linux kernel at
startup.

Less bugs is another approach.


--

John Larkin Highland Technology, Inc

lunatic fringe electronics

On Tue, 12 Jan 2016 02:45:15 -0500, "Tom Del Rosso"
wrote:

Jerry Stuckle wrote:

Obviously if it's a microcode bug, an update should be able to fix it.
Even if it's a hardware bug, there might be a way around the bug in
the microcode.

That's not so obvious unless the microcode is in flash. Isn't it a mask
ROM?

Microcode patches are often done in RAM. BIOS loads the patches every
reset.

On Tue, 12 Jan 2016 16:35:26 +0100, "Skybuck Flying"
Gave us:

Currently Intel's products are a big fat mess.

You're a goddaMNED TOTAL RETARD.

(Reminds me of my first 80486 which produces weird pixels on the screen...
never really figured out what caused that though !

YOU'RE A GODDAMNED RETARDED IDIOT AS WELL.


And you are a Usenet abusing cross-posting uncivil retarded punk as
well.

Your ISP should ****can you for that stupid **** alone. ESPECIALLY
since you have been told to STOP the stupid behavior several times.