1 |
On Monday 17 January 2011 10:48:36 Mark Knecht wrote: |
2 |
> On Mon, Jan 17, 2011 at 10:10 AM, BRM <bm_witness@×××××.com> wrote: |
3 |
> > ----- Original Message ---- |
4 |
> > |
5 |
> >> I have two questions: |
6 |
> >> |
7 |
> >> 1) Do I have to enable microcode updates in the BIOS of my Crosshair |
8 |
> >> IV Formula to activate microcodes push in the CPU by the module |
9 |
> >> "microcode" ? (AMD Phenom X6 1090T) |
10 |
> > |
11 |
> > Not sure about BIOS, but the Linux Kernel you are running will certainly |
12 |
> > need support enabled too. |
13 |
> > |
14 |
> >> 2) Does anyone know, what these microcodes do? They are fixes for... |
15 |
> >> ...what? |
16 |
> > |
17 |
> > The Intel and AMD processors are more abstract than physical now. With |
18 |
> > i486 and earlier the processors were typically hard wired; hardware |
19 |
> > "bug" fixes could not be pushed out. |
20 |
> > Intel's Pentium (and I don't know which AMD) started using micro-code to |
21 |
> > program the processor. This enabled them to push out "hardware" bug |
22 |
> > fixes for the processors. |
23 |
> > |
24 |
> > So what happens is the x86 instruction (e.g. mov ax, bx) gets translated |
25 |
> > to micro-code first, then it gets processed, and the result translated |
26 |
> > back to the expected instruction result - essentially, emulating the |
27 |
> > x86 instruction set in the processor. That's the simple version. |
28 |
> > |
29 |
> > So now when they discover a bug in the hardware they can push out a |
30 |
> > micro-code update to either fix the "hardware" (microcode) bug or work |
31 |
> > around a hardware (physical hardware) bug. |
32 |
> > |
33 |
> > Ben |
34 |
> |
35 |
> Ben, |
36 |
> Do you know how security on these updates is handled? Seems to me |
37 |
> this is an area rife for exploitation so I've been very hesitant to |
38 |
> use them until I understood more. |
39 |
|
40 |
you can not not use them because alsmost all bios load the microcode |
41 |
automatically. |