All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	airlied@linux.ie, daniel@ffwll.ch, torvalds@linux-foundation.org,
	akpm@linux-foundation.org, hpa@zytor.com,
	linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-mm@kvack.org, linux-arch@vger.kernel.org,
	Russell King <linux@armlinux.org.uk>,
	Christian Borntraeger <borntraeger@de.ibm.com>
Subject: Re: [PATCH RESEND 1/4] uaccess: Add user_read_access_begin/end and user_write_access_begin/end
Date: Thu, 2 Apr 2020 10:38:32 -0700	[thread overview]
Message-ID: <202004021035.573BBBE9AA@keescook> (raw)
In-Reply-To: <67e21b65-0e2d-7ca5-7518-cec1b7abc46c@c-s.fr>

On Thu, Apr 02, 2020 at 07:03:28PM +0200, Christophe Leroy wrote:
> > What should we do about arm and s390?  There we want a cookie passed
> > from beginning of block to its end; should that be a return value?
> 
> That was the way I implemented it in January, see
> https://patchwork.ozlabs.org/patch/1227926/
> 
> There was some discussion around that and most noticeable was:
> 
> H. Peter (hpa) said about it: "I have *deep* concern with carrying state in
> a "key" variable: it's a direct attack vector for a crowbar attack,
> especially since it is by definition live inside a user access region."

I share this concern -- we want to keep user/kernel access as static as
possible. It should be provable with static analysis, etc (e.g. objtool
does this already for x86).

Since this doesn't disrupt existing R+W access, I'd prefer the design of
this series as-is.

-- 
Kees Cook

WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: linux-arch@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	airlied@linux.ie, hpa@zytor.com, linux-kernel@vger.kernel.org,
	Russell King <linux@armlinux.org.uk>,
	linux-mm@kvack.org, Paul Mackerras <paulus@samba.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	daniel@ffwll.ch, akpm@linux-foundation.org,
	torvalds@linux-foundation.org
Subject: Re: [PATCH RESEND 1/4] uaccess: Add user_read_access_begin/end and user_write_access_begin/end
Date: Thu, 2 Apr 2020 10:38:32 -0700	[thread overview]
Message-ID: <202004021035.573BBBE9AA@keescook> (raw)
In-Reply-To: <67e21b65-0e2d-7ca5-7518-cec1b7abc46c@c-s.fr>

On Thu, Apr 02, 2020 at 07:03:28PM +0200, Christophe Leroy wrote:
> > What should we do about arm and s390?  There we want a cookie passed
> > from beginning of block to its end; should that be a return value?
> 
> That was the way I implemented it in January, see
> https://patchwork.ozlabs.org/patch/1227926/
> 
> There was some discussion around that and most noticeable was:
> 
> H. Peter (hpa) said about it: "I have *deep* concern with carrying state in
> a "key" variable: it's a direct attack vector for a crowbar attack,
> especially since it is by definition live inside a user access region."

I share this concern -- we want to keep user/kernel access as static as
possible. It should be provable with static analysis, etc (e.g. objtool
does this already for x86).

Since this doesn't disrupt existing R+W access, I'd prefer the design of
this series as-is.

-- 
Kees Cook

  reply	other threads:[~2020-04-02 17:38 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-02  7:34 [PATCH RESEND 1/4] uaccess: Add user_read_access_begin/end and user_write_access_begin/end Christophe Leroy
2020-04-02  7:34 ` Christophe Leroy
2020-04-02  7:34 ` [PATCH RESEND 2/4] uaccess: Selectively open read or write user access Christophe Leroy
2020-04-02  7:34   ` Christophe Leroy
2020-04-02  7:51   ` Kees Cook
2020-04-02  7:51     ` Kees Cook
2020-04-02  8:00     ` Christophe Leroy
2020-04-02  8:00       ` Christophe Leroy
2020-04-02  7:34 ` [PATCH RESEND 3/4] drm/i915/gem: Replace user_access_begin by user_write_access_begin Christophe Leroy
2020-04-02  7:34   ` Christophe Leroy
2020-04-02  7:52   ` Kees Cook
2020-04-02  7:52     ` Kees Cook
2020-04-02  7:59     ` Christophe Leroy
2020-04-02  7:59       ` Christophe Leroy
2020-04-02  7:34 ` [PATCH RESEND 4/4] powerpc/uaccess: Implement user_read_access_begin and user_write_access_begin Christophe Leroy
2020-04-02  7:34   ` Christophe Leroy
2020-04-02  7:52   ` Kees Cook
2020-04-02  7:52     ` Kees Cook
2020-04-02  7:46 ` [PATCH RESEND 1/4] uaccess: Add user_read_access_begin/end and user_write_access_begin/end Kees Cook
2020-04-02  7:46   ` Kees Cook
2020-04-02 16:29 ` Al Viro
2020-04-02 16:29   ` Al Viro
2020-04-02 17:03   ` Christophe Leroy
2020-04-02 17:03     ` Christophe Leroy
2020-04-02 17:38     ` Kees Cook [this message]
2020-04-02 17:38       ` Kees Cook
2020-04-02 17:50     ` Al Viro
2020-04-02 17:50       ` Al Viro
2020-04-02 18:35       ` Christophe Leroy
2020-04-02 18:35         ` Christophe Leroy
2020-04-02 18:35       ` Kees Cook
2020-04-02 18:35         ` Kees Cook
2020-04-02 19:26         ` Linus Torvalds
2020-04-02 19:26           ` Linus Torvalds
2020-04-02 20:27           ` Kees Cook
2020-04-02 20:27             ` Kees Cook
2020-04-02 20:47             ` Linus Torvalds
2020-04-02 20:47               ` Linus Torvalds
2020-04-03  0:58         ` Al Viro
2020-04-03  0:58           ` Al Viro
2020-04-03  9:49           ` Russell King - ARM Linux admin
2020-04-03  9:49             ` Russell King - ARM Linux admin
2020-04-03 11:26           ` Catalin Marinas
2020-04-03 11:26             ` Catalin Marinas
2020-04-03 13:37             ` Russell King - ARM Linux admin
2020-04-03 13:37               ` Russell King - ARM Linux admin
2020-04-03 17:26               ` Al Viro
2020-04-03 17:26                 ` Al Viro
2020-04-03 10:02         ` Russell King - ARM Linux admin
2020-04-03 10:02           ` Russell King - ARM Linux admin

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=202004021035.573BBBE9AA@keescook \
    --to=keescook@chromium.org \
    --cc=airlied@linux.ie \
    --cc=akpm@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=borntraeger@de.ibm.com \
    --cc=christophe.leroy@c-s.fr \
    --cc=daniel@ffwll.ch \
    --cc=hpa@zytor.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@armlinux.org.uk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /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.