From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) by mx.groups.io with SMTP id smtpd.web09.245.1627683918464787878 for ; Fri, 30 Jul 2021 15:25:18 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@taylorbeebe.com header.s=google header.b=QMqoEm6q; spf=pass (domain: taylorbeebe.com, ip: 209.85.214.172, mailfrom: t@taylorbeebe.com) Received: by mail-pl1-f172.google.com with SMTP id a20so12827939plm.0 for ; Fri, 30 Jul 2021 15:25:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=taylorbeebe.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=fmPkQKdLLNSzVS2wrngEscVlgmOfGPlc4+L3ZluwSy4=; b=QMqoEm6qS3ZA6Nc9cKMP36Ofk/hV0fhV4zvtjInmgjoe8bC17vKFnKxlGXCXdyId2M ji7R5k7o4ZORzxtWKGojwmO6sMHOi/QbFLkefRwFCukbLIEuFBdUTq/RkjERsUea86tm 86QsXQDmlu5gswkiu2uqWhas+AunjAuvtHb9UJJHJdtN7/uIHYX0WdT2WT3S7XggI3Uo WxXXm1rszc7csOs3sXqvOfG3mdVyyzcRCCrDqzyV9aRcMAqBRXir3zgPpdUebIuAGgEC y9k5c0ad4DTxp8E+7AB4JW0zn9wlNWzYBYpGoZcg7v6yWHY7OPe6BKhC/sL+F1TAuK7D WR1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fmPkQKdLLNSzVS2wrngEscVlgmOfGPlc4+L3ZluwSy4=; b=t9ixWZetACHMnWyid1n6RLgz5ax1keTPopn2ivoUjgDvPRQnIf/TKj3YJl1dPDolZV DY+1uD50R8LuIe1je4uTWxLukkgD1TDBbrJcuTzK6yBmACSeSl5Ch5dkoKWa+aqxmc7c lxyvlDB9sKAXhiPdHZAlEnS52tdAGXE9bLNnVVu7EE0MoxdYbBQeITJeakvrLjRpJ2SZ D1G/9mrHKU+YE7ej8cyge9SzuIpPGw36BIgjwoIajTdaQiidkdachzMlJL5KrXuzkEqf H9uZ04/WiQuGoLznzTSkrH8KLewJlvAr8D4yG3DoBJW+1mQOZP2NkmQsdDNtphF9npxC yUiw== X-Gm-Message-State: AOAM530Qq5YWMT+wzTGfxT7Dbcd/qA3h4yGLljuNPyNQpMyJCvwqz72b zAydoERRomGUrCP75Ky44I0aDA== X-Google-Smtp-Source: ABdhPJwqXPeDmZnqNYGHd7/uZea/XBrk32pdrU3eCx42NmG5/7TVJawZWnaUR5nRdACmbe513Wltow== X-Received: by 2002:a17:90a:a390:: with SMTP id x16mr5312900pjp.136.1627683918011; Fri, 30 Jul 2021 15:25:18 -0700 (PDT) Return-Path: Received: from [192.168.0.159] ([50.35.69.176]) by smtp.gmail.com with ESMTPSA id v23sm3351921pje.33.2021.07.30.15.25.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Jul 2021 15:25:17 -0700 (PDT) Subject: Re: [edk2-devel] [RFC] MemoryProtectionLib for Dynamic Memory Guard Settings To: Sean Brogan , devel@edk2.groups.io, jiewen.yao@intel.com, "Wang, Jian J" Cc: "Dong, Eric" , "Ni, Ray" , "Kumar, Rahul1" , "mikuback@linux.microsoft.com" , "Wu, Hao A" , "Bi, Dandan" , "gaoliming@byosoft.com.cn" , "Dong, Guo" , "Ma, Maurice" , "You, Benjamin" References: <5ffb8dce-8a33-537c-2019-ec4666854739@taylorbeebe.com> From: "Taylor Beebe" Message-ID: <6ab0641e-e6ff-60c9-4ab7-974148edcfbd@taylorbeebe.com> Date: Fri, 30 Jul 2021 15:25:17 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit I am going to extend the opportunity for feedback to the end of Tuesday. I would very much like more community input on this proposal. On 7/30/2021 11:42 AM, Sean Brogan wrote: > Jiewen, > > **Slight rant** > > I agree with libraries as an effective abstraction method.  But I think > there needs to be a broad discussion about the order of preference for > methods of abstraction.  Today the edk2 code base is a mix and often > there are numerous methods abstracting the same thing which leads to > confusion, misconfiguration, and error. > > In the UEFI specification we have PPIs/Protocols/Events for functional > abstraction.  We have variables, guided config tables, and HII for data > abstraction. > > In the PI specification we add HOBs and PCDs for data abstractions. > > Finally, in EDKII we add the library class concept and leverage it > heavily for arch, phase, and platform/behavioral abstractions. > > Without clear guidance for how and when to use the above it is hard to > keep code being developed by the larger community consistent. > > **End** > > I was leaning towards something closer to > > >> Option 1: > https://github.com/TaylorBeebe/edk2/tree/memory_protection_lib_2 > > the HOB method and internally as we develop more code we are preferring > HOB and data abstractions more than functional abstraction.  Data > abstractions can be used to control functional differences as well if > needed.  Data abstractions allow for easier validation and support > diverse code environments.  For example standalone MM and > payloadpkg/payload concepts.  Finally, data abstractions break the need > for a monolithic code base.   But as you can see in option 1 it actually > uses a library class abstraction as well because no one wants to write > the same code over and over again to get the HOB.  The contract of the > library is just data but it still requires library mappings.  Maybe > these types of libraries need to be treated differently. > > Anyway it would be great to hear from other members of the community > around not just the memory protections RFC (this RFC) but around > preferences for abstraction techniques (pro/con).  If an actual > discussion starts it could move to design meeting. > > Thanks > Sean > > > > > > > > On 7/29/2021 7:34 PM, Yao, Jiewen wrote: >> Thanks. Code talks better. >> >> I prefer option 2, which is a generic way for abstraction. >> >> And you may enable option 1 under the cover of option 2, just create a >> lib instance to get config from Hob. >> >> Thank you >> Yao Jiewen >> >>> -----Original Message----- >>> From: Taylor Beebe >>> Sent: Friday, July 30, 2021 10:07 AM >>> To: Yao, Jiewen ; Wang, Jian J >>> ; >>> devel@edk2.groups.io >>> Cc: spbrogan@outlook.com; Dong, Eric ; Ni, Ray >>> ; Kumar, Rahul1 ; >>> mikuback@linux.microsoft.com; Wu, Hao A ; Bi, Dandan >>> ; gaoliming@byosoft.com.cn; Dong, Guo >>> ; Ma, Maurice ; You, Benjamin >>> >>> Subject: Re: [RFC] MemoryProtectionLib for Dynamic Memory Guard Settings >>> >>> Of course - here are a couple of rough drafts: >>> >>> Option 1: >>> https://github.com/TaylorBeebe/edk2/tree/memory_protection_lib_2 >>> Option 2: https://github.com/TaylorBeebe/edk2/tree/memory_protection_lib >>> >>> On 7/29/2021 6:57 PM, Yao, Jiewen wrote: >>>> Hi >>>> Sorry, I am not able to follow the discussion. >>>> >>>> Is there any sample or POC code to show the concept? >>>> >>>>> -----Original Message----- >>>>> From: Taylor Beebe >>>>> Sent: Friday, July 30, 2021 9:55 AM >>>>> To: Wang, Jian J ; devel@edk2.groups.io >>>>> Cc: spbrogan@outlook.com; Dong, Eric ; Ni, Ray >>>>> ; Kumar, Rahul1 ; >>>>> mikuback@linux.microsoft.com; Wu, Hao A ; Bi, >>> Dandan >>>>> ; gaoliming@byosoft.com.cn; Dong, Guo >>>>> ; Ma, Maurice ; You, >>> Benjamin >>>>> ; Yao, Jiewen >>>>> Subject: Re: [RFC] MemoryProtectionLib for Dynamic Memory Guard >>>>> Settings >>>>> >>>>> Thanks for your feedback, Jian. >>>>> >>>>> In option 2, a most basic implementation would returning the current >>>>> FixedAtBuild PCDs assuming they are kept. If they aren't, the library >>>>> implementer could simply hard-code the return value for each memory >>>>> protection setting. >>>>> >>>>> In option 1, the HOB would be published in pre-mem and I'm not an >>>>> expert >>>>> on exploiting the pre-mem environment. Jiewen may have more to say on >>> this. >>>>> >>>>> -Taylor >>>>> >>>>> On 7/28/2021 7:18 PM, Wang, Jian J wrote: >>>>>> Thanks for the RFC. I'm not object to this idea. The only concern >>>>>> from me >>>>>> is the potential security holes introduced by the changes. >>>>>> According to your >>>>>> description, it allows 3rd party software to violate memory >>>>>> protection >>> policy. >>>>>> I'd like to see more explanations on how to avoid it to be exploited. >>>>>> >>>>>> +Jiewen, what's current process to evaluate the security threat? >>>>>> >>>>>> Regards, >>>>>> Jian >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Taylor Beebe >>>>>>> Sent: Friday, July 23, 2021 8:33 AM >>>>>>> To: devel@edk2.groups.io >>>>>>> Cc: spbrogan@outlook.com; Dong, Eric ; Ni, Ray >>>>>>> ; Kumar, Rahul1 ; >>>>>>> mikuback@linux.microsoft.com; Wang, Jian J ; >>> Wu, >>>>>>> Hao A ; Bi, Dandan ; >>>>>>> gaoliming@byosoft.com.cn; Dong, Guo ; Ma, >>>>> Maurice >>>>>>> ; You, Benjamin >>>>>>> Subject: [RFC] MemoryProtectionLib for Dynamic Memory Guard Settings >>>>>>> >>>>>>> Current memory protection settings rely on FixedAtBuild PCD values >>>>>>> (minus PcdSetNxForStack). Because of this, the memory protection >>>>>>> configuration interface is fixed in nature. Cases arise in which >>>>>>> memory >>>>>>> protections might need to be adjusted between boots (if platform >>>>>>> design >>>>>>> allows) to avoid disabling a system. For example, platforms might >>>>>>> choose >>>>>>> to allow the user to control their protection policies such as allow >>>>>>> execution of critical 3rd party software that might violate memory >>>>>>> protections. >>>>>>> >>>>>>> This RFC seeks your feedback regarding introducing an interface that >>>>>>> allows dynamic configuration of memory protection settings. >>>>>>> >>>>>>> I would like to propose two options: >>>>>>> 1. Describing the memory protection setting configuration in a >>>>>>> HOB that >>>>>>> is produced by the platform. >>>>>>> 2. Introducing a library class (e.g. MemoryProtectionLib) that >>>>>>> allows >>>>>>> abstraction of the memory protection setting configuration data >>>>>>> source. >>>>>>> >>>>>>> In addition, I would like to know if the memory protection >>>>>>> FixedAtBuild >>>>>>> PCDs currently in MdeModulePkg can be removed so we can move the >>>>>>> configuration interface entirely to an option above. >>>>>>> >>>>>>> In any case, I would like the settings to be visible to environments >>>>>>> such as Standalone MM where dynamic PCDs are not accessible. >>>>>>> >>>>>>> I am seeking your feedback on this proposal in preparation for >>>>>>> sending >>>>>>> an edk2 patch series. >>>>>>> >>>>>>> -- >>>>>>> Taylor Beebe >>>>>>> Software Engineer @ Microsoft >>>>> >>>>> -- >>>>> Taylor Beebe >>>>> Software Engineer @ Microsoft >>> >>> -- >>> Taylor Beebe >>> Software Engineer @ Microsoft >> >> >> >> >> -- Taylor Beebe Software Engineer @ Microsoft