From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935519AbcLTOkV (ORCPT ); Tue, 20 Dec 2016 09:40:21 -0500 Received: from mail.skyhub.de ([78.46.96.112]:54364 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935237AbcLTOkS (ORCPT ); Tue, 20 Dec 2016 09:40:18 -0500 Date: Tue, 20 Dec 2016 15:40:12 +0100 From: Borislav Petkov To: Boris Ostrovsky Cc: x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86/microcode: Adjust ramdisk address when accessing by virtual address Message-ID: <20161220144012.lc4cwrg6dphqbyqu@pd.tnic> References: <1482161533-21097-1-git-send-email-boris.ostrovsky@oracle.com> <20161219153714.rhbpvcauc5xigzua@pd.tnic> <383d2984-fdd0-a198-4477-677b992fc955@oracle.com> <20161219164027.ejbf3h6qsnkjjezy@pd.tnic> <20161219180709.2tsvsebagdiyxxrs@pd.tnic> <20161219184340.4tzv2hg2vf3n63b7@pd.tnic> <20161219233229.p5uw2thbl55o26ds@pd.tnic> <22d4e277-81bb-ef10-3f55-f8f947df60e8@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20161014 (1.7.1) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 19, 2016 at 08:40:00PM -0500, Boris Ostrovsky wrote: > Sorry, forgot about this: I see the first line but not the other two (so the > relocation did not occur). Good, that's what I expected. Now it makes sense. So the reason why it didn't trigger here is that my Intel 32-bit .config always relocates the ramdisk. And that was taken care of. But not the case where it didn't relocate it. I.e., your case. The fix below should generalize the situation to *always* read initrd_start when we're running late, with VAs and after reserve_initrd() has run and potentially moved the ramdisk. > > 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. Yes please. Here's a minimal patch for 4.10. Please run it on your setup to verify it fixes your issue. It boots fine on my boxes here, FWIW. --- From: Borislav Petkov Date: Tue, 20 Dec 2016 11:54:30 +0100 Subject: [PATCH] x86/microcode/AMD: Reload proper initrd start address When we switch to virtual addresses and, especially after reserve_initrd()->relocate_initrd() have run, we have the updated initrd address in initrd_start. Use initrd_start then instead of the address which has been passed to us through boot params. (That still gets used when we're running the very early routines on the BSP). Reported-by: Boris Ostrovsky Signed-off-by: Borislav Petkov --- arch/x86/kernel/cpu/microcode/core.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c index c4bb2f7169f6..2af69d27da62 100644 --- a/arch/x86/kernel/cpu/microcode/core.c +++ b/arch/x86/kernel/cpu/microcode/core.c @@ -243,14 +243,12 @@ struct cpio_data find_microcode_in_initrd(const char *path, bool use_pa) # endif /* - * Did we relocate the ramdisk? - * - * So we possibly relocate the ramdisk *after* applying microcode on the - * BSP so we rely on use_pa (use physical addresses) - even if it is not - * absolutely correct - to determine whether we've done the ramdisk - * relocation already. + * Fixup the start address: after reserve_initrd() runs, initrd_start + * has the virtual address of the beginning of the initrd. It also + * possibly relocates the ramdisk. In either case, initrd_start contains + * the updated address so use that instead. */ - if (!use_pa && relocated_ramdisk) + if (!use_pa && initrd_start) start = initrd_start; return find_cpio_data(path, (void *)start, size, NULL); -- 2.11.0 -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.