All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Kees Cook <keescook@chromium.org>,
	Christophe Leroy <christophe.leroy@c-s.fr>,
	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,
	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: Fri, 3 Apr 2020 10:49:40 +0100	[thread overview]
Message-ID: <20200403094940.GA25745@shell.armlinux.org.uk> (raw)
In-Reply-To: <20200403005831.GI23230@ZenIV.linux.org.uk>

On Fri, Apr 03, 2020 at 01:58:31AM +0100, Al Viro wrote:
> On Thu, Apr 02, 2020 at 11:35:57AM -0700, Kees Cook wrote:
> 
> > Yup, I think it's a weakness of the ARM implementation and I'd like to
> > not extend it further. AFAIK we should never nest, but I would not be
> > surprised at all if we did.
> > 
> > If we were looking at a design goal for all architectures, I'd like
> > to be doing what the public PaX patchset did for their memory access
> > switching, which is to alarm if calling into "enable" found the access
> > already enabled, etc. Such a condition would show an unexpected nesting
> > (like we've seen with similar constructs with set_fs() not getting reset
> > during an exception handler, etc etc).
> 
> FWIW, maybe I'm misreading the ARM uaccess logics, but... it smells like
> KERNEL_DS is somewhat more dangerous there than on e.g. x86.
> 
> Look: with CONFIG_CPU_DOMAINS, set_fs(KERNEL_DS) tells MMU to ignore
> per-page permission bits in DOMAIN_KERNEL (i.e. for kernel address
> ranges), allowing them even if they would normally be denied.  We need
> that for actual uaccess loads/stores, since those use insns that pretend
> to be done in user mode and we want them to access the kernel pages.
> But that affects the normal loads/stores as well; unless I'm misreading
> that code, it will ignore (supervisor) r/o on a page.  And that's not
> just for the code inside the uaccess blocks; *everything* done under
> KERNEL_DS is subject to that.
> 
> Why do we do that (modify_domain(), that is) inside set_fs() and not
> in uaccess_enable() et.al.?

First, CONFIG_CPU_DOMAINS is used on older ARMs, not ARMv7. Second,
the kernel image itself is not RO-protected on any ARM32 platform.

If we get rid of CONFIG_CPU_DOMAINS, we will use the ARMv7 method of
user access, which is to use normal load/stores for the user accessors
and every access must check against the address limit, even the
__-accessors.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up

WARNING: multiple messages have this Message-ID (diff)
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: linux-arch@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	Kees Cook <keescook@chromium.org>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	airlied@linux.ie, hpa@zytor.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, Paul Mackerras <paulus@samba.org>,
	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: Fri, 3 Apr 2020 10:49:40 +0100	[thread overview]
Message-ID: <20200403094940.GA25745@shell.armlinux.org.uk> (raw)
In-Reply-To: <20200403005831.GI23230@ZenIV.linux.org.uk>

On Fri, Apr 03, 2020 at 01:58:31AM +0100, Al Viro wrote:
> On Thu, Apr 02, 2020 at 11:35:57AM -0700, Kees Cook wrote:
> 
> > Yup, I think it's a weakness of the ARM implementation and I'd like to
> > not extend it further. AFAIK we should never nest, but I would not be
> > surprised at all if we did.
> > 
> > If we were looking at a design goal for all architectures, I'd like
> > to be doing what the public PaX patchset did for their memory access
> > switching, which is to alarm if calling into "enable" found the access
> > already enabled, etc. Such a condition would show an unexpected nesting
> > (like we've seen with similar constructs with set_fs() not getting reset
> > during an exception handler, etc etc).
> 
> FWIW, maybe I'm misreading the ARM uaccess logics, but... it smells like
> KERNEL_DS is somewhat more dangerous there than on e.g. x86.
> 
> Look: with CONFIG_CPU_DOMAINS, set_fs(KERNEL_DS) tells MMU to ignore
> per-page permission bits in DOMAIN_KERNEL (i.e. for kernel address
> ranges), allowing them even if they would normally be denied.  We need
> that for actual uaccess loads/stores, since those use insns that pretend
> to be done in user mode and we want them to access the kernel pages.
> But that affects the normal loads/stores as well; unless I'm misreading
> that code, it will ignore (supervisor) r/o on a page.  And that's not
> just for the code inside the uaccess blocks; *everything* done under
> KERNEL_DS is subject to that.
> 
> Why do we do that (modify_domain(), that is) inside set_fs() and not
> in uaccess_enable() et.al.?

First, CONFIG_CPU_DOMAINS is used on older ARMs, not ARMv7. Second,
the kernel image itself is not RO-protected on any ARM32 platform.

If we get rid of CONFIG_CPU_DOMAINS, we will use the ARMv7 method of
user access, which is to use normal load/stores for the user accessors
and every access must check against the address limit, even the
__-accessors.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up

  reply	other threads:[~2020-04-03  9:50 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
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 [this message]
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=20200403094940.GA25745@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --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=keescook@chromium.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --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.