On 01/05/2017 01:27 PM, Andy Lutomirski wrote: > On Thu, Jan 5, 2017 at 12:49 PM, Dave Hansen <dave.hansen@xxxxxxxxx> wrote: ... >> Remember, we already have (legacy MPX) binaries in the wild that have no >> knowledge of this stuff. So, we can implicitly have the kernel bump >> this rlimit around, but we can't expect userspace to do it, ever. > > If you s/rlimit/prctl, then I think this all makes sense with one > exception. It would be a bit sad if the personality-setting tool > didn't work if compiled with MPX. Ahh, because if you have MPX enabled you *can't* sanely switch between the two modes because you suddenly go from having small bounds tables to having big ones? It's not the simplest thing in the world to do, but there's nothing keeping the personality-setting tool from doing all the work. It can do: new_bd = malloc(1TB); prctl(MPX_DISABLE_MANAGEMENT); memcpy(new_bd, old_bd, LEGACY_MPX_BD_SIZE); set_bounds_config(new_bd | ENABLE_BIT); prctl(WIDER_VADDR_WIDTH); prctl(MPX_ENABLE_MANAGEMENT); > So what if we had a second prctl field that is the value that kicks in > after execve()? Yeah, that's a pretty sane way to do it too. execve() is a nice chokepoint. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
