On Thu, Jan 30, 2014 at 02:41:09PM -0500, Boris Ostrovsky wrote:
> That's not sufficient though, you'll need the other piece in
> find_ucode_in_initrd() where you check the header.
I meant wrt to looking at ucode_cpio.data. The other piece remains.
> I like this one better. You can move this chec
On 01/30/2014 10:13 AM, Borislav Petkov wrote:
On Wed, Jan 29, 2014 at 12:22:19AM +0100, Borislav Petkov wrote:
Are you sure that
container = (u8 *)(__va((u32)relocated_ramdisk) +
((u32)container -
boot_params.hdr.ramdisk_image));
in save_microcode_in_initrd_amd(
On Wed, Jan 29, 2014 at 12:22:19AM +0100, Borislav Petkov wrote:
> > >Are you sure that
> > >
> > >container = (u8 *)(__va((u32)relocated_ramdisk) +
> > > ((u32)container -
> > >boot_params.hdr.ramdisk_image));
> > >
> > >in save_microcode_in_initrd_amd() always result
On Tue, Jan 28, 2014 at 06:10:59PM -0500, Boris Ostrovsky wrote:
> The patch seems to have fixed the problem.
Thanks, I'll add your Reported-and-tested-by.
>> I'll give it a spin. Apparently the problem is currently in
>> install_equiv_cpu_table() when we are trying to index into buf and
>> buf (
On 01/28/2014 04:37 PM, Boris Ostrovsky wrote:
On 01/28/2014 04:30 PM, Borislav Petkov wrote:
On Tue, Jan 28, 2014 at 04:05:20PM -0500, Boris Ostrovsky wrote:
Yes. This was a bug in our build environment. It is fixed now but I
put this bug back when I was testing your patch.
Right, that was th
On 01/28/2014 04:30 PM, Borislav Petkov wrote:
On Tue, Jan 28, 2014 at 04:05:20PM -0500, Boris Ostrovsky wrote:
Yes. This was a bug in our build environment. It is fixed now but I
put this bug back when I was testing your patch.
Right, that was the deal. Oh well, we'd need to verify the contain
On Tue, Jan 28, 2014 at 04:05:20PM -0500, Boris Ostrovsky wrote:
> Yes. This was a bug in our build environment. It is fixed now but I
> put this bug back when I was testing your patch.
Right, that was the deal. Oh well, we'd need to verify the container
too, I guess:
---
diff --git a/arch/x86/ke
On 01/28/2014 03:52 PM, Borislav Petkov wrote:
On Tue, Jan 28, 2014 at 03:43:57PM -0500, Boris Ostrovsky wrote:
It fixes the case when there is no microcode in initrd but when
microcode is corrupted (as was the case when we were pointing to Intel
binary) we still die. Neither container nor ucode
On Tue, Jan 28, 2014 at 03:43:57PM -0500, Boris Ostrovsky wrote:
> It fixes the case when there is no microcode in initrd but when
> microcode is corrupted (as was the case when we were pointing to Intel
> binary) we still die. Neither container nor ucode_cpio.data is NULL in
> this case.
How is t
On 01/28/2014 11:24 AM, Borislav Petkov wrote:
On Thu, Jan 23, 2014 at 02:41:59PM -0500, Boris Ostrovsky wrote:
32-bit only.
Ok, I think I know what happens. Can you try this one (I missed doing
this on 32-bit and 64-bit does it, which would explain why it didn't
explode there):
---
diff --git
On Thu, Jan 23, 2014 at 02:41:59PM -0500, Boris Ostrovsky wrote:
> 32-bit only.
Ok, I think I know what happens. Can you try this one (I missed doing
this on 32-bit and 64-bit does it, which would explain why it didn't
explode there):
---
diff --git a/arch/x86/kernel/cpu/microcode/amd_early.c
b/
On 01/23/2014 02:29 PM, Borislav Petkov wrote:
On Thu, Jan 23, 2014 at 01:08:46PM -0500, Boris Ostrovsky wrote:
So I tried this on a "good" system and I am pretty sure this is
broken. I don't have any microcode in initrd and I am still dying in
load_microcode_amd().
32-bit still or 64-bit?
32
On Thursday 23 January 2014, Boris Ostrovsky wrote:
>Right. But the (suspected) regression is from this Monday's merge
>of early microcode loading code.
>
>-boris
Ahh, I missed that in the OP then. I'll get me coat.
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap,
On Thu, Jan 23, 2014 at 01:08:46PM -0500, Boris Ostrovsky wrote:
> So I tried this on a "good" system and I am pretty sure this is
> broken. I don't have any microcode in initrd and I am still dying in
> load_microcode_amd().
32-bit still or 64-bit?
> I didn't dig any further but if you can't rep
On 01/23/2014 01:54 PM, Gene Heskett wrote:
On Thursday 23 January 2014, Boris Ostrovsky wrote:
On 01/21/2014 01:25 PM, Borislav Petkov wrote:
On Tue, Jan 21, 2014 at 12:55:53PM -0500, Boris Ostrovsky wrote:
cat $(AMD_UCODE_PATH)/* >
ucode_initrd/kernel/x86/microcode/AuthenticAMD.bi
On Thursday 23 January 2014, Boris Ostrovsky wrote:
>On 01/21/2014 01:25 PM, Borislav Petkov wrote:
>> On Tue, Jan 21, 2014 at 12:55:53PM -0500, Boris Ostrovsky wrote:
>>> cat $(AMD_UCODE_PATH)/* >
>>>
>>> ucode_initrd/kernel/x86/microcode/AuthenticAMD.bin
>>>
>>> (cd ucode_init
On 01/21/2014 01:25 PM, Borislav Petkov wrote:
On Tue, Jan 21, 2014 at 12:55:53PM -0500, Boris Ostrovsky wrote:
cat $(AMD_UCODE_PATH)/* >
ucode_initrd/kernel/x86/microcode/AuthenticAMD.bin
(cd ucode_initrd;find . | cpio -o -H newc >
../$(DISTDIR)/common/ucode_initrd.cpio)
On Tue, Jan 21, 2014 at 12:55:53PM -0500, Boris Ostrovsky wrote:
> cat $(AMD_UCODE_PATH)/* >
> ucode_initrd/kernel/x86/microcode/AuthenticAMD.bin
> (cd ucode_initrd;find . | cpio -o -H newc >
> ../$(DISTDIR)/common/ucode_initrd.cpio)
> ...
> cat $(DISTDIR)/common/uco
On Tue, Jan 21, 2014 at 10:39:21AM -0500, Boris Ostrovsky wrote:
> I was thinking this could have been introduced by last night's merge
> of your tree.
Ok, I need more info:
* kernel .config
* are you building an initrd with the microcode? If so, how exactly?
Which microcode blob?
* what machin
19 matches
Mail list logo
