[PATCH v7 1/3] Add an internal wrapper for clone, clone2 and clone3

Adhemerval Zanella adhemerval.zanella@linaro.org
Mon May 31 15:57:50 GMT 2021



On 31/05/2021 11:01, H.J. Lu wrote:
> On Mon, May 31, 2021 at 6:53 AM Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
>>
>>
>>
>> On 31/05/2021 10:16, H.J. Lu wrote:
>>> On Mon, May 31, 2021 at 6:01 AM Florian Weimer <fweimer@redhat.com> wrote:
>>>>
>>>> * H. J. Lu:
>>>>
>>>>> In the kernel, clone3 and clone go to the same piece of code.  clone won't
>>>>> fail just because of CET.
>>>>
>>>> But clone won't have access to the stack boundaries.  Won't this create
>>>> issues for setting up the shadow stack?
>>>>
>>>
>>> No.  There are:
>>>
>>>         /* Cap shadow stack size to 4 GB */
>>>         size = min_t(unsigned long long, rlimit(RLIMIT_STACK), SZ_4G);
>>>         size = min(size, stack_size);
>>>
>>> where stack_size is passed in clone3.
>>
>> Right, so CET support does not really require clone3 to be used internally
>> then? Or am I missing something?
> 
> Shadow stack size shouldn't be more than normal stack size.  The current
> CET kernel shadow stack size may not be optimal.  My original code did
> 
> if (stack_size != 0)
>   size = stack_size;
> else
>   size = min_t(unsigned long long, rlimit(RLIMIT_STACK), SZ_4G);
> 
> But
> 
> 1. I don't want to disturb it before CET changes are upstreamed.
> 2. It can be updated AFTER it has been upstreamed.

Right, so I take this is just an optimization assuming that the extra
size would unused, right? I still failing to see why clone3 is an
requirement for CET enablement (if I understood this correctly).

I still think supporting clone3 is a nice thing to have, specially
for possible newer architectures and to support newer flags and
functionalities. 


More information about the Libc-alpha mailing list