[RFC PATCH v2 1/3] x86/sgx: Add SGX specific LSM hooks

[Xing, Cedric]

> From: Andy Lutomirski [mailto:luto at kernel.org]
> Sent: Monday, July 01, 2019 12:36 PM
> 
> On Mon, Jul 1, 2019 at 11:31 AM Xing, Cedric <cedric.xing at intel.com>
> wrote:
> > I intended to say the major reason I objected Sean's approach was its
> inability to support SGX2 smoothly - as #PF driven EAUG requires non-
> existent pages to be mmap()'ed, otherwise vm_ops->fault wouldn't be
> dispatched so EAUG couldn't be issued in response to #PF.
> 
> I still think that, if the kernel wants to support #PF-driven EAUG, it
> should be an opt-in thing.  It would be something like
> SGX_IOC_ADD_LAZY_EAUG_PAGES or similar.  If it's done that way, then
> the driver needs to learn how to track ranges of pages efficiently,
> which is another reason to consider leaving all the fancy page / page
> range tracking in the driver.
> 
> I don't think it's a good idea for a page fault on any non-EADDed page
> in ELRANGE to automatically populate the page.

I'm with you. The user code shall be explicit on which range to EAUG pages upon #PF. What I'm saying is, a range has to be mapped before the driver could receive #PFs (in the form of vm_ops->fault callbacks). But Sean's series doesn’t support that because no pages can be mapped before coming into existence.

For "page tracking", what information to track is LSM dependent, so it may run into problems if different LSMs want to track different things. And that's the major reason I think it should be done inside LSM. 

Besides, the current page tracking structure in the driver is page oriented and its sole purpose is to serve #PFs. Page protection is better tracked using range oriented structures. Those 2 are orthogonal. It wouldn't reduce the complexity of the whole kernel by moving it into SGX driver.