> On Oct 24, 2020, at 7:38 AM, Dr. Greg <greg@xxxxxxxxxxxx> wrote: > > > I can't bring myself to believe that LSM's are going to be written > that will be making enclave security decisions on a page by page > basis. Given what I have written above, I think all of this comes > down to giving platform administrators one of three decisions, in > order of most to least secure: > > 1.) Block dynamic code loading and execution. > I don’t understand what you’re trying to say. Unless we’re going to split enclaves into multiple VMAs with different permissions, how do you expect to block dynamic code loading unless you have separate RW and RX pages? That would be “page-by-page”, right? > 2.) Block access to RWX pages. > > 3.) The wild west - no restrictions on enclave page protection manipulation. > > From a security perspective I would argue for the wisdom of making > option 1 unconditional via a kernel command-line parameter. > > It may be that ->mprotect is the right mechanism to implement this. > If that is the case, frame the discussion and documentation so that it > reflects the actual security threat and the consideration and means > for dealing with it. > > Hopefully all of this is useful to the stakeholders in this > technology. > > Have a good weekend. > > Dr. Greg > > As always, > Dr. Greg Wettstein, Ph.D, Worker Autonomously self-defensive > Enjellic Systems Development, LLC IOT platforms and edge devices. > 4206 19th Ave. N. > Fargo, ND 58102 > PH: 701-281-1686 EMAIL: greg@xxxxxxxxxxxx > ------------------------------------------------------------------------------ > "Politics is the business of getting power and privilege without possessing > merit." > -- P.J. O'Rourke
