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:01:27 -0700 [thread overview]
Message-ID: <57147837.2030706@zytor.com> (raw)
In-Reply-To: <CALCETrUSu5cnUfqwK1FK61UnQ6uo=QccPejtohuQRhhz7aP1iw@mail.gmail.com>
On 04/17/16 22:48, Andy Lutomirski wrote:
>
> I think I prefer the "reject weird input" behavior over the "accept
> and normalize weird input" if we can get away with it, and I'm fairly
> confident that we can get away with "reject weird input" given that
> distro kernels do exactly that already.
>
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.
So I'm not sure this is a valid consideration. The reason it generally
works is because the natural way for the user space code to work is to
load a value into %eax which will naturally zero-extend to %rax, but it
isn't inherently required to work that way.
-hpa
next prev parent reply other threads:[~2016-04-18 6:01 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 [this message]
2016-04-18 6:14 ` Andy Lutomirski
2016-04-18 6:19 ` H. Peter Anvin
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=57147837.2030706@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.