From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web11.400.1681508389567659108 for ; Fri, 14 Apr 2023 14:39:49 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=kzLMMQOS; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 01CEB642E0 for ; Fri, 14 Apr 2023 21:39:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 59DFCC433D2 for ; Fri, 14 Apr 2023 21:39:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1681508388; bh=T7l5Tn7ZoBWQSAe8wSo09uEMQ8XrueveNrDMxgN62H8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=kzLMMQOS7Edv5k0kySAukwdRnHFae8SfTMH4mh6xP7aRGhcS6c+fwprMFbLdEc6CG xDHHxtHS2RzyCNz4ZCFeYB+c73Y7/OYxZ/HvsPvsN913xIAOTw2/ENRc6LAGl7F98N MH4c/XcYC7pyk+G1JrbtsCt3k4F1H5PM8XTKRZxG4XY0augZNiknej1GVTf2r9X0dN 8hBs12ytqNPkTcKvoD1P7T7yPgvNETOwAw+7XTKRhGvF3b+2Xq3PPwBwzpU+Hmpo7Y s8UsdxqSRwPpJMXSBpxAZAVrR1G4zEMdB0OoijwINBxEEUUL69FTyZj8enxyujmH0e bqDOWnKUGIzcQ== Received: by mail-lj1-f179.google.com with SMTP id l7so6123617ljq.11 for ; Fri, 14 Apr 2023 14:39:48 -0700 (PDT) X-Gm-Message-State: AAQBX9fcTqzkzCidsxIScZsyYX6iawGlteezkXY2h0zdENo5OELt1yKY PH4ElK6+EBz4fdkBQFy6btAc50YviwA02VYbRcQ= X-Google-Smtp-Source: AKy350YSIyzVVdAZFtasvujrVpx2yjEpqUKPnyatii49Vgkox3auruHOR/WQb+6yQumde3Pn34MpsrSWq6izEtFIQog= X-Received: by 2002:a2e:9916:0:b0:2a5:f850:c356 with SMTP id v22-20020a2e9916000000b002a5f850c356mr2448831lji.2.1681508386216; Fri, 14 Apr 2023 14:39:46 -0700 (PDT) MIME-Version: 1.0 References: <7f0f5f8e-09c7-4ae4-ffca-1a7c322949a8@amd.com> In-Reply-To: <7f0f5f8e-09c7-4ae4-ffca-1a7c322949a8@amd.com> From: "Ard Biesheuvel" Date: Fri, 14 Apr 2023 23:39:35 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Strange behavior between GCC 11 and GCC 12 To: Tom Lendacky Cc: "devel@edk2.groups.io" , Gerd Hoffmann Content-Type: text/plain; charset="UTF-8" On Fri, 14 Apr 2023 at 22:23, Tom Lendacky wrote: > > I've been trying to debug a problem I'm seeing when I moved to the GCC 12 > compiler. Under SEV it results in the guest crashing. > > I narrowed the issue down to the call to TemporaryRamMigration() in > PeiCheckAndSwitchStack() of MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c. > > I get this output on GCC11: > Old Stack size 32768, New stack size 131072 > Stack Hob: BaseAddress=0x3BF76000 Length=0x20000 > Heap Offset = 0x3B786000 Stack Offset = 0x3B776000 > *** DEBUG: PeiCheckAndSwitchStack:851 - SecCoreData=3BF95D20 > TemporaryRamMigration(0x810000, 0x3BF8E000, 0x10000) > *** DEBUG: PeiCheckAndSwitchStack:871 - SecCoreData=3BF95D20 > > and everything is good. > > However, I get this output on GCC12: > Old Stack size 32768, New stack size 131072 > Stack Hob: BaseAddress=0x3BF76000 Length=0x20000 > Heap Offset = 0x3B786000 Stack Offset = 0x3B776000 > *** DEBUG: PeiCheckAndSwitchStack:851 - SecCoreData=3BF95D20 > TemporaryRamMigration(0x810000, 0x3BF8E000, 0x10000) > *** DEBUG: PeiCheckAndSwitchStack:871 - SecCoreData=7770BD20 > MMIO using encrypted memory: 7770BD48 > !!!! X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - 00000000 !!!! > > and terminate because SecCoreData has been corrupted and points to an > address in an MMIO range (this is an SEV-ES/SEV-SNP example). > > As near as I can tell from looking at the object code, on GCC12 it looks > like the SecCoreData value is stored in the RBP register, which appears to > be getting corrupted when calling TemporaryRamMigration(). > > Does anyone have any thoughts on this? > The stack switching logic in OvmfPkg/Sec/SecMain.c looks highly dubious to me. LongJump() can be used to do a long return, i.e., it allows to return from several levels deep in the call stack to back up to where SetJump() was called. However, using LongJump() to return to the caller with a different stack is, quite frankly, insane, and I'm surprised it didn't break a lot sooner. In this particular case, RBX gets updated along with RSP, presumably because the code assumes it is being used as a frame pointer? Are you building with -fomit-frame-pointer perhaps?