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=-7.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no 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 DE8BFC636C8 for ; Tue, 20 Jul 2021 15:04:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D0A26610FB for ; Tue, 20 Jul 2021 15:04:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238771AbhGTOXI (ORCPT ); Tue, 20 Jul 2021 10:23:08 -0400 Received: from mail.kernel.org ([198.145.29.99]:51554 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239979AbhGTN7l (ORCPT ); Tue, 20 Jul 2021 09:59:41 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 8F17F6101E for ; Tue, 20 Jul 2021 14:40:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1626792019; bh=0svNeulWDtZSBXCy3gTGL2vqJj/8SC0F4typBUqFsB4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Pg9YgCgq+8qt+xK9x0mMcFXGGHSOwxpqnREjWlSyqZzAS5XizO9Mywo4RnxdYrYRm RTMhaFni1FM03EnhcRy9vf7217Y0a87UFo1P4abjtBRMRJy8keKqmtkNP6LDjgbRoZ lVj2d+v+Z6ikK7Clo6jgWmx0UE+GZc8+jrCvIAYSrAQJdsxUO2FbXkPpMZEfo4XG6d xj3nWW5KKQEAL+MVooc0c09EsvgN7DnHQB/e8Y5TOQjCxHPon5D6GyL9nnlgEStCwk LDvbKrANBCTRswctmlKQBMcygs3030JdLyYRyEmaxEAXwgRZQ3WfvqLb2XpyJ6DsuH hBpE3WOP2UEjQ== Received: by mail-ot1-f54.google.com with SMTP id t4-20020a05683014c4b02904cd671b911bso13656697otq.1 for ; Tue, 20 Jul 2021 07:40:19 -0700 (PDT) X-Gm-Message-State: AOAM531zvbXsYYUasTFHkLlviSPrrN3bBtCwqiEGmaqbUqMtGH7SjCSU f2mkkJ5R5RnFNNBDxMjpC0Mt3lhrdhc6p2WDDUw= X-Google-Smtp-Source: ABdhPJwaP8Jcg14bUt4VtZt9Ld2ugI0PHQnqHbE+hmvo3VnYpGI/HsVgbNr67zPTTnjm6UhTIsPzLdz20jv9B6fLm7E= X-Received: by 2002:a05:6830:34a6:: with SMTP id c38mr9697856otu.108.1626792018921; Tue, 20 Jul 2021 07:40:18 -0700 (PDT) MIME-Version: 1.0 References: <161920fc31ec4168290ca31b3e4ac7a75ac1df6b.camel@kernel.crashing.org> <0e1280c9ca789e15a46b65f6796a8c333a9da18a.camel@kernel.crashing.org> <2e4fb9458e32d2727099a5116c59a6c54e280aad.camel@kernel.crashing.org> In-Reply-To: From: Ard Biesheuvel Date: Tue, 20 Jul 2021 16:40:07 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 2/2] arm64: efi: kaslr: Fix boot failure if efi_random_alloc() fails To: Benjamin Herrenschmidt Cc: Linux ARM , linux-efi , "linux-kernel@vger.kernel.org Will Deacon" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org On Tue, 20 Jul 2021 at 16:25, Benjamin Herrenschmidt wrote: > > On Tue, 2021-07-20 at 16:10 +0200, Ard Biesheuvel wrote: > > > > > My patch simply ensures that this is also true when KASLR fails to > > > randomize the kernel address. > > > > > > > Fair enough. > > > > The history here is that passing nokaslr on the command line would > > force 2M alignment even if KASLR was not enabled to begin with, > > without affecting the alignment policy of KASLR capable kernels if > > KASLR was not explicitly disabled, but not available on the platform. > > > > I realize now that my commit d32de9130f6c7 has interfered with this: > > efi_nokaslr is set to true there so the later code does not complain > > about the EFI_RNG_PROTOCOL being unavailable, but it has the side > > effect of affecting the alignment policy in the remainder of the > > function. > > > > So what I would prefer here is to capture efi_nokaslr at entry, and > > use that to decide the alignment. That way, efi_nokaslr can be set to > > true without affecting the subsequent allocation logic. > > So interestingly, the bug I am trying to fix with this patch seems to > indicate that this doesn't work (though I would need to debug further > as to why) on my systems (EC2 c6g.metal instances). > > IE, in my case what happens is: > > - kernel has CONFIG_RANDOMIZE_BASE and CONFIG_RELOCATABLE both enabled > - RNG protocol exists, it gets a random seed, but due to the other > bug, efi_random_alloc() fails. It thus falls back to the "normal" > alignment check & relocation case (the big if (status != EFI_SUCCESS)) > - That alignment check uses 64K and not 2M however. In my case it > passes (_text is already 64K aligned) and we boot... > - And nothing happens. IE, it dies somewhere in/after exit boot > services, I haven't had a chance to figure out in more details why, > those machines take 20mn to reboot. > > So *something* is wrong when we stick to a 64K alignment and don't > randomize the kernel base. > Interesting. Could this be related to caching? If EFI loads Image and it remains in place, we boot the image that we are executing from, and if your ExitBootServices() implementation plays tricks with [non-architected] caches, this could cause problems, I suppose. Just guessing ... > Interestingly we don't set nokaslr in that case, so we should still be > hitting all the kaslr path in the main kernel. The problem could relate > to running from that initial address. I'll have to debug further, maybe > try a repro-case in qemu. > > In the meantime, please apply patch 1 which solves the main issue and > I'll continue digging. > OK > Note (in case this is relevant): This was all tested/debugged on 5.10.y > > Cheers, > Ben. > > 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=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 6A9CFC07E9B for ; Tue, 20 Jul 2021 14:41:37 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3D58B610CC for ; Tue, 20 Jul 2021 14:41:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3D58B610CC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=xGBCocXIUCun2SnU1zT+m4WWTP1HcMIv1eamwW/g/HE=; b=Mng6ans0QJHk/G 2084tB3EFqSHJ9UpiKrBu4QVfmswfm7NJPnRMUN0OXknbr4qLDmhGM/VrmQdloZViIL9R+ggQFIQW 1rDOXexi+AoHyZ/76LPHOt9eS7MIsi/JlCPZ7zd6xKzhtGUsrIUX9Y4ZGy2SDiUJUDBtqs/yYDyAg fJboFEIgpNqkrCBo6syn22ypBBxYPktEIPWJf8a3rAS+qUK+XaXUdDnqm8HmIEOTYxESqlw1gMknI +9Vwb74jr023QXwT0ARthSLAKc7xi7LuRFF2gaEcgKysNksTFoO0We2lhuOr9DhIfxgY9FBnfV/mT ghtg0APkYr8nDMbRl4Dw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m5qv1-00DEFg-TZ; Tue, 20 Jul 2021 14:40:24 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1m5qux-00DEEq-Rf for linux-arm-kernel@lists.infradead.org; Tue, 20 Jul 2021 14:40:21 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 8ADC5610A0 for ; Tue, 20 Jul 2021 14:40:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1626792019; bh=0svNeulWDtZSBXCy3gTGL2vqJj/8SC0F4typBUqFsB4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Pg9YgCgq+8qt+xK9x0mMcFXGGHSOwxpqnREjWlSyqZzAS5XizO9Mywo4RnxdYrYRm RTMhaFni1FM03EnhcRy9vf7217Y0a87UFo1P4abjtBRMRJy8keKqmtkNP6LDjgbRoZ lVj2d+v+Z6ikK7Clo6jgWmx0UE+GZc8+jrCvIAYSrAQJdsxUO2FbXkPpMZEfo4XG6d xj3nWW5KKQEAL+MVooc0c09EsvgN7DnHQB/e8Y5TOQjCxHPon5D6GyL9nnlgEStCwk LDvbKrANBCTRswctmlKQBMcygs3030JdLyYRyEmaxEAXwgRZQ3WfvqLb2XpyJ6DsuH hBpE3WOP2UEjQ== Received: by mail-ot1-f53.google.com with SMTP id 59-20020a9d0ac10000b0290462f0ab0800so21712356otq.11 for ; Tue, 20 Jul 2021 07:40:19 -0700 (PDT) X-Gm-Message-State: AOAM531o+sjJ7ha8yRjLqJLTa95kqF9gGlyF9cOb/DEfHWAM7V5g3LIh /hKWdGeHj/LhPDwaupy6zKGeXS4jZu2sZRu3OJw= X-Google-Smtp-Source: ABdhPJwaP8Jcg14bUt4VtZt9Ld2ugI0PHQnqHbE+hmvo3VnYpGI/HsVgbNr67zPTTnjm6UhTIsPzLdz20jv9B6fLm7E= X-Received: by 2002:a05:6830:34a6:: with SMTP id c38mr9697856otu.108.1626792018921; Tue, 20 Jul 2021 07:40:18 -0700 (PDT) MIME-Version: 1.0 References: <161920fc31ec4168290ca31b3e4ac7a75ac1df6b.camel@kernel.crashing.org> <0e1280c9ca789e15a46b65f6796a8c333a9da18a.camel@kernel.crashing.org> <2e4fb9458e32d2727099a5116c59a6c54e280aad.camel@kernel.crashing.org> In-Reply-To: From: Ard Biesheuvel Date: Tue, 20 Jul 2021 16:40:07 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 2/2] arm64: efi: kaslr: Fix boot failure if efi_random_alloc() fails To: Benjamin Herrenschmidt Cc: Linux ARM , linux-efi , "linux-kernel@vger.kernel.org Will Deacon" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210720_074019_978225_563688D2 X-CRM114-Status: GOOD ( 32.21 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, 20 Jul 2021 at 16:25, Benjamin Herrenschmidt wrote: > > On Tue, 2021-07-20 at 16:10 +0200, Ard Biesheuvel wrote: > > > > > My patch simply ensures that this is also true when KASLR fails to > > > randomize the kernel address. > > > > > > > Fair enough. > > > > The history here is that passing nokaslr on the command line would > > force 2M alignment even if KASLR was not enabled to begin with, > > without affecting the alignment policy of KASLR capable kernels if > > KASLR was not explicitly disabled, but not available on the platform. > > > > I realize now that my commit d32de9130f6c7 has interfered with this: > > efi_nokaslr is set to true there so the later code does not complain > > about the EFI_RNG_PROTOCOL being unavailable, but it has the side > > effect of affecting the alignment policy in the remainder of the > > function. > > > > So what I would prefer here is to capture efi_nokaslr at entry, and > > use that to decide the alignment. That way, efi_nokaslr can be set to > > true without affecting the subsequent allocation logic. > > So interestingly, the bug I am trying to fix with this patch seems to > indicate that this doesn't work (though I would need to debug further > as to why) on my systems (EC2 c6g.metal instances). > > IE, in my case what happens is: > > - kernel has CONFIG_RANDOMIZE_BASE and CONFIG_RELOCATABLE both enabled > - RNG protocol exists, it gets a random seed, but due to the other > bug, efi_random_alloc() fails. It thus falls back to the "normal" > alignment check & relocation case (the big if (status != EFI_SUCCESS)) > - That alignment check uses 64K and not 2M however. In my case it > passes (_text is already 64K aligned) and we boot... > - And nothing happens. IE, it dies somewhere in/after exit boot > services, I haven't had a chance to figure out in more details why, > those machines take 20mn to reboot. > > So *something* is wrong when we stick to a 64K alignment and don't > randomize the kernel base. > Interesting. Could this be related to caching? If EFI loads Image and it remains in place, we boot the image that we are executing from, and if your ExitBootServices() implementation plays tricks with [non-architected] caches, this could cause problems, I suppose. Just guessing ... > Interestingly we don't set nokaslr in that case, so we should still be > hitting all the kaslr path in the main kernel. The problem could relate > to running from that initial address. I'll have to debug further, maybe > try a repro-case in qemu. > > In the meantime, please apply patch 1 which solves the main issue and > I'll continue digging. > OK > Note (in case this is relevant): This was all tested/debugged on 5.10.y > > Cheers, > Ben. > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel