From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F0CB5C4360F for ; Thu, 4 Apr 2019 07:48:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C2944214AF for ; Thu, 4 Apr 2019 07:48:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727321AbfDDHsY (ORCPT ); Thu, 4 Apr 2019 03:48:24 -0400 Received: from mail.cn.fujitsu.com ([183.91.158.132]:45177 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725914AbfDDHsX (ORCPT ); Thu, 4 Apr 2019 03:48:23 -0400 X-IronPort-AV: E=Sophos;i="5.60,306,1549900800"; d="scan'208";a="58459807" Received: from unknown (HELO cn.fujitsu.com) ([10.167.33.5]) by heian.cn.fujitsu.com with ESMTP; 04 Apr 2019 15:48:21 +0800 Received: from G08CNEXCHPEKD01.g08.fujitsu.local (unknown [10.167.33.80]) by cn.fujitsu.com (Postfix) with ESMTP id 1A4444CD80C3; Thu, 4 Apr 2019 15:48:21 +0800 (CST) Received: from localhost.localdomain (10.167.225.56) by G08CNEXCHPEKD01.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 4 Apr 2019 15:48:28 +0800 Date: Thu, 4 Apr 2019 15:48:17 +0800 From: Chao Fan To: Dave Young CC: "bhe@redhat.com" , Junichi Nomura , Borislav Petkov , "kasong@redhat.com" , "x86@kernel.org" , "kexec@lists.infradead.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel Message-ID: <20190404074817.GM1555@localhost.localdomain> References: <20190403082305.GG1555@localhost.localdomain> <20190403090210.GH1555@localhost.localdomain> <20190404025234.GA12658@dhcp-128-65.nay.redhat.com> <20190404030037.GT7627@MiWiFi-R3L-srv> <20190404031030.GU7627@MiWiFi-R3L-srv> <20190404032238.GA16267@dhcp-128-65.nay.redhat.com> <20190404064130.GA5530@dhcp-128-65.nay.redhat.com> <20190404072007.GL1555@localhost.localdomain> <20190404074102.GA5970@dhcp-128-65.nay.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20190404074102.GA5970@dhcp-128-65.nay.redhat.com> User-Agent: Mutt/1.11.3 (2019-02-01) X-Originating-IP: [10.167.225.56] X-yoursite-MailScanner-ID: 1A4444CD80C3.A8FF3 X-yoursite-MailScanner: Found to be clean X-yoursite-MailScanner-From: fanc.fnst@cn.fujitsu.com Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 04, 2019 at 03:41:02PM +0800, Dave Young wrote: >Hi Chao, >On 04/04/19 at 03:20pm, Chao Fan wrote: >> On Thu, Apr 04, 2019 at 02:41:30PM +0800, Dave Young wrote: >> >On 04/04/19 at 11:22am, Dave Young wrote: >> >> On 04/04/19 at 11:10am, Baoquan He wrote: >> >> > On 04/04/19 at 11:00am, Baoquan He wrote: >> >> > > On 04/04/19 at 10:52am, Dave Young wrote: >> >> > > > On 04/04/19 at 01:23am, Junichi Nomura wrote: >> >> > + /* Save RSDP address for later use. */ >> >> > + boot_params->acpi_rsdp_addr = get_rsdp_addr(); >> >> > + >> >> > + error("Hang kernel for kexec debugging"); >> >> > >> >> > Sorry, here I means calling error() to hang kernel after calling >> >> > get_rsdp_addr(). >> >> >> >> Thanks, it did not hang, it always reset to firmware/grub boot menu. >> >> I'm pretty sure now the bug exists in get_rsdp_addr(). >> > >> >static acpi_physical_address kexec_get_rsdp_addr(void) >> >{ >> >... >> > /* Get systab from boot params. */ >> > systab = (efi_system_table_64_t *) (ei->efi_systab | ((__u64)ei->efi_systab_hi << 32)); >> > if (!systab) >> > error("EFI system table not found in kexec boot_params."); >> > >> >... >> > -> add error("hang me") here will have a hang >> >... >> > return __efi_get_rsdp_addr((unsigned long)esd->tables, >> > systab->nr_tables, true); >> > >> >> I have an idea, but not sure whether is a problem. >> In code of Nomura: >> >> #if defined(CONFIG_EFI) && defined(CONFIG_X86_64) >> [...] >> if (strncmp(sig, EFI64_LOADER_SIGNATURE, 4)) { >> debug_putstr("Wrong kexec EFI loader signature.\n"); >> return 0; >> } >> >> /* Get systab from boot params. */ >> systab = (efi_system_table_64_t *) (ei->efi_systab | ((__u64)ei->efi_systab_hi << 32)); >> [...] >> #endif >> >> After review agian, I wonder what will happen if 32bit-efi boot 64bit >> OS. > >It is hard to find 32bit efi hardware, I can confirm all the laptop I >have are 64bit efi. > >In case 32bit efi EFI64_LOADER_SIGNATURE checking will be false. Yes, just when reviewing code, I notice this problem. Thanks, Chao Fan > >