Hi! > Thanks for the lively discussion. I have tried to answer some of the > comments below. > > There are options today, e.g. > > > > a) If the restriction is only per-alias, you can have distinct aliases > > where one is writable and another is executable, and you can make it > > hard to find the relationship between the two. > > > > b) If the restriction is only temporal, you can write instructions into > > an RW- buffer, transition the buffer to R--, verify the buffer > > contents, then transition it to --X. > > > > c) You can have two processes A and B where A generates instrucitons into > > a buffer that (only) B can execute (where B may be restricted from > > making syscalls like write, mprotect, etc). > > The general principle of the mitigation is W^X. I would argue that > the above options are violations of the W^X principle. If they are > allowed today, they must be fixed. And they will be. So, we cannot > rely on them. Would you mind describing your threat model? Because I believe you are using model different from everyone else. In particular, I don't believe b) is a problem or should be fixed. I'll add d), application mmaps a file(R--), and uses write syscall to change trampolines in it. > b) This is again a violation. The kernel should refuse to give execute > ???????? permission to a page that was writeable in the past and refuse to > ???????? give write permission to a page that was executable in the past. Why? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
