From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oa1-f47.google.com (mail-oa1-f47.google.com [209.85.160.47]) by mx.groups.io with SMTP id smtpd.web11.3384.1686099445342930467 for ; Tue, 06 Jun 2023 17:57:25 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="signature has expired" header.i=@gmail.com header.s=20221208 header.b=co027o9q; spf=pass (domain: gmail.com, ip: 209.85.160.47, mailfrom: kuqin12@gmail.com) Received: by mail-oa1-f47.google.com with SMTP id 586e51a60fabf-19f6f8c840bso6163492fac.3 for ; Tue, 06 Jun 2023 17:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686099444; x=1688691444; h=content-transfer-encoding:subject:content-language:from:to :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=1X/TiPZd/pWUJN3tgSFMh4qWkmlaU1n3o5fj4x+2UAI=; b=co027o9qa9loS9p1xtEStnZDd0dpTICyqohJEM7sf62VaoWhCQJ94hbkS43y0eaL3m carkvSuC4TaqWiOYWFEgLHI+kV6W8+dG00RrikvWyFERKnLMXoWaH4TPqghRWz9Icxk2 eiQO4+WvWgcym0K+Z5Ib7YaYRG7q/IRkC2lBOKEU0F7C4T085oUjPfiDtJ1aA6QCrjoM BcOKpe/jg+h1XglD7UGU1VHZMx2iKfYvIjLDFp+NUc66gs+q7N8XdFSOSAv9vxD1dEP/ 9AOWDqyWSq2h2ADlD3UStji3VuOPMqgx6k9ORF1NpJLevBBKh4vDP/PtWG6zIhNW8vTN H15g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686099444; x=1688691444; h=content-transfer-encoding:subject:content-language:from:to :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=1X/TiPZd/pWUJN3tgSFMh4qWkmlaU1n3o5fj4x+2UAI=; b=YOlKryV0fvMzKYGzK7OYKO3rwLLXg18QK7Vk+QhZQWWzgAhT0amYAwScpzy7dKDgG2 eUhm80oaZE6R+EYmHdvhzN6heq5wLFJy5QOmJH0ll+ZbvYtLx1/xKHTjBDRXig7Fbkp7 fWE7jYf8/2cy4z/igJKvGAl1lrgPATqPtx/d23E7kZXdix9o+8sBaoOeTGivpdpsl/HQ 3y5Jsmo4FHmxj6y7yUFgTWE7VC8mVn5JWGVIlUCCDbrfm0XHiPoP2DQpT/ncP0lNycKx QeP+Tm8o2diXHDSaGbnbwqIytcpn4J9Fp/LsZhP719L//CxeWaT3QQ3jwG/gbwZRuCJY 4Gug== X-Gm-Message-State: AC+VfDyuXJc964O65bUrsGpUqzXghsLVUoeT5Ioz1nsdM3hThE1ipxNK bERqmzBsLmOO+YkERh4PEDZLbjTnAI4= X-Google-Smtp-Source: ACHHUZ4V2PVVZAFl/r/ON+Q+kCjKm1b3gIpZ0qJay+vB6LHhj58GKtdmNLb9/OW400NMFdyouWyX5w== X-Received: by 2002:a05:6870:955c:b0:1a3:199a:ae4f with SMTP id v28-20020a056870955c00b001a3199aae4fmr3053907oal.47.1686099444208; Tue, 06 Jun 2023 17:57:24 -0700 (PDT) Return-Path: Received: from ?IPV6:2001:4898:d8:33:e490:d74e:193b:f53c? ([2001:4898:80e8:b:64a8:d74e:193b:f53c]) by smtp.gmail.com with ESMTPSA id jk11-20020a170903330b00b001ac7c725c1asm9142825plb.6.2023.06.06.17.57.23 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jun 2023 17:57:23 -0700 (PDT) Message-ID: Date: Tue, 6 Jun 2023 17:57:23 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 To: devel@edk2.groups.io From: "Kun Qin" Subject: Using Depex for Standalone MM drivers on ARM Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi all, We found an issue a while back on ARM systems, where the Standalone MM drivers with Depex specified will run into a hang when TFA hands off to Standalone MM core. (https://bugzilla.tianocore.org/show_bug.cgi?id=3883) After some debugging, the logic in the ticket still seems to be true until today: 1. The UEFI Standalone MM partition needs to setup Standalone MM core to be branched off that the beginning of this FV by manipulating the build rules. Example: https://github.com/tianocore/edk2-platforms/blob/93a71a67fd80bbc5baf0708ba75e73696b4a1c67/Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf#LL88C1-L89C1 2. During build time, the MM partition was initialized to code pages through `ARM_SP_IMAGE_MMAP` as part of `plat_arm_mmap` see here: https://github.com/ARM-software/arm-trusted-firmware/blob/a0f3b552cfa45258099170c83f79619b2dbd7b9b/include/plat/arm/common/arm_spm_def.h#LL36C11-L36C11, which was later used for initial setup. 3. During BL31 setup step, the EL1 jump point will be updated to `sp_image_base` from `plat_get_secure_partition_boot_info`: https://github.com/ARM-software/arm-trusted-firmware/blob/a0f3b552cfa45258099170c83f79619b2dbd7b9b/services/std_svc/spm/spm_mm/spm_mm_setup.c#LL45C29-L45C42 which was initialized to `ARM_SP_IMAGE_BASE`. 4. After demoting to Secure EL1, the FD will first branch off to standalone core entrypoint: https://github.com/tianocore/edk2/blob/ded0b489af09cde5afa05d74acdb12cd4b4f8394/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/Arm/StandaloneMmCoreEntryPoint.c#L319. Standalone core entrypoint will execute in place of FV for the first few lines. Then the core will locate itself in reported buffer SpImageBase (which is also the FV image buffer location) and update the page attribute accordingly (https://github.com/tianocore/edk2/blob/ded0b489af09cde5afa05d74acdb12cd4b4f8394/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/Arm/StandaloneMmCoreEntryPoint.c#LL386C12-L386C48). 5. The FV image buffer location (SpImageBase from UEFI, sp_image_base from tf-a) is then published as an FV hob for further dispatches (https://github.com/tianocore/edk2/blob/ded0b489af09cde5afa05d74acdb12cd4b4f8394/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/Arm/CreateHobList.c#LL84C1-L84C75), which was then used for Depex tracking/evaluation during driver discovery and dispatching process in https://github.com/tianocore/edk2/blob/ded0b489af09cde5afa05d74acdb12cd4b4f8394/StandaloneMmPkg/Core/StandaloneMmCore.c#L646. 6. Depex discovered from FV during this process is cached in the DriverEntry structure as pointers and added to the mDiscoveredList in https://github.com/tianocore/edk2/blob/ded0b489af09cde5afa05d74acdb12cd4b4f8394/StandaloneMmPkg/Core/Dispatcher.c#L864 7. Later during Standalone MM dispatching, this Depex pointer will be updated in place: https://github.com/tianocore/edk2/blob/ded0b489af09cde5afa05d74acdb12cd4b4f8394/StandaloneMmPkg/Core/Dependency.c#LL256C14-L256C14, which causes memory violation as we are writing to the code pages. Could you please let me know if there is anything I missed on this path? To resolve this issue, I think any one of the following changes could be considered: 1. Updating the incoming FV region to be Data pages, in TF-A; 2. Copying this incoming region to a separate data buffer; 3. Allocating designated copy pools for Depex sections during dispatching (and free them once done). We could work around this by compressing the FV, but I think we should still fix the issue, correct? Any thoughts or suggestions on this would be appreciated. Regards, Kun