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
next prev parent reply other threads:[~2024-03-26 10:20 UTC|newest]
Thread overview: 19+ 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-18 20:50 ` Alexandre Ghiti
2024-03-18 21:29 ` Samuel Holland
2024-03-19 16:51 ` Alexandre Ghiti
2024-03-24 19:42 ` David Laight
2024-03-25 7:30 ` Alexandre Ghiti
2024-03-25 9:30 ` David Laight
2024-03-25 16:39 ` Mark Rutland
2024-03-25 18:02 ` Arnd Bergmann
2024-03-25 18:30 ` Mark Rutland
2024-03-25 19:20 ` Samuel Holland
2024-03-25 20:38 ` Arnd Bergmann
2024-03-26 10:19 ` David Laight [this message]
2024-03-26 14:49 ` Mark Rutland
2024-03-25 20:12 ` Alexandre Ghiti
2024-03-24 22:05 ` Arnd Bergmann
2024-03-25 7:25 ` Alexandre Ghiti
2024-03-25 11:15 ` 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox