From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>,
Peter Anvin <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
the arch/x86 maintainers <x86@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] de-asmify the x86-64 system call slowpath
Date: Mon, 27 Jan 2014 23:07:53 +0000 [thread overview]
Message-ID: <20140127230753.GF10323@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CA+55aFyajjkCtRiTOS2AbFOWi7qt2FUnW6T3iG9nXqoZ0O9Ljg@mail.gmail.com>
On Mon, Jan 27, 2014 at 02:43:14PM -0800, Linus Torvalds wrote:
> On Mon, Jan 27, 2014 at 2:32 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > do_signal() is also a place where arbitrary changes to regs might've
> > been done by tracer, so regs->cs might need to be checked in the same
> > place where we validate regs->rip ;-/
>
> Fair enough. But it would still be really easy, and make the common
> case signal delivery a bit faster.
>
> Now, sadly, most signal delivery is then followed by sigreturn (the
> exceptions being dying or doing a longjmp), so we'd still get the
> iretq then. But it would cut the iretq's related to signals in half.
>
> We *could* try to do sigreturn with sysret and a small trampoline too,
> of course. But I'm not sure how far I'd want to take it.
The problem with validation is that we'll suddenly become sensitive to
hard-to-estimate pile of hardware bugs ;-/ E.g. which AMD-specific
errata is that comment in entry_64.S about? The one I kinda-sorta
remember is Intel-specific, and that was about uncanonical RIP; looking
for AMD one has turned #353 (with suggested workaround being "have bit 16 set
in whatever you put into R11"), but I've no idea whether that's the only
potential issue there...
next prev parent reply other threads:[~2014-01-27 23:09 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-26 22:28 [RFC] de-asmify the x86-64 system call slowpath Linus Torvalds
2014-01-27 0:22 ` Al Viro
2014-01-27 4:32 ` Linus Torvalds
2014-01-27 4:48 ` H. Peter Anvin
2014-01-27 7:42 ` Al Viro
2014-01-27 22:06 ` Andy Lutomirski
2014-01-27 22:17 ` Linus Torvalds
2014-01-27 22:32 ` Al Viro
2014-01-27 22:43 ` Linus Torvalds
2014-01-27 22:46 ` Andy Lutomirski
2014-01-28 0:22 ` H. Peter Anvin
2014-01-28 0:44 ` Andy Lutomirski
2014-01-27 23:07 ` Al Viro [this message]
2014-01-27 10:27 ` Peter Zijlstra
2014-01-27 11:36 ` Al Viro
2014-01-27 17:39 ` Oleg Nesterov
2014-01-28 1:18 ` Al Viro
2014-01-28 16:38 ` Oleg Nesterov
2014-01-28 16:48 ` Al Viro
2014-01-28 17:19 ` Oleg Nesterov
2014-02-06 0:32 ` Linus Torvalds
2014-02-06 0:55 ` Kirill A. Shutemov
2014-02-06 2:32 ` Linus Torvalds
2014-02-06 4:33 ` Linus Torvalds
2014-02-06 21:29 ` Linus Torvalds
2014-02-06 22:24 ` Kirill A. Shutemov
2014-02-07 1:31 ` Linus Torvalds
2014-02-07 15:42 ` [RFC, PATCH] mm: map few pages around fault address if they are in page cache Kirill A. Shutemov
2014-02-07 17:32 ` Andi Kleen
2014-02-07 17:56 ` Kirill A. Shutemov
2014-02-07 18:11 ` Andi Kleen
2014-02-06 5:42 ` [RFC] de-asmify the x86-64 system call slowpath Ingo Molnar
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=20140127230753.GF10323@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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.