From: David Laight <David.Laight@ACULAB.COM>
To: 'Christoph Hellwig' <hch@lst.de>, Miles Chen <miles.chen@mediatek.com>
Cc: "David S . Miller" <davem@davemloft.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mediatek@lists.infradead.org"
<linux-mediatek@lists.infradead.org>,
"wsd_upstream@mediatek.com" <wsd_upstream@mediatek.com>
Subject: RE: [PATCH] net: untag pointer in sockptr_is_kernel
Date: Tue, 11 Aug 2020 11:44:59 +0000 [thread overview]
Message-ID: <36e381c558e24185bc2f7e80a758d06a@AcuMS.aculab.com> (raw)
In-Reply-To: <20200811111551.GA3958@lst.de>
> On Tue, Aug 11, 2020 at 06:27:04PM +0800, Miles Chen wrote:
> > From: Miles Chen <miles.chen@mediatek.com>
> >
> > sockptr_is_kernel() uses (sockptr.kernel >= TASK_SIZE) to tell
> > if the pointer is kernel space or user space. When user space uses
> > the "top byte ignored" feature such as HWAsan, we must untag
> > the pointer before checking against TASK_SIZE.
> >
> > sockptr_is_kernel() will view a tagged user pointer as a kernel pointer
> > and use memcpy directly and causes a kernel crash.
>
> Dave merged a patch from me to rever the optimized sockptr
> implementation for now. If we bring it back we should fold in your
> fix.
I missed that going though :-(
I've looked for a fix to the access_ok(kernel_addr,0) being true issue.
Shouldn't TASK_SIZE be increased to cover all the 'tagged' addresses?
ISTR the 'tag' bits are the 'next' 8 (or so) address bits at the top
of valid user addresses.
Then presumably the user-copies would be able to use the tagged
address values getting whatever protection that gives.
ISTM that for kernel-user boundary checks TASK_SIZE is the
wrong constant.
(The upper limit for mmap() is entirely different.)
The limit should be independent of whether the process is 32 or 64bit
(any fault above 4G will fail to find a user-page for 32bit).
The limit can also go well into the address 'black hole' that
exists on x86-x64 (and similar) between valid user and kernel
addresses - handling the relevant trap should be too hard
(it is always an error, so need not be fast).
So with set_fs(KERNEL_DS) gone x86-x64 can (almost certainly)
do a cheap test for (long)addr >= 0 in access_ok() (+ length test).
While set_fs() is needed it can be:
((long)addr & current->mask) >= 0
(masking off the top bit if kernel addresses are valid).
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2020-08-11 11:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-11 10:27 [PATCH] net: untag pointer in sockptr_is_kernel Miles Chen
2020-08-11 11:15 ` Christoph Hellwig
2020-08-11 11:44 ` David Laight [this message]
2020-08-12 9:15 ` Miles Chen
2020-08-12 9:48 ` David Laight
2020-08-11 12:24 ` kernel test robot
2020-08-11 12:28 ` kernel test robot
2020-08-12 9:17 ` Miles Chen
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=36e381c558e24185bc2f7e80a758d06a@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=davem@davemloft.net \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=miles.chen@mediatek.com \
--cc=wsd_upstream@mediatek.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