On Mon, Jul 08, 2019 at 05:02:00PM -0700, Casey Schaufler wrote: > On 7/7/2019 6:30 AM, Dr. Greg wrote: > > On Wed, Jul 03, 2019 at 08:32:10AM -0700, Casey Schaufler wrote: > > > > Good morning, I hope the weekend has been enjoyable for everyone. > > > >>>> On 7/2/2019 12:42 AM, Xing, Cedric wrote: > >>>>> ... > >>>>> Guess this discussion will never end if we don't get into > >>>>> code. Guess it'd be more productive to talk over phone then come back > >>>>> to this thread with a conclusion. Will that be ok with you? > >>>> I don't think that a phone call is going to help. Talking code > >>>> issues tends to muddle them in my brain. If you can give me a few > >>>> days I will propose a rough version of how I think your code should > >>>> be integrated into the LSM environment. I'm spending more time > >>>> trying (unsuccessfully :( ) to discribe the issues in English than > >>>> it will probably take in C. > >>> While Casey is off writing his rosetta stone, > >> I'd hardly call it that. More of an effort to round the corners on > >> the square peg. And Cedric has some ideas on how to approach that. > > Should we infer from this comment that, of the two competing > > strategies, Cedric's is the favored architecture? > > With Cedric's latest patches I'd say there's only one > strategy. There's still some refinement to do, but we're > getting there. Dynamic tracking has an unsolvable race condition. If process A maps a page W and process B maps the same page X, then the result of W^X checks depends on the order of mprotect() calls between A and B. If we're ok saying "don't do that" then I can get behind dynamic tracking as a whole. Even if we settle on dynamic tracking, where that tracking code lives is still an open IMO.
