From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 1E4BA21E97814 for ; Tue, 5 Sep 2017 20:08:52 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id g13so2166425pfm.2 for ; Tue, 05 Sep 2017 20:11:41 -0700 (PDT) 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=DihAdsH0P3YcBJfYaGLo5H5GrWnkTCWekgnPNDV3g6I=; b=GyQhGpUueDdCzqz0T2w1dBvRvQkT7YUd4ZM8ScryTx6r3a9NkYe43I8oSvN1Kf3r94 LdJedGXaDnU5OQSW3kco2Ncsc4iDWjHb5RJWkPxY3A0dDhcSBpFLBYnG1sGAAoKW12Eo b/k/asK3BmHJY11vt9ADoky2uwKWO3zhyUylnlRXXuBZEweCCHU9pswszVHuC0GxT+WR 6klg4KQrg3KCLS14vopv11B2dhEh5xtaPzyHyJZOOF4RnsGxCaaNcSFs1ecBlCHahUe1 YLXJPt7ysUEYo9uqVQCdyd63Hf7RBpZCgN/iSoVA1A+Tk67GMubYGZaTjnSeAkStiuaA ctRQ== 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=DihAdsH0P3YcBJfYaGLo5H5GrWnkTCWekgnPNDV3g6I=; b=H7m17H7PKMeQX744EvzYU+svBIpMOEIcIvGcMiXvzQKXXnPK7Cs1vAQKw1KYiiXvtn EbFqRA1MjDcIjtNooGyO/P8QcxyLrgPrvPsyvqK7YsfGwXtEZ5XYvNX8nKy/V2DdyJ5w Dllsbm3vYyLOanGtZxCjtV9UnSIGUiPdOHWPj1/qaBjYOpNJ2ckbuTSXfwksQXleZ6cA oiuqcgDZ7D6rq6Z5HPo9YMqSeBu0aN86RGMGj3k7Rf8PvPyvs7GfW++KBRFM1UC9z032 LpV6BIQ6IdBkuWoea+FKmZD76lSb80cN9TD74Ck8Xe0UrBZybH+ju2ofvA4goNUQxht8 gAyQ== X-Gm-Message-State: AHPjjUgerD5Q8AVGLWQPmYSQR/5ibbTW9h4y/nmEwoN8F1div2tj+fBq LLQmcBVLBA3D+mdOd/k= X-Google-Smtp-Source: ADKCNb4o3Tg1h4xDUQQ6c9guIfHx//FtAdyQEibk7jkCxgQYdEnGENCG945W9Q8AIvWqYvrSSEkWXg== X-Received: by 10.98.71.198 with SMTP id p67mr5805328pfi.15.1504667501320; Tue, 05 Sep 2017 20:11:41 -0700 (PDT) Received: from localhost.localdomain ([180.173.249.63]) by smtp.gmail.com with ESMTPSA id l66sm459228pfl.156.2017.09.05.20.11.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Sep 2017 20:11:40 -0700 (PDT) From: songgebird@gmail.com X-Google-Original-From: ge.song@hxt-semitech.com To: edk2-devel@lists.01.org Cc: Jordan Justen , Laszlo Ersek , Ard Biesheuvel , Ge Song Date: Wed, 6 Sep 2017 11:11:35 +0800 Message-Id: <20170906031135.10358-2-ge.song@hxt-semitech.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20170906031135.10358-1-ge.song@hxt-semitech.com> References: <20170906031135.10358-1-ge.song@hxt-semitech.com> MIME-Version: 1.0 Subject: [PATCH v3 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: , X-List-Received-Date: Wed, 06 Sep 2017 03:08:52 -0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Ge Song 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 > > => 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’s 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) == 0) { #if defined (MDE_CPU_IA32) JumpBuffer.Esp = JumpBuffer.Esp + DebugAgentContext.StackMigrateOffset; + JumpBuffer.Ebp = JumpBuffer.Ebp + DebugAgentContext.StackMigrateOffset; #endif #if defined (MDE_CPU_X64) JumpBuffer.Rsp = JumpBuffer.Rsp + DebugAgentContext.StackMigrateOffset; + JumpBuffer.Rbp = JumpBuffer.Rbp + DebugAgentContext.StackMigrateOffset; #endif LongJump (&JumpBuffer, (UINTN)-1); } -- 2.11.0