All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 11/20] amifb: get rid of pointless access_ok() calls
Date: Thu, 14 May 2020 16:25:35 +0200	[thread overview]
Message-ID: <f6fcfa46-6271-45ea-37c2-62bcf0a607cb@samsung.com> (raw)
In-Reply-To: <20200514140720.GB23230@ZenIV.linux.org.uk>


On 5/14/20 4:07 PM, Al Viro wrote:
> On Thu, May 14, 2020 at 03:45:09PM +0200, Bartlomiej Zolnierkiewicz wrote:
>>
>> Hi Al,
>>
>> On 5/10/20 1:45 AM, Al Viro wrote:
>>> From: Al Viro <viro@zeniv.linux.org.uk>
>>>
>>> addresses passed only to get_user() and put_user()
>>
>> This driver lacks checks for {get,put}_user() return values so it will
>> now return 0 ("success") even if {get,put}_user() fails.
>>
>> Am I missing something?
> 
> "now" is interesting, considering
> /* We let the MMU do all checking */
> static inline int access_ok(const void __user *addr,
>                             unsigned long size)
> {
>         return 1;
> }
> in arch/m68k/include/asm/uaccess_mm.h
> 
> Again, access_ok() is *NOT* about checking if memory is readable/writable/there
> in the first place.  All it does is a static check that address is in
> "userland" range - on architectures that have kernel and userland sharing the
> address space.  On architectures where we have separate ASI or equivalents
> thereof for kernel and for userland the fscker is always true.
> 
> If MMU will prevent access to kernel memory by uaccess insns for given address
> range, access_ok() is fine with it.  It does not do anything else.
> 
> And yes, get_user()/put_user() callers should handle the fact that those can
> fail.  Which they bloody well can _after_ _success_ of access_ok().  And
> without any races whatsoever.
> 
> IOW, the lack of such checks is a bug, but it's quite independent from the
> bogus access_ok() call.  On any architecture.  mmap() something, munmap()
> it and pass the address where it used to be to that ioctl().  Failing
> get_user()/put_user() is guaranteed, so's succeeding access_ok().
> 
> And that code is built only on amiga, so access_ok() always succeeds, anyway.

Thank you for in-detail explanations, for this patch:

Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

Could you also please take care of adding missing checks for {get,put}_user()
failures later?

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

  reply	other threads:[~2020-05-14 14:25 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-09 23:41 [PATCHES] uaccess simple access_ok() removals Al Viro
2020-05-09 23:45 ` [PATCH 01/20] dlmfs_file_write(): get rid of pointless access_ok() Al Viro
2020-05-09 23:45   ` [PATCH 02/20] fat_dir_ioctl(): hadn't needed that access_ok() for more than a decade Al Viro
2020-05-09 23:45   ` [PATCH 03/20] btrfs_ioctl_send(): don't bother with access_ok() Al Viro
2020-05-09 23:45   ` [PATCH 04/20] FIEMAP: " Al Viro
2020-05-10  7:02     ` Christoph Hellwig
2020-05-13 19:02       ` Al Viro
2020-05-13 19:38         ` Christoph Hellwig
2020-05-29 15:01           ` Al Viro
2020-05-09 23:45   ` [PATCH 05/20] tomoyo_write_control(): get rid of pointless access_ok() Al Viro
2020-05-10  0:50     ` Tetsuo Handa
2020-05-10  0:57       ` Linus Torvalds
2020-05-10  1:04         ` Tetsuo Handa
2020-05-10  3:01         ` Al Viro
2020-05-09 23:45   ` [PATCH 06/20] n_hdlc_tty_read(): remove " Al Viro
2020-05-15 10:53     ` Greg Kroah-Hartman
2020-05-09 23:45   ` [PATCH 07/20] nvram: drop useless access_ok() Al Viro
2020-05-15 10:54     ` Greg Kroah-Hartman
2020-05-09 23:45   ` [PATCH 08/20] cm4000_cs.c cmm_ioctl(): get rid of pointless access_ok() Al Viro
2020-05-09 23:45   ` [PATCH 09/20] drivers/fpga/dfl-fme-pr.c: " Al Viro
2020-05-09 23:45   ` [PATCH 10/20] drivers/fpga/dfl-afu-dma-region.c: " Al Viro
2020-05-09 23:45   ` [PATCH 11/20] amifb: get rid of pointless access_ok() calls Al Viro
2020-05-14 13:45     ` Bartlomiej Zolnierkiewicz
2020-05-14 14:07       ` Al Viro
2020-05-14 14:25         ` Bartlomiej Zolnierkiewicz [this message]
2020-05-14 17:41           ` Al Viro
2020-05-14 20:21             ` Geert Uytterhoeven
2020-05-09 23:45   ` [PATCH 12/20] omapfb: " Al Viro
2020-05-14 13:39     ` Bartlomiej Zolnierkiewicz
2020-05-09 23:45   ` [PATCH 13/20] drivers/crypto/ccp/sev-dev.c: get rid of pointless access_ok() Al Viro
2020-05-09 23:45   ` [PATCH 14/20] via-pmu: don't bother with access_ok() Al Viro
2020-05-09 23:45   ` [PATCH 15/20] drm_read(): get rid of pointless access_ok() Al Viro
2020-05-09 23:45   ` [PATCH 16/20] efi_test: " Al Viro
2020-05-09 23:45   ` [PATCH 17/20] lpfc_debugfs: " Al Viro
2020-05-09 23:45   ` [PATCH 18/20] usb: get rid of pointless access_ok() calls Al Viro
2020-05-15 10:53     ` Greg Kroah-Hartman
2020-05-09 23:45   ` [PATCH 19/20] hfi1: get rid of pointless access_ok() Al Viro
2020-05-09 23:45   ` [PATCH 4/4] vmci_host: " Al Viro
2020-05-15 10:53     ` Greg Kroah-Hartman
2020-05-10  0:34 ` [PATCHES] uaccess simple access_ok() removals Linus Torvalds
2020-05-10  3:27   ` Al Viro
2020-05-10 14:34 ` David Laight

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=f6fcfa46-6271-45ea-37c2-62bcf0a607cb@samsung.com \
    --to=b.zolnierkie@samsung.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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.