From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f45.google.com (mail-pj1-f45.google.com [209.85.216.45]) by mx.groups.io with SMTP id smtpd.web08.18893.1627610820724946185 for ; Thu, 29 Jul 2021 19:07:00 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@taylorbeebe.com header.s=google header.b=b8XruzOo; spf=pass (domain: taylorbeebe.com, ip: 209.85.216.45, mailfrom: t@taylorbeebe.com) Received: by mail-pj1-f45.google.com with SMTP id u9-20020a17090a1f09b029017554809f35so18472925pja.5 for ; Thu, 29 Jul 2021 19:07:00 -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=7vUvWCXZwGHh5Ki/4kbX2l+zseNqbIyVAB9HYmeycXg=; b=b8XruzOorAM0DMttVdLasFXdHZgNkhIdXyWiq1AFJ0NuNBh2Cquh1E3HpS1Wkf0K/4 gYZSNuvRCUHW9NxPcKzMKgbyM0r0afCzqo0jhhZhLk7Fi5rsQKjcNwUfnCVZsRS9nVhL n9sA2/s60D7uKCX5g3P+bkq7cJvAUhGPhZ7gd8AxMknOJQL9heGJ0UOc664y1Yt89vhX vE3D0mLSWGIfXOfN5xARhLFBEQ9ByrRaDHagQ1SQDmV1wmud7FNfd33c+PTOxl0rYk9m Rxkk8R384Vz5DoRqQOGewvFtQ8gqiLGbPWOiWPJZQXwQ7XyBN98KQj3XmfDDrndCgy36 BADA== 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=7vUvWCXZwGHh5Ki/4kbX2l+zseNqbIyVAB9HYmeycXg=; b=GSyg1JWgP00MFfDDjDIFTz8/oOTmfoJI5zMSJ59Z7rLEpwK7Mne6WmlSEYCqVT4f5t GVyPZ4DAh8Ba55w4bgDLsvIsWEKaq2GhHChfpuPMpcN/PgnXp4MHggRCjRoGrHiHqvwK z7dF6ED8Kev0tM8SKfWFw5ecPs3A+elH3tOl9iekNBaYdnBTAubNF27nN53fwQQVqcaz kgxMJEDOyA5JjTTbD0X//uc6HowAREaVj6N/eA7uiOMzg4lQASNbfbVzXoZ5peuJIYDu dkRBWgC+5ccuj/lylhqrCBvsXjxyHadfdjE9ieDiCNm6TAbOe0ufjJMJH2NQinMvtXuC gBKg== X-Gm-Message-State: AOAM5311O8Ike9A36c5fZEhBGI7NkRig+Jx1/M+RuuGfCh6/qASKUbmQ +CkYXR7jN5FXWmYpVd89tvI79Q== X-Google-Smtp-Source: ABdhPJzeAHrMI2lIxK7ciOe4T4U222px/MvetBRmiausMxHhDI1XEgaDJbk0RlgV5S/eU/0idv+4Dw== X-Received: by 2002:a17:90a:c092:: with SMTP id o18mr505540pjs.3.1627610820332; Thu, 29 Jul 2021 19:07:00 -0700 (PDT) Return-Path: Received: from [192.168.0.159] ([50.35.69.176]) by smtp.gmail.com with ESMTPSA id c12sm185005pjm.16.2021.07.29.19.06.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jul 2021 19:07:00 -0700 (PDT) Subject: Re: [RFC] MemoryProtectionLib for Dynamic Memory Guard Settings 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" References: <5ffb8dce-8a33-537c-2019-ec4666854739@taylorbeebe.com> From: "Taylor Beebe" Message-ID: Date: Thu, 29 Jul 2021 19:06:58 -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: 7bit 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