public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>,
	Andy Lutomirski <luto@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-api <linux-api@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Boqun Feng <boqun.feng@gmail.com>,
	Dave Watson <davejwatson@fb.com>, Paul Turner <pjt@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Russell King <linux@arm.linux.org.uk>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Andi Kleen <andi@firstfloor.org>, Chris Lameter <cl@linux.com>,
	Ben Maurer <bmaurer@fb.com>, rostedt <rostedt@goodmis.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Michael Kerrisk <mtk.manpages@gmail.com>,
	Joel Fernandes <joelaf@google.com>
Subject: Re: [RFC PATCH for 4.18 1/2] rseq: validate rseq_cs fields are < TASK_SIZE
Date: Fri, 29 Jun 2018 11:03:42 -0400 (EDT)	[thread overview]
Message-ID: <729451355.9702.1530284622326.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <CA+55aFxRJWjbgLeSQ_swi3F5nF1SYgZnC-R7QsOvZdcuSaWeaw@mail.gmail.com>

----- On Jun 29, 2018, at 10:17 AM, Linus Torvalds torvalds@linux-foundation.org wrote:

> On Fri, Jun 29, 2018 at 7:05 AM Mathieu Desnoyers
> <mathieu.desnoyers@efficios.com> wrote:
>>
>> What I'm worried about is setting regs->ip of a compat 32-bit task to
>> addresses in the range 0x100000000-0xFFFFFFFFFFFFFFFF.
> 
> Well, they won't have anything mapped in that range, so it really
> shouldn't matter.

It appears that arm64 simply clears the top bits of regs->ip when
returning to 32-bit compat userspace. So this would be inconsistent
between 32-bit kernel and 64-bit kernel with a 32-bit compat task:
a 32-bit kernel would kill the process, but a 64-bit kernel would
silently clear the top bits.

Considering those inconsistencies between architectures (either
the task gets killed, or the top bits are silently cleared), I'm
very much tempted to be restrictive in the inputs accepted by
rseq, and not rely on architectures as providing consistent
validation of the return IP.

Thoughts ?

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

  reply	other threads:[~2018-06-29 15:03 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-28 16:23 [RFC PATCH for 4.18 1/2] rseq: validate rseq_cs fields are < TASK_SIZE Mathieu Desnoyers
2018-06-28 16:23 ` [RFC PATCH for 4.18 2/2] rseq: check that rseq->rseq_cs padding is zero Mathieu Desnoyers
2018-06-28 16:53   ` Will Deacon
2018-06-28 20:55     ` Mathieu Desnoyers
2018-06-28 20:22 ` [RFC PATCH for 4.18 1/2] rseq: validate rseq_cs fields are < TASK_SIZE Andy Lutomirski
2018-06-28 20:56   ` Mathieu Desnoyers
2018-06-28 21:22   ` Linus Torvalds
2018-06-28 22:29     ` Mathieu Desnoyers
2018-06-28 23:29     ` Andy Lutomirski
2018-06-29  0:18       ` Linus Torvalds
2018-06-29  0:54         ` Mathieu Desnoyers
2018-06-29  1:08         ` Andy Lutomirski
2018-06-29 14:02           ` Linus Torvalds
2018-06-29 14:05             ` Mathieu Desnoyers
2018-06-29 14:17               ` Linus Torvalds
2018-06-29 15:03                 ` Mathieu Desnoyers [this message]
     [not found]                   ` <CA+55aFw==YnFJn7iGnKMW=RbPT74YHNa0QDF96mEdMPA2oX9SA@mail.gmail.com>
2018-06-29 15:54                     ` Linus Torvalds
2018-06-29 16:07                       ` Mathieu Desnoyers
2018-06-29 17:03                         ` Linus Torvalds
2018-06-29 19:48                           ` Mathieu Desnoyers
2018-06-29 20:39                             ` Andy Lutomirski
2018-07-02 14:32                               ` Mathieu Desnoyers
2018-07-02 16:04                                 ` Mathieu Desnoyers
2018-07-02 17:11                                 ` Andy Lutomirski
2018-07-02 19:00                                   ` Mathieu Desnoyers
2018-07-02 19:02                                     ` Andy Lutomirski
2018-07-02 19:31                                       ` Linus Torvalds
2018-07-02 20:12                                         ` Andy Lutomirski
2018-07-02 20:22                                           ` Linus Torvalds
2018-06-29 16:07                     ` Andy Lutomirski
2018-06-29 13:55       ` Mathieu Desnoyers

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=729451355.9702.1530284622326.JavaMail.zimbra@efficios.com \
    --to=mathieu.desnoyers@efficios.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=bmaurer@fb.com \
    --cc=boqun.feng@gmail.com \
    --cc=catalin.marinas@arm.com \
    --cc=cl@linux.com \
    --cc=davejwatson@fb.com \
    --cc=hpa@zytor.com \
    --cc=joelaf@google.com \
    --cc=josh@joshtriplett.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=mtk.manpages@gmail.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=pjt@google.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=will.deacon@arm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox