On Tue, Aug 20, 2024 at 03:59:21PM +0100, Catalin Marinas wrote: > On Mon, Aug 19, 2024 at 05:33:24PM +0100, Mark Brown wrote: > > On Mon, Aug 19, 2024 at 10:10:36AM +0100, Catalin Marinas wrote: > > > At a quick look, do_mmap() seems to always set VM_MAYEXEC but discard it > > > for non-executable file mmap. Last time I looked (when doing MTE) there > > > wasn't a way for the arch code to clear specific VM_* flags, only to > > > validate them. But I think we should just clear VM_MAYEXEC and also > > > return an error for VM_EXEC in the core do_mmap() if VM_SHADOW_STACK. It > > > would cover the other architectures doing shadow stacks. > > Yes, I think adding something generic would make sense here. That feels > > like a cleanup which could be split out? > It can be done separately. It doesn't look like x86 has such checks. > Adding it generically would be a slight ABI tightening but I doubt it > matters, no sane software would use an executable shadow stack. OK. > > > Is there any arch restriction with setting BTI and GCS? It doesn't make > > > sense but curious if it matters. We block the exec permission anyway > > > (unless the BTI pages moved to PIE as well, I don't remember). > > As you say BTI should be meaningless for a non-executable page like GCS, > > I'm not aware of any way in which it matters. BTI is separate to PIE. > My thoughts were whether we can get rid of this hunk entirely by > handling it in the core code. We'd allow BTI if one wants such useless > combination but clear VM_MAYEXEC in the core code (and ignore VM_SHARED > since you can't set it anyway). I have to admit that the BTI because I was shoving _EXEC in there rather than because it specifically needed to be blocked. So change the check for VM_SHARED to a VM_WARN_ON(), and leave the _EXEC check for now pending the above core change?
Attachment:
signature.asc
Description: PGP signature
