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.web09.5411.1662539245807856002 for ; Wed, 07 Sep 2022 01:27:26 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=e/YXzX37; 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 37B8B617CE for ; Wed, 7 Sep 2022 08:27:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9E888C43470 for ; Wed, 7 Sep 2022 08:27:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1662539244; bh=oY4t6mWuofuZL6xluZr44RqNUesTND4YEyP4IuRXZ00=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=e/YXzX37O4XtaETshPHpnGkgZEk0o4s6YYaZfBUj9jJavQCT3c950yOMAAKCN7G+i 5foNjBRtyi7jawucF88JOLzUQiSo7XPx10xN356jSBbP2kFIezB5LVqUY3Jczhdo9Z Ty7bNE8N5kCW/h9f49bsiMzZJ3as47Rjj4RIqpR7uxzv579dEc8Wktd4nZdlgSETLV uyg/TDaj3jn4en90h+N+y3wypONwvYZM5kWahX+OV7enqJd9a05Pdzs9FxCt1yF4hu 1SDTTgir9xet1PghAlVPouw+u6yFLWuJctIL9A/3K4P4grMa9Uj+xedVYSwdugLAMT kB6cz33I+cDmw== Received: by mail-lf1-f48.google.com with SMTP id m15so1589925lfl.9 for ; Wed, 07 Sep 2022 01:27:24 -0700 (PDT) X-Gm-Message-State: ACgBeo39OUlc720e3TSdzb8ZcSEcy1srfxABbTHbYDNIXlMwpHI1JiqQ miqOTqxbl2BwbnWMfk62B7KA4GdlH2NFUvH6Ip0= X-Google-Smtp-Source: AA6agR5Ssq4Qe+/50IXNwW53f5GN6hxN/6EQ6xVycLo6Kd5uKgm8+tl5CJ2Z3Zoj/A5+vzybVSHAr46lYT2iFsDRa38= X-Received: by 2002:a05:6512:150e:b0:492:d9fd:9bdf with SMTP id bq14-20020a056512150e00b00492d9fd9bdfmr703243lfb.583.1662539242626; Wed, 07 Sep 2022 01:27:22 -0700 (PDT) MIME-Version: 1.0 References: <16BC2C06E438B403.26361@groups.io> <6fcb7f10-c113-1c9d-2b4d-264b81ed6ad1@gmail.com> In-Reply-To: From: "Ard Biesheuvel" Date: Wed, 7 Sep 2022 10:27:11 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH v1 0/2] MM communicate functionality in variable policy To: Kun Qin Cc: edk2-devel-groups-io , Jian J Wang , Liming Gao , Hao A Wu , Leif Lindholm , Ard Biesheuvel , Bret Barkelew , Michael Kubacki Content-Type: text/plain; charset="UTF-8" On Mon, 13 Dec 2021 at 19:23, Kun Qin wrote: > > Hi ArmPkg and MdeModulePkg maintainers, > > Now that the hard freeze is lifted, could you please provide some > feedback on these patches when you have a chance? > My apologies for not responding to these changes. If these patches are still relevant, please rebase and resend them. > On 12/06/2021 10:41, Ard Biesheuvel wrote: > > On Mon, 6 Dec 2021 at 19:35, Kun Qin wrote: > >> > >> Hi ArmPkg and MdeModulePkg maintainers, > >> > >> It has been a week since the patches were sent. Could you please review > >> the changes and let me know if there is any feedback? Any input is > >> appreciated. > >> > > > > As far as I know, we are still in hard freeze for the upcoming stable tag. > > > >> > >> On 11/29/2021 16:39, Kun Qin via groups.io wrote: > >>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3709 > >>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3751 > >>> > >>> Currently, setups with variable policy operations used together with MM > >>> communicate from ArmPkg could fail with `EFI_INVALID_PARAMETER`. This was > >>> due to the errors from 2 following aspects: > >>> > >>> 1. For variable policy implementations in MdeModulePkg, the DXE runtime > >>> agent would communicate to MM to disable, register or query policies. > >>> However, during these operations, the MessageLength calculation is > >>> including MM communicate header. This could lead to MM agent read data > >>> across the given buffer boundary and/or trigger other errors. > >>> > >>> 2. On the other hand, current MM communicate routine from ArmPkg would > >>> fail the function if the input message length does not equal to input > >>> buffer size. > >>> > >>> As defined in PI specification, the `CommSize`, when as input, should > >>> stand for "The size of the data buffer being passed in", which would mean > >>> the maximal number of bytes `CommBuffer` can hold. In turn, the value of > >>> this input parameter can be used for MM handlers to determine whether the > >>> output data is too large to fit in this buffer. Enforcing the incoming > >>> buffer to hold exactly the number of used bytes mismatches with the PI > >>> spec description. > >>> > >>> This change fix MessageLength field calculation from variable policy and > >>> updated input argument inspections from MM communicate routine in ArmPkg > >>> to match PI spec descriptions. > >>> > >>> Patch v1 branch: https://github.com/kuqin12/edk2/tree/mm_communicate_check > >>> > >>> Cc: Jian J Wang > >>> Cc: Liming Gao > >>> Cc: Hao A Wu > >>> Cc: Leif Lindholm > >>> Cc: Ard Biesheuvel > >>> Cc: Bret Barkelew > >>> Cc: Michael Kubacki > >>> > >>> Kun Qin (2): > >>> MdeModulePkg: VariableSmmRuntimeDxe: Fix Variable Policy Message > >>> Length > >>> ArmPkg: MmCommunicationDxe: Update MM communicate input arguments > >>> checks > >>> > >>> ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c | 44 ++++++++++++-------- > >>> MdeModulePkg/Universal/Variable/RuntimeDxe/VariablePolicySmmDxe.c | 10 ++--- > >>> 2 files changed, 32 insertions(+), 22 deletions(-) > >>>