Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4895495pxj; Wed, 9 Jun 2021 04:41:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyy6+aNmPHYLMVX5reotB/M3DjsCTskiU6PUCWH8di1mkCgFGMnGno1SEXX5VoLyOCddkk3 X-Received: by 2002:a17:906:b213:: with SMTP id p19mr20527948ejz.51.1623238912517; Wed, 09 Jun 2021 04:41:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623238912; cv=none; d=google.com; s=arc-20160816; b=AZ8uz+GTsT1SwcWpXCHgkV8ZoF9s/cX9m2Av2sC6S7cIf2Vacu5hjrp1rtsXycW/5+ vYLFueelsM6qlMQOQKZjhCL/iqr/9SCgyfp22DUlKjEGgX8cQS1y7MBeQyCu3GpaVwOl r6a3L/yPKxunnQ2QIWsEUZ5E8GfR6A3tGJ3E40DWgSW2LccgeXfHp/LLAAdDOfPWY1Ow 0Zk+a3DvKbOF/XkmI6I46fg0n+UmREAxCXPkkNrzAw4zqYcjoAjIJuA+p94RXgS4QlKj GmssClDDwoOlvgAZoQlSZG1ab4X1924V5UlI2d3FdtGZOp8jOs2AwCm3fJccVCDSb2XN QJeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=pYTEA7ZFfdn94rXPwQz8ZqU+46Urht6x/74neWtZvZY=; b=VCM1QByZV/WDFQurD3iDylTlFw/AL/BbKOGjMjVWV8rc9srobVlfajZq44PqHlSbnd uo0VKiVihUtVTuryY0CGMEsWFba/FmCuU72uzkUZgtOwOxq3cz/GsWrezYOAazQ2d7D6 t6neEmDdRFtII6+4TkUcsUJidyLAZ9t+1RlZdUiKFsjzwN2flllfvKDJQf2segL6zwAv 4QRN2B0wP+JAeHtK2A8zEp35cy6JPYTZ/4Psm3KVDh8jstd9U8FMNXfSLNdtEbQs9WfH hbV/IQNIRQZISGGSae3ZaH4bFyubsFwnmW5GGeO0TFFvMEUBuTtxmCyyNJBULbPiXVi/ DlBA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=WFNATtg8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d12si2496010ejj.278.2021.06.09.04.41.15; Wed, 09 Jun 2021 04:41:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=WFNATtg8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234953AbhFHUcq (ORCPT + 99 others); Tue, 8 Jun 2021 16:32:46 -0400 Received: from mail.skyhub.de ([5.9.137.197]:37956 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234000AbhFHUcp (ORCPT ); Tue, 8 Jun 2021 16:32:45 -0400 Received: from zn.tnic (p200300ec2f16b100e640acc4c45ae2c4.dip0.t-ipconnect.de [IPv6:2003:ec:2f16:b100:e640:acc4:c45a:e2c4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 412561EC03F0; Tue, 8 Jun 2021 22:30:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1623184251; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=pYTEA7ZFfdn94rXPwQz8ZqU+46Urht6x/74neWtZvZY=; b=WFNATtg8GZelRPM5pYMEpGNg66evBRzZeyfwjanYoBaIgAMoZMsL6pjaeou8Ge9S3kDH7Q 1jCxB9gEX1mZ4u3rHms6QV7ziDTvEZxAOlBDyannKYU8cmJCkFkALKhFtc10nsRrs9ZyFe aDZ4ciXCSbFzknJqNl0kGocOmuNS2bo= Date: Tue, 8 Jun 2021 22:30:46 +0200 From: Borislav Petkov To: Linus Torvalds Cc: Michael Kelley , James Morris , Sasha Levin , Mike Rapoport , x86-ml , lkml , James Morris Subject: [PATCH] x86/setup: Document that Windows reserves the first MiB Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org It does so unconditionally too, on Intel and AMD machines, to work around BIOS bugs, as confirmed by Microsoft folks (see Link for full details). Reflow the paragraph, while at it. Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/MWHPR21MB159330952629D36EEDE706B3D7379@MWHPR21MB1593.namprd21.prod.outlook.com --- arch/x86/kernel/setup.c | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 7638ac6c3d80..85acd22f8022 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -1060,17 +1060,18 @@ void __init setup_arch(char **cmdline_p) #endif /* - * Find free memory for the real mode trampoline and place it - * there. - * If there is not enough free memory under 1M, on EFI-enabled - * systems there will be additional attempt to reclaim the memory - * for the real mode trampoline at efi_free_boot_services(). + * Find free memory for the real mode trampoline and place it there. If + * there is not enough free memory under 1M, on EFI-enabled systems + * there will be additional attempt to reclaim the memory for the real + * mode trampoline at efi_free_boot_services(). * - * Unconditionally reserve the entire first 1M of RAM because - * BIOSes are know to corrupt low memory and several - * hundred kilobytes are not worth complex detection what memory gets - * clobbered. Moreover, on machines with SandyBridge graphics or in - * setups that use crashkernel the entire 1M is reserved anyway. + * Unconditionally reserve the entire first 1M of RAM because BIOSes + * are known to corrupt low memory and several hundred kilobytes are not + * worth complex detection what memory gets clobbered. Windows does the + * same thing for very similar reasons. + * + * Moreover, on machines with SandyBridge graphics or in setups that use + * crashkernel the entire 1M is reserved anyway. */ reserve_real_mode(); -- 2.29.2 -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette