From nobody Thu Dec 26 11:51:10 2024 Delivered-To: importer@patchew.org Received-SPF: none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) client-ip=198.145.21.10; envelope-from=edk2-devel-bounces@lists.01.org; helo=ml01.01.org; Authentication-Results: mx.zohomail.com; dkim=fail; spf=none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) smtp.mailfrom=edk2-devel-bounces@lists.01.org Return-Path: Received: from ml01.01.org (ml01.01.org [198.145.21.10]) by mx.zohomail.com with SMTPS id 150462327537442.18097687131956; Tue, 5 Sep 2017 07:54:35 -0700 (PDT) Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 571A621EB88F3; Tue, 5 Sep 2017 07:51:44 -0700 (PDT) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id F230021E3EA6F for ; Tue, 5 Sep 2017 07:51:42 -0700 (PDT) Received: by mail-pg0-x241.google.com with SMTP id d8so2094662pgt.3 for ; Tue, 05 Sep 2017 07:54:32 -0700 (PDT) Received: from localhost.localdomain ([139.227.181.161]) by smtp.gmail.com with ESMTPSA id s184sm1457405pfb.123.2017.09.05.07.54.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Sep 2017 07:54:31 -0700 (PDT) X-Original-To: edk2-devel@lists.01.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=Z7MqCpK15lsy8UOqDix03peVvHSakfKOVEloYziB+Yc=; b=jCltSD76eAuvpNVfrP/vGCpxXjvbjCuiuyxqzLSsLKuTJmmRWFiiL4/rS0nffn2dUU 8j6+AMUj2Tg42SRp7Eszc6l4r396ps/r5CkNoAChrFqyn8zC1QgRHHSEO2ipwFPPBwU+ kOowNEviknj2iWnMWGqgivtMQTrFEcpbG7GZ4710B2IKfKd+WfMbek6WrkCWE9cSkR+Z IBrRp3VXlvyeiNypKAYVVeVgaeudcr05Vru8fNUczscXK38L32oSzxyAi1pqN36faDzo 9d7pj0rkm9Gajd8BXBLEO3KWSLxUOtalAGrnjT0SkJfekailiywrqoijYmiVGt8GTdAF NlKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Z7MqCpK15lsy8UOqDix03peVvHSakfKOVEloYziB+Yc=; b=DeXtCYDItNS6I5hsITEnOeQhpWh02/jYOqrrkBZQ81yBsXz/rmB9lLmmyNOWtF8qTo vvJl1gc0+x6+VAGoQ4quY2Omoa/NCVNox73UBEvz7eqfybWwYKO6NP78LAW1wxweszcq ObD3Qtl0q1nhzD8MmE6eoI7T35NMFQFtAx8wOqENB7rmgfz/DQ66Or1eQa360qglLgc6 OQelR473EI5kTiEIYrcnMJrRG5QQ4mV1aekrICF6J3O/bE7O9C/WT8dMV+iygdZeQujc OY63AVq7MWfUsxeDhFaGiZaRCflKYgMVlEbh2T9AG+FkD2sxqXM9AYFjR4PBeQHy0/Le S1/g== X-Gm-Message-State: AHPjjUhEEirlSiduVKLIOxA8vyLNqOTrz4EdKS4Xwy0x5/d5o0EMiAzA 18XpuAAUFFVGRd8kwSo= X-Google-Smtp-Source: ADKCNb5kMHPcjIBY99yNmLjIHtGCB32aJcZpnChfK/MsImGdo1I7oRGwtqsOReMomvkHKz/SXbTPFQ== X-Received: by 10.84.238.138 with SMTP id v10mr4666855plk.37.1504623271655; Tue, 05 Sep 2017 07:54:31 -0700 (PDT) From: Ge Song To: edk2-devel@lists.01.org Date: Tue, 5 Sep 2017 22:54:19 +0800 Message-Id: <20170905145419.3095-2-songgebird@gmail.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20170905145419.3095-1-songgebird@gmail.com> References: <20170905145419.3095-1-songgebird@gmail.com> MIME-Version: 1.0 Subject: [edk2] [PATCH v2 1/1] OvmfPkg/SecMain: Fix stack switching to permanent memory X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Ge Song , Ard Biesheuvel , Laszlo Ersek , Jordan Justen Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Errors-To: edk2-devel-bounces@lists.01.org Sender: "edk2-devel" X-ZohoMail-DKIM: fail (Header signature does not verify) X-ZohoMail: RDKM_2 RSF_4 Z_629925259 SPT_0 In earlier PEI stage, temporary memory at PcdOvmfSecPeiTempRamBase is employed as stack and heap. We move them to the new room and do some relocation fixup when permanent memory becomes available. TemporaryRamMigration() is responsible for switching the stack. Before entering TemporaryRamMigration(), Ebp/Rbp is populated with the content of Esp/Rsp and used as frame pointer. After the execution of SetJump/LongJump, stack migrates to new position while the context keeps unchanged. But when TemporaryRamMigration() exits, Esp/Rsp is filled with the content of Ebp/Rbp to destroy this stack frame. The result is, stack switches back to previous temporary memory. When permanent memory becomes available, modules that have registered themselves for shadowing will be scheduled to execute. Some of them need to consume more memory(heap/stack). Contrast to temporary stack, permanent stack possesses larger space. The potential risk is overflowing the stack if stack staying in temporary memory. When it happens, system may crash during S3 resume. More detailed information: > (gdb) disassemble /r > Dump of assembler code for function TemporaryRamMigration: > 0x00000000fffcd29c <+0>: 55 push %rbp > 0x00000000fffcd29d <+1>: 48 89 e5 mov %rsp,%rbp > 0x00000000fffcd2a0 <+4>: 48 81 ec 70 01 00 00 sub > $0x170,%rsp > ... > ... > 0x00000000fffcd425 <+393>: e8 80 10 00 00 callq 0xfffce4aa > > =3D> 0x00000000fffcd42a <+398>: b8 00 00 00 00 mov $0x0,%eax > 0x00000000fffcd42f <+403>: c9 leaveq > 0x00000000fffcd430 <+404>: c3 retq > End of assembler dump. See the description of leave(opcode: c9), from Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 2A "Releases the stack frame set up by an earlier ENTER instruction. The LEAVE instruction copies the frame pointer (in the EBP register) into the stack pointer register (ESP), which releases the stack space allocated to the stack frame. The old frame pointer (the frame pointer for the calling procedure that was saved by the ENTER instruction) is then popped from the stack into the EBP register, restoring the calling procedure=E2=80=99s stack frame." To solve this, update Ebp/Rbp too when Esp/Rsp is updated Cc: Jordan Justen Cc: Laszlo Ersek Cc: Ard Biesheuvel Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ge Song Tested-by: Laszlo Ersek Reviewed-by: Laszlo Ersek --- OvmfPkg/Sec/SecMain.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/OvmfPkg/Sec/SecMain.c b/OvmfPkg/Sec/SecMain.c index e1993ec347b5..f7fec3d8c03b 100644 --- a/OvmfPkg/Sec/SecMain.c +++ b/OvmfPkg/Sec/SecMain.c @@ -931,9 +931,11 @@ TemporaryRamMigration ( if (SetJump (&JumpBuffer) =3D=3D 0) { #if defined (MDE_CPU_IA32) JumpBuffer.Esp =3D JumpBuffer.Esp + DebugAgentContext.StackMigrateOffs= et; + JumpBuffer.Ebp =3D JumpBuffer.Ebp + DebugAgentContext.StackMigrateOffs= et; #endif =20 #if defined (MDE_CPU_X64) JumpBuffer.Rsp =3D JumpBuffer.Rsp + DebugAgentContext.StackMigrateOffs= et; + JumpBuffer.Rbp =3D JumpBuffer.Rbp + DebugAgentContext.StackMigrateOffs= et; #endif =20 LongJump (&JumpBuffer, (UINTN)-1); } --=20 2.11.0 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel