From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (NAM11-DM6-obe.outbound.protection.outlook.com [40.92.19.76]) by mx.groups.io with SMTP id smtpd.web10.1843.1627670548394473897 for ; Fri, 30 Jul 2021 11:42:28 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@outlook.com header.s=selector1 header.b=Vc0NiO2L; spf=pass (domain: outlook.com, ip: 40.92.19.76, mailfrom: spbrogan@outlook.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mnMpZHZzLqHM2mtNIonHKINOy9bRfVtlMaiPTiW6QnTIw2ZOK0ALr49mEUqAAX18bDh0HZzxFkFKOMkN3656ZbmjHCLViaVroCo7FgRoJ73MnOvBaNHPgTK+syMKkAhoewHJLFJ0xbi6/bLhlHbSRQzlAa27+1AuPLr/qFnlCiVQm9Ji6qaijq0LSd3a83rNhvdMLP4Bpiul7aaSEdk0vfwbmLJfD6sfQNAQCTaW4EK9qc3G6QW0bOc+BF0XsZdcKtMSZAJsdZwqb2WX1WM4ka1FpSDGHCQPtkQEtUvHvx/7tExK+BEEC0otn5oc9zArLlQx/TzUT3XVwMIKbtdBtQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iTwsg1SPeBw3Nd0b4ctlWrtCfv2Y45ZmKa3WCOt4TIs=; b=JCeyQV4GM5bDjX4xUNY+SE8cOFCnM9W2oKZymtTjj2C74S6s5BE1g12AgEVxw18rLhPSG+GCMa6gT2YpUmSgh1SwsGEKej+mu6/9BBHcB/uv9JtBeiU+PplJ/C1pF6VI5piKvGehRHIA046OPxrgXM1+aT+wpdqIHw5LyHTUAtTsdXc/EU1q3HWYddTw9Z3rvcGVwHusl0no7ZsLiavIucb0DTlT7cTxmQ+BDWA3UwXADaRbZHtabTd7BYWiX/MNUzck56jgBNbUUQy9CUO1HKvlYIjlqv8T9FQr68p9Pj4tWdo+RGF8hGUynEsyF9tDGDLQTPFH10fUFBAM/KWxmQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iTwsg1SPeBw3Nd0b4ctlWrtCfv2Y45ZmKa3WCOt4TIs=; b=Vc0NiO2LUbZBXgxjODU5mjHZXXQCutqU22mUN00+j11THZD6i1EXbKErse6Pr1TM+/A/dGZsveD7+4oebjgV7Xr5UQH52xClp2xSvMNVVl/RCH2yXQAn4RmQHzll2Oplgdocjt/teo58T/AmLruYadAWppQ07W5NY6uF0ZIkP4Ca3nCAJUoj0/at5eT+zzoh84vr4WI5h1iLPizt6XzjsI8eG/jK4vCZs35Y7q2t6nQrOki3bnwWBA8zWCSNjT+xSDyL0DXc66E7mbTyhNAd17Xv1y+0Xj3tuWgslOLdqdcoLAlwY03Wy+SXJQWTCp5mMWDTQuCu26p9/YzbuHiWkQ== Received: from CO1NAM11FT005.eop-nam11.prod.protection.outlook.com (2a01:111:e400:3861::48) by CO1NAM11HT232.eop-nam11.prod.protection.outlook.com (2a01:111:e400:3861::389) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.18; Fri, 30 Jul 2021 18:42:26 +0000 Received: from BY3PR19MB4900.namprd19.prod.outlook.com (2a01:111:e400:3861::53) by CO1NAM11FT005.mail.protection.outlook.com (2a01:111:e400:3861::147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.18 via Frontend Transport; Fri, 30 Jul 2021 18:42:26 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:D79F32C057C5A5E73F7E8ABF43DD98E6BC6661B3D2CA93BBE6B07A103A844230;UpperCasedChecksum:E56EA4838442E20958C5F338A02C096D43009396E3A4C7AE0B478EEADA36644A;SizeAsReceived:9573;Count:48 Received: from BY3PR19MB4900.namprd19.prod.outlook.com ([fe80::ace7:1da0:cc6e:c52]) by BY3PR19MB4900.namprd19.prod.outlook.com ([fe80::ace7:1da0:cc6e:c52%6]) with mapi id 15.20.4373.025; Fri, 30 Jul 2021 18:42:26 +0000 Subject: Re: [edk2-devel] [RFC] MemoryProtectionLib for Dynamic Memory Guard Settings To: devel@edk2.groups.io, jiewen.yao@intel.com, Taylor Beebe , "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: "Sean" Message-ID: Date: Fri, 30 Jul 2021 11:42:23 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 In-Reply-To: X-TMN: [fhB8Eefg/v9xKj/ouVRFDgGxsCzBHJac] X-ClientProxiedBy: MWHPR22CA0026.namprd22.prod.outlook.com (2603:10b6:300:69::12) To BY3PR19MB4900.namprd19.prod.outlook.com (2603:10b6:a03:354::11) Return-Path: spbrogan@outlook.com X-Microsoft-Original-Message-ID: MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.2.78] (50.47.113.221) by MWHPR22CA0026.namprd22.prod.outlook.com (2603:10b6:300:69::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.18 via Frontend Transport; Fri, 30 Jul 2021 18:42:25 +0000 X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 48 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: 796d5066-2cfd-492a-8ada-08d95389c6a1 X-MS-TrafficTypeDiagnostic: CO1NAM11HT232: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: EgpqkknJfwmcEMVqS/0GQCJe0/V6dAc+tRMlf1GbUl+0lLJX1rl20yWBIyNQeM7weX4Fys7ruWS+d98AGJegTEtH/iVMUXC2m1ijFU0dA+gCLktL/2UDQNB+T9lx3cEs8FOo9vLPHuPkbDEAcCNo9NcWxn686L2qKYVXlnA39g+pJrSfJboYJ0eKnl6dQitfMXI39FpA9ODLWgFmMRUwoMvbv/Ka1ld6O2JTxZs6t+hP8dJiBoDquo1GwYTnXpYcTLd8HgsFYJxIlvsmfJJ+uiPZeQxB8HsNVPJa8tcB9pXv0Z1/jbd8lhCxprkWH0ZM/t/FpwSyuObNJvgdc6bnVVQ8D1UEpVPT6+PDs6c2MU/IoCGInW4B1vHuvxjCRecgHnQWhdxoUDb/Bb8qK5sfN1TwxgHufGjzQ03GmpFULfAwE/fd9mYZc8FVBUmnYcyLxdMN3wWm2LMtr5WbkqEuHYrks0gWfPi6qtTbBgk0FbY= X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: f/ChZE12gEPoJI3ikwpL+K3uZxdWRdTDg467+ntO8/Dn+AunOfAGkZy1drEdFVFbu43ltqGRFPap7ST0XsYhYBbNJ6ZpLol2ftV3Q+clvUfN0fV6OEMSRhZeNcAluGwve8QEqkJ9CcyCHW5FIhD9FA== X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 796d5066-2cfd-492a-8ada-08d95389c6a1 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jul 2021 18:42:26.5621 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-AuthSource: CO1NAM11FT005.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM11HT232 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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 > > > > >