Messages in this thread | | | Subject | Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function | From | Dave Hansen <> | Date | Mon, 10 Jun 2019 15:59:29 -0700 |
| |
On 6/10/19 3:40 PM, Yu-cheng Yu wrote: > Ok, we will go back to do_mmap() with MAP_PRIVATE, MAP_NORESERVE and > VM_DONTDUMP. The bitmap will cover only 48-bit address space.
Could you make sure to discuss the downsides of only doing a 48-bit address space?
What are the reasons behind and implications of VM_DONTDUMP?
> We then create PR_MARK_CODE_AS_LEGACY. The kernel will set the bitmap, but it > is going to be slow.
Slow compared to what? We're effectively adding one (quick) system call to a path that, today, has at *least* half a dozen syscalls and probably a bunch of page faults. Heck, we can probably avoid the actual page fault to populate the bitmap if we're careful. That alone would put a syscall on equal footing with any other approach. If the bit setting crossed a page boundary it would probably win.
> Perhaps we still let the app fill the bitmap?
I think I'd want to see some performance data on it first.
| |