On 2014-09-15, One Thousand Gnomes wrote:
>> The base of the bounds directory is set into mm_struct during
>> PR_MPX_REGISTER command execution. This member can be used to check
>> whether one application is mpx enabled.
>
> Not really because by the time you ask the question another thread
> might have decided to unregister it.
>
>
>> +int mpx_register(struct task_struct *tsk) {
>> + struct mm_struct *mm = tsk->mm;
>> +
>> + if (!cpu_has_mpx)
>> + return -EINVAL;
>> +
>> + /*
>> + * runtime in the userspace will be responsible for allocation of
>> + * the bounds directory. Then, it will save the base of the bounds
>> + * directory into XSAVE/XRSTOR Save Area and enable MPX through
>> + * XRSTOR instruction.
>> + *
>> + * fpu_xsave() is expected to be very expensive. In order to do
>> + * performance optimization, here we get the base of the bounds
>> + * directory and then save it into mm_struct to be used in future.
>> + */
>> + mm->bd_addr = task_get_bounds_dir(tsk);
>> + if (!mm->bd_addr)
>> + return -EINVAL;
>
> What stops two threads calling this in parallel ?
>> +
>> + return 0;
>> +}
>> +
>> +int mpx_unregister(struct task_struct *tsk) {
>> + struct mm_struct *mm = current->mm;
>> +
>> + if (!cpu_has_mpx)
>> + return -EINVAL;
>> +
>> + mm->bd_addr = NULL;
>
> or indeed calling this in parallel
>
> What are the semantics across execve() ?
>
This will not impact on the semantics of execve(). One runtime library for MPX
will be provided (or merged into Glibc), and when the application starts, this
runtime will be called to initialize MPX runtime environment, including calling
prctl() to notify the kernel to start managing the bounds directories. You can
see the discussion about exec(): https://lkml.org/lkml/2014/1/26/199
It would be extremely unusual for an application to have some MPX and some
non-MPX threads, since they would share the same address space and the non-MPX
threads would mess up the bounds. That is to say, it looks like be unusual for
one of these threads to call prctl() to enable or disable MPX. I guess we need
to add some rules into documentation.
Thanks,
Qiaowei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
