lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 19 Dec 2016 20:40:00 -0500
From:   Boris Ostrovsky <boris.ostrovsky@...cle.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/microcode: Adjust ramdisk address when accessing by
 virtual address



On 12/19/2016 08:27 PM, Boris Ostrovsky wrote:
>
>
> On 12/19/2016 06:32 PM, Borislav Petkov wrote:
>> On Mon, Dec 19, 2016 at 07:43:40PM +0100, Borislav Petkov wrote:
>>> On Mon, Dec 19, 2016 at 01:12:25PM -0500, Boris Ostrovsky wrote:
>>>> IIUIC find_microcode_in_initrd() is called with paging on only on Intel
>>>> (which is where I observed it).
>>>
>>> Ah, that was an important fact. Yes, I can repro it now.
>>
>> Ok, questions:
>>
>> * does your guest relocate the ramdisk?
>
>
> This is not a guest. I crashed with baremetal kernel.
>
>
>>
>> I.e., do you see something like this in dmesg before the splat:
>>
>> [    0.000000] RAMDISK: [mem 0x7f84c000-0x7ffcffff]
>> [    0.000000] Allocated new RAMDISK: [mem 0x3647a000-0x36bfd9e6]
>> [    0.000000] Move RAMDISK from [mem 0x7f84c000-0x7ffcf9e6] to [mem
>> 0x3647a000-0x36bfd9e6]
>>            ^^^^^^^^^^^^^^


Sorry, forgot about this: I see the first line but not the other two (so 
the relocation did not occur).


-boris

>>
>> If not, then I know what happens.
>>
>> Also, does it work if you change these lines:
>>
>>         if (!use_pa && relocated_ramdisk)
>>                 start = initrd_start;
>>
>> to:
>>
>>         if (!use_pa)
>>                 start = initrd_start;
>
> Yes, it does.
>
> I also thought it might be better but I haven't gone through the code to
> make sure this would always work.
>
> I can run more tests tomorrow if you want.
>
> -boris
>
>>
>>
>> Because if that works, I can actually simplify that function radically.
>>
>> But more tomorrow.
>>
>> Thanks.
>>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