Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 9/9/2020 3:59 PM, Dave Hansen wrote:
On 9/9/20 3:08 PM, Yu, Yu-cheng wrote:
After looking at this more, I found the changes are more similar to
mprotect() than madvise().  We are going to change an anonymous mapping
to a read-only mapping, and add the VM_SHSTK flag to it.  Would an
x86-specific mprotect(PROT_SHSTK) make more sense?

One alternative would be requiring a read-only mapping for
madvise(MADV_SHSTK).  But that is inconvenient for the application.

Why?  It's just:

	mmap()/malloc();
	mprotect(PROT_READ);
	madvise(MADV_SHSTK);

vs.

	mmap()/malloc();
	mprotect(PROT_SHSTK);

I'm not sure a single syscall counts as inconvenient.

I don't quite think we should use a PROT_ bit for this.  It seems like
the kind of thing that could be fragile and break existing expectations.
  I don't care _that_ strongly though.

What if a writable mapping is passed to madvise(MADV_SHSTK)? Should that be rejected?





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux