All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Arnd Bergmann' <arnd@arndb.de>, Mark Rutland <mark.rutland@arm.com>
Cc: Alexandre Ghiti <alex@ghiti.fr>,
	Samuel Holland <samuel.holland@sifive.com>,
	Alexandre Ghiti <alexghiti@rivosinc.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	Albert Ou <aou@eecs.berkeley.edu>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	Charlie Jenkins <charlie@rivosinc.com>,
	guoren <guoren@kernel.org>, Jisheng Zhang <jszhang@kernel.org>,
	Kemeng Shi <shikemeng@huaweicloud.com>,
	Matthew Wilcox <willy@infradead.org>,
	"Mike Rapoport" <rppt@kernel.org>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	"Xiao W Wang" <xiao.w.wang@intel.com>,
	Yangyu Chen <cyy@cyyself.name>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] riscv: Define TASK_SIZE_MAX for __access_ok()
Date: Tue, 26 Mar 2024 10:19:28 +0000	[thread overview]
Message-ID: <882fc86da89f4adb81570cde3a653e6f@AcuMS.aculab.com> (raw)
In-Reply-To: <95eb125d-dd54-42f1-b080-938faca6a8a1@app.fastmail.com>

From: Arnd Bergmann
> Sent: 25 March 2024 20:38
> 
> On Mon, Mar 25, 2024, at 19:30, Mark Rutland wrote:
> > On Mon, Mar 25, 2024 at 07:02:13PM +0100, Arnd Bergmann wrote:
> >> On Mon, Mar 25, 2024, at 17:39, Mark Rutland wrote:
> >
> >> If an architecture ignores all the top bits of a virtual address,
> >> the largest TASK_SIZE would be higher than the smallest (positive,
> >> unsigned) PAGE_OFFSET, so you need TASK_SIZE_MAX to be dynamic.
> >
> > Agreed, but do we even support such architectures within Linux?
> 
> Apparently not.
> 
> On 32-bit architectures, you often have TASK_SIZE==PAGE_OFFSET,
> but not on 64-bit -- either the top few bits in PAGE_OFFSET are
> always ones, or the user and kernel page tables are completely
> separate.

ISTR that arm64 uses (something like) bit 56 to select kernel
with the annoying 'feature' that the high bits can be ignored
just to complicate things.

But I also recall the people that want 'address masking' for x86-64
have been persuaded that addresses with the top bit set are invalid.
I has to be said that I'm not sure that aliasing user addresses
like that is a good idea.
If the TLB/PTE verified the masked bits it might be more use.

If bit63 selects kernel addresses (as in x86-64) there is a massive
(non-canonical address) gap before the first valid kernel address
that is larger than the user address space (and hence buffer size).
I think that lets access_ok() check ((address | size) >> 60) != 0.
Although it probably means that you don't need to test 'size' at all
(unless some code probes the last byte of the buffer).

For 32bit the user/kernel boundary is usually 0x80000000 or 0xc0000000
and there may not even be an invalid page between the two.
This does require access_ok() check the length (even for get_user()).

	David

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


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: David Laight <David.Laight@ACULAB.COM>
To: 'Arnd Bergmann' <arnd@arndb.de>, Mark Rutland <mark.rutland@arm.com>
Cc: Alexandre Ghiti <alex@ghiti.fr>,
	Samuel Holland <samuel.holland@sifive.com>,
	Alexandre Ghiti <alexghiti@rivosinc.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	Albert Ou <aou@eecs.berkeley.edu>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	Charlie Jenkins <charlie@rivosinc.com>,
	guoren <guoren@kernel.org>, Jisheng Zhang <jszhang@kernel.org>,
	Kemeng Shi <shikemeng@huaweicloud.com>,
	Matthew Wilcox <willy@infradead.org>,
	"Mike Rapoport" <rppt@kernel.org>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	"Xiao W Wang" <xiao.w.wang@intel.com>,
	Yangyu Chen <cyy@cyyself.name>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] riscv: Define TASK_SIZE_MAX for __access_ok()
Date: Tue, 26 Mar 2024 10:19:28 +0000	[thread overview]
Message-ID: <882fc86da89f4adb81570cde3a653e6f@AcuMS.aculab.com> (raw)
In-Reply-To: <95eb125d-dd54-42f1-b080-938faca6a8a1@app.fastmail.com>

