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=-6.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 66AA1C47088 for ; Wed, 26 May 2021 16:30:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 47254613E6 for ; Wed, 26 May 2021 16:30:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234684AbhEZQby (ORCPT ); Wed, 26 May 2021 12:31:54 -0400 Received: from mail.kernel.org ([198.145.29.99]:39122 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234544AbhEZQbs (ORCPT ); Wed, 26 May 2021 12:31:48 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 6D8D8613CE; Wed, 26 May 2021 16:30:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1622046616; bh=K2m+rOb2f5WbHdz8pamr+WIQ2N26pRLHMfuwQxJHfRc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=jhC4cjoVWCu6lSiiL7n4CJy8Ikr7zv8QwzE4SuU9kh/vXEJNpGroSZ+/An5/5Q4Xu j/7s5x/MeU2UllKWl30Ze5nDPJR61nSny+59D5CA4DN3RVOGUN7t4X2/d6hQAWPNfW m+ZIbdk14b+IRidC/kV+eEkG6wXYGcJAioi8/i2EVibXtBy+oitp6xc1eZDIHGsfQb +VSRYHpgX9BYreoUIxRTlB+RbTRCLPwSnw9sFY6ZKXPXs5EKh03Q/uUKRwTWdiOvey dslvDCRl08RxnTkYx1u4Sv1kMDFQZgy7dArO0+77lYOCEsbG0d17t2ErWzLqZ4CnMu STGbT5UzBOX1A== Date: Wed, 26 May 2021 19:30:09 +0300 From: Mike Rapoport To: Borislav Petkov Cc: Ingo Molnar , "H. Peter Anvin" , Thomas Gleixner , Mike Rapoport , untaintableangel@hotmail.co.uk, x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86/Kconfig: decrease maximum of X86_RESERVE_LOW to 512K Message-ID: References: <20210526081100.12239-1-rppt@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 26, 2021 at 10:47:21AM +0200, Borislav Petkov wrote: > On Wed, May 26, 2021 at 11:11:00AM +0300, Mike Rapoport wrote: > > From: Mike Rapoport > > > > After the consolidation of early memory reservations introduced by the > > commit a799c2bd29d1 ("x86/setup: Consolidate early memory reservations") > > the kernel fails to boot if X86_RESERVE_LOW is set to 640K. > > > > The boot fails because real-time trampoline must be allocated under 1M (or > > essentially under 640K) but with X86_RESERVE_LOW set to 640K the memory is > > already reserved by the time reserve_real_mode() is called. > > > > Before the reordering of the early memory reservations it was possible to > > allocate from low memory even despite user's request to avoid using that > > memory. This lack of consistency could potentially lead to memory > > corruptions by BIOS in the areas allocated by kernel. > > Hmm, so this sounds weird to me: real-time trampoline clearly has > precedence over X86_RESERVE_LOW because you need former to boot the > machine, right? > > In that case, real-time trampoline should allocate first and *then* the > rest of low range requested to be reserved should be reserved, no? We can restore that behaviour, but it feels like cheating to me. We let user say "Hey, don't touch low memory at all", even though we know we must use at least some of it. And then we sneak in an allocation under 640K despite user's request not to use it. -- Sincerely yours, Mike.