All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Ben Hutchings <ben@decadent.org.uk>,
	Andy Lutomirski <luto@kernel.org>, X86 ML <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86/entry/x32: Check top 32 bits of syscall number on the fast path
Date: Sun, 17 Apr 2016 23:19:34 -0700	[thread overview]
Message-ID: <57147C76.3060005@zytor.com> (raw)
In-Reply-To: <CALCETrXfWWNTNy-hKxT6K+XQqDRdu=45jF+ZcMKvB0ANm4jYGQ@mail.gmail.com>

On 04/17/16 23:14, Andy Lutomirski wrote:
>>
>> It's not "weird", it is the ABI as defined.  We have to do this for all
>> the system call arguments, too; you just don't notice it because the
>> compiler does it for us.  Some other architectures, e.g. s390, has the
>> opposite convention where the caller is responsible for normalizing the
>> result; in that case we have to do it *again* in the kernel, which is
>> one of the major reasons for the SYSCALL_*() macros.
> 
> What ABI?
> 

The C ABI for int.  I hadn't seen the below, because I think syscall(3)
is just braindamaged, but the odds are that if we'd ever use the upper
32 bits for anything we'd be in a world of hurt, so that would be highly
theoretical IMO.  Bit 31 might be possible, but I wouldn't really want
to brave it unless we really have no choice.

> Also, the behavior in which fail the syscall if any high bits are set
> is faster -- it's one fewer instruction.  Admittedly, the CPU can
> probably do that instruction for free, but still...

Yes, it can; at least on any remotely modern hardware.

	-hpa

  reply	other threads:[~2016-04-18  6:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-14 17:22 System call number masking Ben Hutchings
2016-04-14 17:48 ` Andy Lutomirski
2016-04-18  0:45   ` Ben Hutchings
2016-04-18  0:47     ` [PATCH] x86/entry/x32: Check top 32 bits of syscall number on the fast path Ben Hutchings
2016-04-18  4:50       ` H. Peter Anvin
2016-04-18  5:18         ` Andy Lutomirski
2016-04-18  5:21           ` H. Peter Anvin
2016-04-18  5:39             ` Andy Lutomirski
2016-04-18  5:45               ` H. Peter Anvin
2016-04-18  5:48                 ` Andy Lutomirski
2016-04-18  6:01                   ` H. Peter Anvin
2016-04-18  6:14                     ` Andy Lutomirski
2016-04-18  6:19                       ` H. Peter Anvin [this message]
2016-04-18  5:24           ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57147C76.3060005@zytor.com \
    --to=hpa@zytor.com \
    --cc=ben@decadent.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.