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 9EA13C10F13 for ; Fri, 12 Apr 2019 00:23:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7168F2084D for ; Fri, 12 Apr 2019 00:23:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726897AbfDLAXx (ORCPT ); Thu, 11 Apr 2019 20:23:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60024 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726636AbfDLAXx (ORCPT ); Thu, 11 Apr 2019 20:23:53 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A3C3D85545; Fri, 12 Apr 2019 00:23:52 +0000 (UTC) Received: from localhost (ovpn-12-23.pek2.redhat.com [10.72.12.23]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 51A9D608BB; Fri, 12 Apr 2019 00:23:48 +0000 (UTC) Date: Fri, 12 Apr 2019 08:23:45 +0800 From: Baoquan He To: Junichi Nomura , Dave Young Cc: Borislav Petkov , Chao Fan , Kairui Song , "x86@kernel.org" , "kexec@lists.infradead.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v4] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel Message-ID: <20190412002345.GA6356@MiWiFi-R3L-srv> References: <20190408231011.GA5402@jeru.linux.bs1.fc.nec.co.jp> <20190410171431.GE26580@zn.tnic> <7cbc096d-0548-18b1-a335-8ba114f234a7@ce.jp.nec.com> <20190411080927.GA30080@zn.tnic> <20190411084235.GJ3805@localhost.localdomain> <1bb7bccb-0270-d073-fa2f-43e1a1c73fbe@ce.jp.nec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1bb7bccb-0270-d073-fa2f-43e1a1c73fbe@ce.jp.nec.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Fri, 12 Apr 2019 00:23:52 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/11/19 at 09:14am, Junichi Nomura wrote: > On 4/11/19 5:42 PM, Baoquan He wrote: > > On 04/11/19 at 08:16am, Junichi Nomura wrote: > >> kexec_get_rsdp_addr() might fail on kexec-booted kernel, e.g. if the > >> setup_data was invalid. In such a case, falling back to efi_get_rsdp_addr() > >> will hit the problem of accessing invalid table pointer again. > > > > Seems you are trying to address Dave Young's comment in > > http://lkml.kernel.org/r/20190404073233.GC5708@dhcp-128-65.nay.redhat.com > > Right. His "In case kexec_get_rsdp_addr failed.." comment. > > > We may need discuss and make clear if those are doable. E.g the first > > comment, if not hang by below line of code, returning 0 for what? Can > > kexec still be saved, or just reset to firmware? > > > > error("EFI system table not found in kexec boot_params.") > > If we return 0 and also don't hang in the rest of get_rsdp_addr(), > it just work as the same way as v5.0 and earlier kernel do. > > Failure cases in kexec_get_rsdp_addr() are followings: > 1. efi_setup_data is invalid > 2. loader signature is invalid > 3. EFI systab is not found in boot_params > 4. RSDP is not found by parsing tables pointed to by efi_setup_data > > I think all of them are critical for EFI boot, so one option could be > we never return failure in kexec_get_rsdp_addr() and just hang. > But hanging in this very early stage of boot may make the problem > harder to investigate once happens. Even earlyprintk is not working yet. > So the other option is returning 0 to defer the crash for later stage. OK, I got the point, thanks. So it is deferred to the late stage, KASLR may not avoid those memory region which is marked as hotpluggable in SRAT. Kernel can boot up, but doesn't function well on hotplug stuff. In this case, people don't know why it happened. We are still blind. Seems early console in efi is the problem, but not kexec or hotplug. I am fine to hang, or make it continue booting for now. Hi Dave, Is it possible to fix the efi early console issue? I mean the feasibility, I believe it won't be easy. Ask this because not only this issue encountered, any other issue could be triggered during boot decompressing stage. If efi has this problem, we can't debug them either. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx1.redhat.com ([209.132.183.28]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hEjz0-0008H9-By for kexec@lists.infradead.org; Fri, 12 Apr 2019 00:23:56 +0000 Date: Fri, 12 Apr 2019 08:23:45 +0800 From: Baoquan He Subject: Re: [PATCH v4] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel Message-ID: <20190412002345.GA6356@MiWiFi-R3L-srv> References: <20190408231011.GA5402@jeru.linux.bs1.fc.nec.co.jp> <20190410171431.GE26580@zn.tnic> <7cbc096d-0548-18b1-a335-8ba114f234a7@ce.jp.nec.com> <20190411080927.GA30080@zn.tnic> <20190411084235.GJ3805@localhost.localdomain> <1bb7bccb-0270-d073-fa2f-43e1a1c73fbe@ce.jp.nec.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1bb7bccb-0270-d073-fa2f-43e1a1c73fbe@ce.jp.nec.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Junichi Nomura , Dave Young Cc: Chao Fan , Kairui Song , "x86@kernel.org" , "kexec@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Borislav Petkov On 04/11/19 at 09:14am, Junichi Nomura wrote: > On 4/11/19 5:42 PM, Baoquan He wrote: > > On 04/11/19 at 08:16am, Junichi Nomura wrote: > >> kexec_get_rsdp_addr() might fail on kexec-booted kernel, e.g. if the > >> setup_data was invalid. In such a case, falling back to efi_get_rsdp_addr() > >> will hit the problem of accessing invalid table pointer again. > > > > Seems you are trying to address Dave Young's comment in > > http://lkml.kernel.org/r/20190404073233.GC5708@dhcp-128-65.nay.redhat.com > > Right. His "In case kexec_get_rsdp_addr failed.." comment. > > > We may need discuss and make clear if those are doable. E.g the first > > comment, if not hang by below line of code, returning 0 for what? Can > > kexec still be saved, or just reset to firmware? > > > > error("EFI system table not found in kexec boot_params.") > > If we return 0 and also don't hang in the rest of get_rsdp_addr(), > it just work as the same way as v5.0 and earlier kernel do. > > Failure cases in kexec_get_rsdp_addr() are followings: > 1. efi_setup_data is invalid > 2. loader signature is invalid > 3. EFI systab is not found in boot_params > 4. RSDP is not found by parsing tables pointed to by efi_setup_data > > I think all of them are critical for EFI boot, so one option could be > we never return failure in kexec_get_rsdp_addr() and just hang. > But hanging in this very early stage of boot may make the problem > harder to investigate once happens. Even earlyprintk is not working yet. > So the other option is returning 0 to defer the crash for later stage. OK, I got the point, thanks. So it is deferred to the late stage, KASLR may not avoid those memory region which is marked as hotpluggable in SRAT. Kernel can boot up, but doesn't function well on hotplug stuff. In this case, people don't know why it happened. We are still blind. Seems early console in efi is the problem, but not kexec or hotplug. I am fine to hang, or make it continue booting for now. Hi Dave, Is it possible to fix the efi early console issue? I mean the feasibility, I believe it won't be easy. Ask this because not only this issue encountered, any other issue could be triggered during boot decompressing stage. If efi has this problem, we can't debug them either. _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec