[PATCH] linux: Add mseal syscall support

[Collin Funk]

Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> writes:

> On 13/10/25 17:48, Adhemerval Zanella Netto wrote:
>> 
>> 
>> On 10/10/25 16:41, Collin Funk wrote:
>>> Adhemerval Zanella <adhemerval.zanella@linaro.org> writes:
>>>
>>>> +      if (errno == ENOSYS)
>>>> +        FAIL_UNSUPPORTED
>>>> +          ("kernel does not support memory protection keys");
>>>> +      if (errno == EINVAL)
>>>> +        FAIL_UNSUPPORTED
>>>> +          ("CPU does not support memory protection keys: %m");
>>>
>>> Do any other syscalls fail with different errno's depending on if the
>>> kernel or the CPU do not support them? I feel like it is better to use
>>> ENOSYS in both cases, but maybe I am missing something.
>> 
>> I am trying to recall why I had to add this on previous version, I had the
>> impression that was because on 32-bit kernels the syscall might return it
>> but double checking it does return ENOSYS in this case as well.
>> 
>> I will remove this check.
>
> This comes from sysdeps/unix/sysv/linux/tst-pkey.c, where pkey_alloc is supported
> by the hardware does not support protection keys.  So the check seems fine indeed.
>
> And I do not recall any other syscall with this constraint on top of my mind.

Ah, for some reason I thought the errno was set by mseal, not pkey_alloc.

I asked because in Gnulib we override some functions if they are not
supported by the kernel. Like this:

   if (have_dup3_really >= 0)
     {
       int result = dup3 (oldfd, newfd, flags);
       if (!(result < 0 && errno == ENOSYS))
        {
          have_dup3_really = 1; /* We have dup3.  */
          /* Mess with wrong error numbers and such...  */
        }
       else
         have_dup3_really = -1; /* We don't have dup3.  */
     }

I wanted to avoid a new errno to check, since all other functions I know
of just return ENOSYS if it is not supported by the system. But it is
not relevant since those errno's are not from mseal.

>>>
>>> Also, for formatting long lines like this I think the following looks
>>> better:
>>>
>>>       FAIL_UNSUPPORTED ("CPU does not support "
>>>                         "memory protection keys: %m");
>>>
>>> Collin
>> 
>> Ack, I will double check the size.
>
> Hum this does seem to fit in 78-colmun, doesn't it?

Your original lines are under the limit, I just think that having the
macro name and the following opening parentheses on different lines
looks strange.

But since it already exists in sysdeps/unix/sysv/linux/tst-pkey.c, and
other places, I guess it is fine:

   $ git ls-files | grep '\.[ch]' | xargs grep 'FAIL_UNSUPPORTED$' \
       | wc -l
   7

I didn't see those before.

Collin