From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mx.groups.io with SMTP id smtpd.web12.9707.1602831870175931117 for ; Fri, 16 Oct 2020 00:04:30 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: arm.com, ip: 217.140.110.172, mailfrom: ard.biesheuvel@arm.com) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0EE75D6E; Fri, 16 Oct 2020 00:04:29 -0700 (PDT) Received: from [192.168.1.81] (unknown [10.37.8.32]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BD1803F66B; Fri, 16 Oct 2020 00:04:26 -0700 (PDT) Subject: Re: [edk2-rfc] [edk2-devel] [RFC] Support Both MM Traditional and Standalone Drivers with One MM Core To: "Fu, Siyuan" , "devel@edk2.groups.io" , "sami.mujawar@arm.com" , "lersek@redhat.com" , "Yao, Jiewen" , "rfc@edk2.groups.io" Cc: "Dong, Eric" , "Ni, Ray" , Supreeth Venkatesh References: <91565e60-54c5-8315-142b-d7b1309fca5a@redhat.com> <35c9e93e-5bd0-c932-c27c-183a687926c7@redhat.com> From: "Ard Biesheuvel" Message-ID: <06550454-2f65-8137-de07-b8ac048bed26@arm.com> Date: Fri, 16 Oct 2020 09:04:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit On 10/16/20 3:36 AM, Fu, Siyuan wrote: > Hi, Sami > > I know the traditional MM is planned to be deprecated but the reality is that there > are many existing traditional MM platforms/drivers and the migration has to happen > step-by-step. It may take a long time like several years, not days or months. Not sure > if we really want to maintain duplicate code in 3 different MM cores in EDK2 for > such a long time. > Could you explain more about the gap that needs to be bridged here? I suppose the desire is to be able to reuse existing DXE_SMM_DRIVER modules, and deploy them unmodified in a standalone MM context? So would you expect runtime dispatch for these drivers? What about any accesses to EFI boot services, which are no longer possible when running under standalone MM? Do you have any reason to believe that this hybrid MM core will be able to run a significant fraction of those existing drivers? > Would you think it's acceptable if we put the traditional MM related code controlled > by a feature flag PCD in StandaloneMmPkg core? The default value of the PCD can > be set as disabled so those existing platforms doesn't need to be changed. > This is security critical code, and having PCD controlled behavior like this makes it much hard to reason about correctness in all its instantiation. I guess I would have to see what the code looks like, but having PCD checks all over the place does not seem like a great way to do this IMHO. -- Ard.