From: David Laight <David.Laight@ACULAB.COM>
To: 'Thomas Gleixner' <tglx@linutronix.de>, Jann Horn <jannh@google.com>
Cc: Andrei Vagin <avagin@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 2/2] time/namespace: Forbid timens page faults under kthread_use_mm()
Date: Wed, 30 Nov 2022 22:48:11 +0000 [thread overview]
Message-ID: <1c767e89dcf8475f90d2d817b9096a55@AcuMS.aculab.com> (raw)
In-Reply-To: <87y1rttid2.ffs@tglx>
From: Thomas Gleixner
> Sent: 30 November 2022 00:08
....
> >> None of those VDSO (user space) addresses are subject to be faulted in
> >> by anything else than the associated user space task(s).
> >
> > Are you saying that it's not possible or that it doesn't happen when
> > userspace is well-behaved?
>
> My subconcious self told me that a kthread won't do that unless it's
> buggered which makes the vdso fault path the least of our problems, but
> thinking more about it: You are right, that there are ways that the
> kthread ends up with a vdso page address.... Bah!
>
> Still my point stands that this is not a timens VDSO issue, but an issue
> of: kthread tries to fault in a VDSO page of whatever nature.
Isn't there also the kernel code path where one user thread
reads data from another processes address space.
(It does some unusual calls to the iov_import() functions.)
I can't remember whether it is used by strace or gdb.
But there is certainly the option of getting to access
an 'invalid' address in the other process and then faulting.
ISTR not being convinced that there was a correct check
for user/kernel addresses in it either.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2022-11-30 22:48 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-29 19:18 [PATCH 1/2] time/namespace: Refactor copy-pasted helper into one copy Jann Horn
2022-11-29 19:18 ` [PATCH 2/2] time/namespace: Forbid timens page faults under kthread_use_mm() Jann Horn
2022-11-29 21:18 ` Thomas Gleixner
2022-11-29 22:28 ` Jann Horn
2022-11-29 22:34 ` Jann Horn
2022-11-30 0:09 ` Thomas Gleixner
2022-11-30 0:07 ` Thomas Gleixner
2022-11-30 22:48 ` David Laight [this message]
2022-12-01 9:31 ` Jann Horn
2022-11-30 10:15 ` [PATCH 1/2] time/namespace: Refactor copy-pasted helper into one copy Jann Horn
2022-11-30 10:57 ` Thomas Gleixner
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=1c767e89dcf8475f90d2d817b9096a55@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=avagin@gmail.com \
--cc=jannh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
/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
all inboxes | Powered by JetHome®