mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Arnd Bergmann' <arnd@kernel.org>
Cc: Michal Simek <monstr@monstr.eu>,
	Christoph Hellwig <hch@infradead.org>,
	Arnd Bergmann <arnd@arndb.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] microblaze: remove CONFIG_SET_FS
Date: Thu, 10 Feb 2022 14:21:07 +0000	[thread overview]
Message-ID: <cc2a0d0eb77b4ace872263db7bf0c115@AcuMS.aculab.com> (raw)
In-Reply-To: <CAK8P3a3tZEc30AaiNENbHKf8+x5VOw7Q=4dVDMNwz0F6+v9YrQ@mail.gmail.com>

From: Arnd Bergmann
> Sent: 10 February 2022 13:30
...
> #define __access_ok(addr, size) \
>         ((get_fs().seg == KERNEL_DS.seg) || \
>         (((unsigned long)addr < get_fs().seg) && \
>           (unsigned long)size < (get_fs().seg - (unsigned long)addr)))

That one is strange.
Seems to be optimised for kernel accesses!

> ia64 and sparc skip the size check entirely but rely on an unmapped page
> at the beginning of the kernel address range, which avoids this problem
> but may also be dangerous.

An unmapped page requires that the kernel do sequential accesses
(or, at least, not big offset) - which is normally fine.
Especially for 64bit where there is plenty of address space.
I guess it could be problematic for 32bit if you can/want to
use 'big pages' for the kernel addresses.
Losing a single (typically) 4k page isn't a problem.

Certainly not mapping the page at TASK_SIZE is a good safety check.
Actually, setting TASK_SIZE to 0xc0000000 - PAGE_SIZE and never
mapping the last user page has the same effect.
Except I bet the ldso has to go there :-(
Not to mention the instruction sets where loading the constant
would then be two instructions.

...
> > Although typical 64bit architectures can use the faster:
> >         ((addr | size) >> 62)
> 
> I think this is the best version, and it's already widely used:

I just did a quick check, both clang and gcc optimise out
constant values for 'size'.

> static inline int __range_ok(unsigned long addr, unsigned long size)
> {
>         return size <= TASK_SIZE && addr <= (TASK_SIZE - size);
> }
> 
> since 'size' is usually constant, so this turns into a single comparison
> against a compile-time constant.

Hmmm... maybe there should be a comment that it is the same as
the more obvious:
	(addr <= TASK_SIZE && addr <= TASK_SIZE - size)
but is better for constant size.
(Provided TASK_SIZE is a constant.)

I'm sure Linus was 'unhappy' about checking against 2^63 for
32bit processes on a 64bit kernel.

Hmmm compat code that has 32bit addr/size needn't even call
access_ok() - it can never access kernel memory at all.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

  reply	other threads:[~2022-02-10 14:21 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-09 14:48 Arnd Bergmann
2022-02-10  9:36 ` David Laight
2022-02-10 13:29   ` Arnd Bergmann
2022-02-10 14:21     ` David Laight [this message]
2022-02-10 14:53       ` Arnd Bergmann
2022-02-10 22:23       ` Stafford Horne
  -- strict thread matches above, loose matches on Subject: below --
2022-01-17 13:24 [PATCH 03/10] exit: Move oops specific logic from do_exit into make_task_dead Arnd Bergmann
2022-01-17 13:27 ` [PATCH] microblaze: remove CONFIG_SET_FS Arnd Bergmann
2022-02-09 13:50   ` Michal Simek
2022-02-09 13:52     ` Christoph Hellwig
2022-02-09 14:03       ` Michal Simek
2022-02-09 14:40     ` Arnd Bergmann
2022-02-09 14:44       ` Michal Simek
2022-02-09 14:54         ` Arnd Bergmann
2022-02-09 23:31           ` Stafford Horne
2022-02-11  0:17             ` Stafford Horne
2022-02-11 16:59               ` Arnd Bergmann
2022-02-11 17:46                 ` Linus Torvalds
2022-02-11 20:57                   ` Arnd Bergmann
2022-02-11 21:10                     ` Eric W. Biederman
2022-02-11 22:21                       ` Stafford Horne
2022-02-14  7:41                   ` Christoph Hellwig
2022-02-14  7:50                 ` Christoph Hellwig
2022-02-14 16:20                   ` Arnd Bergmann

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=cc2a0d0eb77b4ace872263db7bf0c115@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=arnd@arndb.de \
    --cc=arnd@kernel.org \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=monstr@monstr.eu \
    /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

Powered by JetHome