From: Al Viro <[email protected]>
To: David Laight <[email protected]>
Cc: 'Christoph Hellwig' <[email protected]>,
Andrew Morton <[email protected]>,
Jens Axboe <[email protected]>, Arnd Bergmann <[email protected]>,
David Howells <[email protected]>,
"[email protected]"
<[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]"
<[email protected]>
Subject: Re: [PATCH 04/11] iov_iter: explicitly check for CHECK_IOVEC_ONLY in rw_copy_check_uvector
Date: Mon, 21 Sep 2020 16:11:19 +0100 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
On Mon, Sep 21, 2020 at 03:05:32PM +0000, David Laight wrote:
> I've actually no idea:
> 1) Why there is an access_ok() check here.
> It will be repeated by the user copy functions.
Early sanity check.
> 2) Why it isn't done when called from mm/process_vm_access.c.
> Ok, the addresses refer to a different process, but they
> must still be valid user addresses.
>
> Is 2 a legacy from when access_ok() actually checked that the
> addresses were mapped into the process's address space?
It never did. 2 is for the situation when a 32bit process
accesses 64bit one; addresses that are perfectly legitimate
for 64bit userland (and fitting into the first 4Gb of address
space, so they can be represented by 32bit pointers just fine)
might be rejected by access_ok() if the caller is 32bit.
next prev parent reply other threads:[~2020-09-21 15:11 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-21 14:34 let import_iovec deal with compat_iovecs as well v2 Christoph Hellwig
2020-09-21 14:34 ` [PATCH 01/11] compat.h: fix a spelling error in <linux/compat.h> Christoph Hellwig
2020-09-21 14:34 ` [PATCH 02/11] mm: call import_iovec() instead of rw_copy_check_uvector() in process_vm_rw() Christoph Hellwig
2020-09-21 14:48 ` Matthew Wilcox
2020-09-21 15:02 ` Al Viro
2020-09-21 15:21 ` David Laight
2020-09-21 15:29 ` Al Viro
2020-09-21 15:44 ` David Laight
2020-09-21 16:27 ` Al Viro
2020-09-21 16:12 ` Christoph Hellwig
2020-09-21 14:34 ` [PATCH 03/11] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c and mark it static Christoph Hellwig
2020-09-21 14:34 ` [PATCH 04/11] iov_iter: explicitly check for CHECK_IOVEC_ONLY in rw_copy_check_uvector Christoph Hellwig
2020-09-21 15:05 ` David Laight
2020-09-21 15:11 ` Al Viro [this message]
2020-09-21 15:26 ` David Laight
2020-09-21 15:07 ` Al Viro
2020-09-21 14:34 ` [PATCH 05/11] iov_iter: merge the compat case into rw_copy_check_uvector Christoph Hellwig
2020-09-21 15:14 ` Al Viro
2021-01-08 11:49 ` David Laight
2020-09-21 14:34 ` [PATCH 06/11] iov_iter: handle the compat case in import_iovec Christoph Hellwig
2020-09-21 15:20 ` Al Viro
2020-09-21 14:34 ` [PATCH 07/11] fs: remove various compat readv/writev helpers Christoph Hellwig
2020-09-21 14:34 ` [PATCH 08/11] fs: remove the compat readv/writev syscalls Christoph Hellwig
2020-09-21 14:34 ` [PATCH 09/11] fs: remove compat_sys_vmsplice Christoph Hellwig
2020-09-21 14:34 ` [PATCH 10/11] mm: remove compat_process_vm_{readv,writev} Christoph Hellwig
2020-09-21 14:34 ` [PATCH 11/11] security/keys: remove compat_keyctl_instantiate_key_iov Christoph Hellwig
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 \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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