From: Arnd Bergmann
> Sent: 25 March 2024 20:38
> 
> On Mon, Mar 25, 2024, at 19:30, Mark Rutland wrote:
> > On Mon, Mar 25, 2024 at 07:02:13PM +0100, Arnd Bergmann wrote:
> >> On Mon, Mar 25, 2024, at 17:39, Mark Rutland wrote:
> >
> >> If an architecture ignores all the top bits of a virtual address,
> >> the largest TASK_SIZE would be higher than the smallest (positive,
> >> unsigned) PAGE_OFFSET, so you need TASK_SIZE_MAX to be dynamic.
> >
> > Agreed, but do we even support such architectures within Linux?
> 
> Apparently not.
> 
> On 32-bit architectures, you often have TASK_SIZE==PAGE_OFFSET,
> but not on 64-bit -- either the top few bits in PAGE_OFFSET are
> always ones, or the user and kernel page tables are completely
> separate.

ISTR that arm64 uses (something like) bit 56 to select kernel
with the annoying 'feature' that the high bits can be ignored
just to complicate things.

But I also recall the people that want 'address masking' for x86-64
have been persuaded that addresses with the top bit set are invalid.
I has to be said that I'm not sure that aliasing user addresses
like that is a good idea.
If the TLB/PTE verified the masked bits it might be more use.

If bit63 selects kernel addresses (as in x86-64) there is a massive
(non-canonical address) gap before the first valid kernel address
that is larger than the user address space (and hence buffer size).
I think that lets access_ok() check ((address | size) >> 60) != 0.
Although it probably means that you don't need to test 'size' at all
(unless some code probes the last byte of the buffer).

For 32bit the user/kernel boundary is usually 0x80000000 or 0xc0000000
and there may not even be an invalid page between the two.
This does require access_ok() check the length (even for get_user()).

	David

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


  reply	other threads:[~2024-03-26 10:20 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-13 17:59 [PATCH] riscv: Define TASK_SIZE_MAX for __access_ok() Samuel Holland
2024-03-13 17:59 ` Samuel Holland
2024-03-18 20:50 ` Alexandre Ghiti
2024-03-18 20:50   ` Alexandre Ghiti
2024-03-18 21:29   ` Samuel Holland
2024-03-18 21:29     ` Samuel Holland
2024-03-19 16:51     ` Alexandre Ghiti
2024-03-19 16:51       ` Alexandre Ghiti
2024-03-24 19:42       ` David Laight
2024-03-24 19:42         ` David Laight
2024-03-25  7:30         ` Alexandre Ghiti
2024-03-25  7:30           ` Alexandre Ghiti
2024-03-25  9:30           ` David Laight
2024-03-25  9:30             ` David Laight
2024-03-25 16:39           ` Mark Rutland
2024-03-25 16:39             ` Mark Rutland
2024-03-25 18:02             ` Arnd Bergmann
2024-03-25 18:02               ` Arnd Bergmann
2024-03-25 18:30               ` Mark Rutland
2024-03-25 18:30                 ` Mark Rutland
2024-03-25 19:20                 ` Samuel Holland
2024-03-25 19:20                   ` Samuel Holland
2024-03-25 20:38                 ` Arnd Bergmann
2024-03-25 20:38                   ` Arnd Bergmann
2024-03-26 10:19                   ` David Laight [this message]
2024-03-26 10:19                     ` David Laight
2024-03-26 14:49                     ` Mark Rutland
2024-03-26 14:49                       ` Mark Rutland
2024-03-25 20:12             ` Alexandre Ghiti
2024-03-25 20:12               ` Alexandre Ghiti
2024-03-24 22:05       ` Arnd Bergmann
2024-03-24 22:05         ` Arnd Bergmann
2024-03-25  7:25         ` Alexandre Ghiti
2024-03-25  7:25           ` Alexandre Ghiti
2024-03-25 11:15           ` Arnd Bergmann
2024-03-25 11:15             ` Arnd Bergmann
2024-03-25 20:40 ` Arnd Bergmann
2024-03-25 20:40   ` 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=882fc86da89f4adb81570cde3a653e6f@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex@ghiti.fr \
    --cc=alexghiti@rivosinc.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=arnd@arndb.de \
    --cc=charlie@rivosinc.com \
    --cc=cyy@cyyself.name \
    --cc=guoren@kernel.org \
    --cc=jszhang@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=rppt@kernel.org \
    --cc=samuel.holland@sifive.com \
    --cc=shikemeng@huaweicloud.com \
    --cc=willy@infradead.org \
    --cc=xiao.w.wang@intel.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 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.