Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp1706798ybh; Tue, 14 Jul 2020 05:21:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyqNdX9GSsBQvRTKZQijQcUflImPCJY8Chh+XTOJ7gDm8Q01c9I0Ei+nlx0Ec5co1S4AgkV X-Received: by 2002:a05:6402:143c:: with SMTP id c28mr4432063edx.54.1594729277171; Tue, 14 Jul 2020 05:21:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594729277; cv=none; d=google.com; s=arc-20160816; b=UeFnGsTZXOPWN3ZWI0GMUydUcprh8vFisyGf8g+EzswMI8GkylCpSbyZAumQljyZ7K v805dga8sf6IsWX8Ntkuy0nWNZKAr+3Zrh1dz7xbYJgOlveEoFgSRSaedKSTiC9FS/Su d+ixFoWAzyeSkvNQIHzYtckS25D5IspCH37yBjQjxGuX2eiw9VPrao5x+yxhGmH9INJH sYHVF3jIea4R4BdNnWV39ZcHs77V5RZ7KTM49697UFxntCGC1gq6gwTPzmHjiaNlJHYs DvanpKOiF0QIg/NdnDomcftaCCWUBPiXXFPeldGypaseVExNFytinx6DyF7l1HCzPDOr 4WIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=1awmjFVoba9HdCuoxR8Aj9Opb3GHQkhjFnifoFFZFYg=; b=n/GC0EcYSXaK2gFg38+7JwDlPrvmbh2EnWEvsAmh7M+29kjWWMAdgeuNmv9Z2ZRUrl XDzkKa2/HuaOo7oVQ18DjT05yWsGkNDQKp0V8teNl6hJz1w+5oTfCecOaPyKF79f0o7Z mfitpBQVDXF5/VQHYV0CHkkXZ7/W5/H1sKAMwhbnjWFeCJtNJ2xIZxUqPth0OknVxCtj UimuEMbN8tMT8b46sfYPuKNr6DaeLFZcZbjFe7BJ45Y7NNgWaUy+2k7Q/YmgFM9tY22C KnevOqlJYcwaijtGGB8xjZJTk+RynCNDBVhXcFrMLGGx9yG3NWBHGD9G/m2yQmaP8HKR Sx7A== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h5si10864314eji.26.2020.07.14.05.20.52; Tue, 14 Jul 2020 05:21:17 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728350AbgGNMRk (ORCPT + 99 others); Tue, 14 Jul 2020 08:17:40 -0400 Received: from 8bytes.org ([81.169.241.247]:52918 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726630AbgGNMKk (ORCPT ); Tue, 14 Jul 2020 08:10:40 -0400 Received: from cap.home.8bytes.org (p5b006776.dip0.t-ipconnect.de [91.0.103.118]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by theia.8bytes.org (Postfix) with ESMTPSA id DEC3E5D1; Tue, 14 Jul 2020 14:10:38 +0200 (CEST) From: Joerg Roedel To: x86@kernel.org Cc: Joerg Roedel , Joerg Roedel , hpa@zytor.com, Andy Lutomirski , Dave Hansen , Peter Zijlstra , Jiri Slaby , Dan Williams , Tom Lendacky , Juergen Gross , Kees Cook , David Rientjes , Cfir Cohen , Erdem Aktas , Masami Hiramatsu , Mike Stunes , Sean Christopherson , Martin Radev , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org Subject: [PATCH v4 11/75] x86/boot/compressed/64: Disable red-zone usage Date: Tue, 14 Jul 2020 14:08:13 +0200 Message-Id: <20200714120917.11253-12-joro@8bytes.org> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20200714120917.11253-1-joro@8bytes.org> References: <20200714120917.11253-1-joro@8bytes.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Joerg Roedel The x86-64 ABI defines a red-zone on the stack: The 128-byte area beyond the location pointed to by %rsp is considered to be reserved and shall not be modified by signal or interrupt handlers. Therefore, functions may use this area for temporary data that is not needed across function calls. In particular, leaf functions may use this area for their entire stack frame, rather than adjusting the stack pointer in the prologue and epilogue. This area is known as the red zone. This is not compatible with exception handling, because the IRET frame written by the hardware at the stack pointer and the functions to handle the exception will overwrite the temporary variables of the interrupted function, causing undefined behavior. So disable red-zones for the pre-decompression boot code. Signed-off-by: Joerg Roedel --- arch/x86/boot/Makefile | 2 +- arch/x86/boot/compressed/Makefile | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile index fe605205b4ce..4d6a16a47e9f 100644 --- a/arch/x86/boot/Makefile +++ b/arch/x86/boot/Makefile @@ -66,7 +66,7 @@ targets += cpustr.h # --------------------------------------------------------------------------- -KBUILD_CFLAGS := $(REALMODE_CFLAGS) -D_SETUP +KBUILD_CFLAGS := $(REALMODE_CFLAGS) -D_SETUP -mno-red-zone KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__ KBUILD_CFLAGS += $(call cc-option,-fmacro-prefix-map=$(srctree)/=) KBUILD_CFLAGS += -fno-asynchronous-unwind-tables diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile index 7619742f91c9..95ac85b8ef27 100644 --- a/arch/x86/boot/compressed/Makefile +++ b/arch/x86/boot/compressed/Makefile @@ -32,7 +32,7 @@ KBUILD_CFLAGS := -m$(BITS) -O2 KBUILD_CFLAGS += -fno-strict-aliasing $(call cc-option, -fPIE, -fPIC) KBUILD_CFLAGS += -DDISABLE_BRANCH_PROFILING cflags-$(CONFIG_X86_32) := -march=i386 -cflags-$(CONFIG_X86_64) := -mcmodel=small +cflags-$(CONFIG_X86_64) := -mcmodel=small -mno-red-zone KBUILD_CFLAGS += $(cflags-y) KBUILD_CFLAGS += -mno-mmx -mno-sse KBUILD_CFLAGS += $(call cc-option,-ffreestanding) -- 2.27.0