"H. Peter Anvin" <[email protected]> writes:
> On July 3, 2026 4:39:18 AM PDT, Sven Schnelle <[email protected]>
> wrote:
>>Michal Suchánek <[email protected]> writes:
>>
>>> The same could be asked of syscall_enter_from_user_mode. I find it
> very
>>> odd. Why does it conflate the syscall number with its return value?
>>>
>>> It never uses the syscall number passed in except when returning it
>>> unchanged. When it pokes the registers it reads the syscall number
> from
>>> them.
>>>
>>> If the caller of syscall_enter_from_user_mode only read the syscall
>>> number from the registers when syscall_enter_from_user_mode returns
> and
>>> indicates the syscall should be still executed this whole shenigan
> would
>>
>>I agree. The fact that if (nr < NR_syscall) just works because -1
> gets
>>casted to 0xffffffff and is therefore out of bounds is very odd.
>>
>
> Not at all strange. It is an *extremely* common construct in C,
> especially for range checking values into [0, n).
A clear indication that this is not as common as you think is that
there's an extra comment in arch/x86/entry/syscall_64.c:
/*
* Convert negative numbers to very high and thus out of range
* numbers for comparisons.
*/
If everyone knows what this is the comment wouldn't be necessary. But
that cast is not the thing i'm really interested in - if it stays
that way, fine with me. But I would like to see the change from Michal
going in which untangles the secure_computing() return value from the
syscall number. Because this behaviour is very subtle and removing that
would make things easier. (And also easier to read/audit, which is
always importand with security related code, which seccomp/syscall
clearly is).
> In addition to being idiomatic, keep in mind that this is one of the
> absolutely most performance critical paths in the entire kernel. One
> of the fundamental cornerstones behind Unix is to keep system calls
> cheap so that they can be simple building blocks for more complex
> operations. It is not the only possible design philosophy, but it is
> the one we chose to adopt, quite successfully.
>
> The downside? Squeezing every possible cycle out of the system call
> path becomes one of the most essential tuning tasks. The good part is
> that keeping the system call path clean also makes it maintainable,
> even when there are quirks.
I haven't measured it, but I doubt that the unsigned vs signed syscall
bounds check makes a difference in real world scenarios. Even for
ni_syscall cases it would be small. With the C entry code we have
nowadays such optimizations should be left to the compiler. I wouldn't
be surprised if the generated code is even the same.
But as written above, I don't really care about this.
