On Mon, Jul 1, 2019 at 10:11 AM Xing, Cedric <cedric.xing@xxxxxxxxx> wrote: > > Hi Andy, > > > From: Andy Lutomirski [mailto:luto@xxxxxxxxxx] > > Sent: Saturday, June 29, 2019 4:47 PM > > > > Just on a very cursory review, this seems like it's creating a bunch of > > complexity (a whole new library and data structure), and I'm not > > convinced the result is any better than Sean's version. > > The new EMA data structure is to track enclave pages by range. Yes, Sean avoided that by storing similar information in the existing encl_page structure inside SGX subsystem. But as I pointed out, his code has to iterate through *every* page in range so mprotect() will be very slow if the range is large. So he would end up introducing something similar to achieve the same performance. It seems odd to stick it in security/ if it only has one user, though. Also, if it wasn't in security/, then the security folks would stop complaining :) > > And that's not the most important point. The major problem in his patch lies in SGX2 support, as #PF driven EAUG cannot be supported (or he'd have to amend his code accordingly, which will add complexity and tip your scale). > Why can't it be?
