linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Linus Torvalds' <torvalds@linux-foundation.org>
Cc: "Kirill A. Shutemov" <kirill@shutemov.name>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Andy Lutomirski <luto@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	"x86@kernel.org" <x86@kernel.org>,
	Kostya Serebryany <kcc@google.com>,
	"Andrey Ryabinin" <ryabinin.a.a@gmail.com>,
	Andrey Konovalov <andreyknvl@gmail.com>,
	Alexander Potapenko <glider@google.com>,
	Taras Madan <tarasmadan@google.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	"H . J . Lu" <hjl.tools@gmail.com>,
	"Andi Kleen" <ak@linux.intel.com>,
	Rick Edgecombe <rick.p.edgecombe@intel.com>,
	Bharata B Rao <bharata@amd.com>,
	Jacob Pan <jacob.jun.pan@linux.intel.com>,
	Ashok Raj <ashok.raj@intel.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCHv13 05/16] x86/uaccess: Provide untagged_addr() and remove tags before address check
Date: Tue, 3 Jan 2023 08:37:46 +0000	[thread overview]
Message-ID: <35b24dab4dc5451a86ef87f93088e0b7@AcuMS.aculab.com> (raw)
In-Reply-To: <CAHk-=wgh9zNsFX0gSfMBfJBxOOTztsZ6NZc5pvzCikB1Gz8B3A@mail.gmail.com>

From: Linus Torvalds
> Sent: 02 January 2023 19:05
...
> > Are byte loads guaranteed to fault?
> 
> Yeah, we don't map the highest address on x86-64. And we don't want to
> in the future either, because of how our error pointers work (ie if
> somebody misses an "IS_ERR()" check and uses an error pointer as a
> pointer, we want that to fault, rather than do random things).
> 
> It's not a hard requirement architecturally (either hardware or
> software), and iirc on 32-bit we used to use the last virtual page for
> something, so maybe I'm missing some odd use on 64-bit too, but
> accessing the top-of-virtual address space on x86-64 should always
> cause a clear fault afaik.
> 
> A byte access would always be a page fault, while a wrapping access
> might trigger a GP fault first (probably not - on 32-bit it would be a
> segment size violation, on 64-bit we've left those bad old days behind
> and I don't think wrapping matters either)

For some reason I was thinking you were relying on the wrapping access.

The other check is access_ok() for longer copies.
If you make the assumption that the copy is 'reasonably sequential'
then the length can be ignored provided that the bottom of 'kernel
space' is unmapped.
For x86-64 treating -ve values as kernel that is pretty true.
32-bit would need at least one unmapped page between user and kernel.
I suspect the kernel is loaded at 0xc0000000 making that difficult.

	David

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

  reply	other threads:[~2023-01-03  8:37 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-27  3:08 [PATCHv13 00/16] Linear Address Masking enabling Kirill A. Shutemov
2022-12-27  3:08 ` [PATCHv13 01/16] x86: Allow atomic MM_CONTEXT flags setting Kirill A. Shutemov
2023-01-04 19:07   ` Dave Hansen
2022-12-27  3:08 ` [PATCHv13 02/16] x86: CPUID and CR3/CR4 flags for Linear Address Masking Kirill A. Shutemov
2022-12-27  3:08 ` [PATCHv13 03/16] x86/mm: Handle LAM on context switch Kirill A. Shutemov
2022-12-27  3:08 ` [PATCHv13 04/16] mm: Introduce untagged_addr_remote() Kirill A. Shutemov
2022-12-27  3:08 ` [PATCHv13 05/16] x86/uaccess: Provide untagged_addr() and remove tags before address check Kirill A. Shutemov
2022-12-27 19:10   ` Linus Torvalds
2022-12-31  0:10     ` Kirill A. Shutemov
2022-12-31  0:42       ` Linus Torvalds
2023-01-02 13:55         ` David Laight
2023-01-02 19:05           ` Linus Torvalds
2023-01-03  8:37             ` David Laight [this message]
2023-01-07  9:10         ` Kirill A. Shutemov
2023-01-07 17:28           ` Linus Torvalds
2022-12-27  3:08 ` [PATCHv13 06/16] x86/mm: Provide arch_prctl() interface for LAM Kirill A. Shutemov
2023-01-04 19:55   ` Edgecombe, Rick P
2023-01-10  6:17     ` Kirill A. Shutemov
2022-12-27  3:08 ` [PATCHv13 07/16] x86/mm: Reduce untagged_addr() overhead until the first LAM user Kirill A. Shutemov
2022-12-27  3:08 ` [PATCHv13 08/16] mm: Expose untagging mask in /proc/$PID/status Kirill A. Shutemov
2022-12-27  3:08 ` [PATCHv13 09/16] iommu/sva: Replace pasid_valid() helper with mm_valid_pasid() Kirill A. Shutemov
2022-12-27  3:08 ` [PATCHv13 10/16] x86/mm/iommu/sva: Make LAM and SVA mutually exclusive Kirill A. Shutemov
2022-12-27  3:08 ` [PATCHv13 11/16] selftests/x86/lam: Add malloc and tag-bits test cases for linear-address masking Kirill A. Shutemov
2022-12-27  3:08 ` [PATCHv13 12/16] selftests/x86/lam: Add mmap and SYSCALL " Kirill A. Shutemov
2022-12-27  3:08 ` [PATCHv13 13/16] selftests/x86/lam: Add io_uring " Kirill A. Shutemov
2022-12-27  3:08 ` [PATCHv13 14/16] selftests/x86/lam: Add inherit " Kirill A. Shutemov
2022-12-27  3:08 ` [PATCHv13 15/16] selftests/x86/lam: Add ARCH_FORCE_TAGGED_SVA " Kirill A. Shutemov
2022-12-27  3:08 ` [PATCHv13 16/16] selftests/x86/lam: Add test cases for LAM vs thread creation Kirill A. Shutemov

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=35b24dab4dc5451a86ef87f93088e0b7@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=ak@linux.intel.com \
    --cc=andreyknvl@gmail.com \
    --cc=ashok.raj@intel.com \
    --cc=bharata@amd.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=hjl.tools@gmail.com \
    --cc=jacob.jun.pan@linux.intel.com \
    --cc=kcc@google.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rick.p.edgecombe@intel.com \
    --cc=ryabinin.a.a@gmail.com \
    --cc=tarasmadan@google.com \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /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