Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1379141 > unrolled thread

System call number masking

Back to article view | Back to linux.kernel

Contents

  System call number masking Ben Hutchings <ben@decadent.org.uk> - 2016-04-14 19:30 +0200
    Re: System call number masking Andy Lutomirski <luto@amacapital.net> - 2016-04-14 19:50 +0200

#1379141 — System call number masking

[Multipart message — attachments visible in raw view] — view raw

I'm updating my x32-as-boot-time-option patch for 4.6, and I noticed a
subtle change in system call number masking on x86_64 as a result of
moving the slow path into C.

Previously we would mask out the upper 32 bits before doing anything
with the system call number, both on the slow and fast paths, if and
only if x32 was enabled.

Now we always mask out the upper 32 bits on the slow path, so it's not
quite consistent with the fast path if x32 is disabled.  A system call
that would be rejected by the fast path can succeed on the slow path.
I don't know whether this causes any problems, but it seems
undesirable.

But it's also undesirable that the behaviour of system call numbers not
assigned to x32 also varies depending on whether x32 is enabled.
Should we always mask out the upper 32 bits on the fast path?

Ben.

-- 
Ben Hutchings
In a hierarchy, every employee tends to rise to his level of incompetence.

[toc] | [next] | [standalone]

#1379163

On Thu, Apr 14, 2016 at 10:22 AM, Ben Hutchings <ben@decadent.org.uk> wrote:
> I'm updating my x32-as-boot-time-option patch for 4.6, and I noticed a
> subtle change in system call number masking on x86_64 as a result of
> moving the slow path into C.
>
> Previously we would mask out the upper 32 bits before doing anything
> with the system call number, both on the slow and fast paths, if and
> only if x32 was enabled.

I always thought that the old behavior was nonsensical.  The behavior
should be the same regardless of config options.

>
> Now we always mask out the upper 32 bits on the slow path, so it's not
> quite consistent with the fast path if x32 is disabled.  A system call
> that would be rejected by the fast path can succeed on the slow path.
> I don't know whether this causes any problems, but it seems
> undesirable.
>
> But it's also undesirable that the behaviour of system call numbers not
> assigned to x32 also varies depending on whether x32 is enabled.
> Should we always mask out the upper 32 bits on the fast path?
>

I think we should.  Alternatively, the ja 1f that takes us back out if
the syscall nr is invalid could be changed to jump to the slow path,
thus avoiding an instruction in the fast path and keeping the code a
bit cleaner.

--Andy

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web