All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Kees Cook <keescook@chromium.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andy Lutomirski <luto@amacapital.net>,
	Dmitry Vyukov <dvyukov@google.com>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@alien8.de>,
	Denys Vlasenko <dvlasenk@redhat.com>,
	"x86@kernel.org" <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Kostya Serebryany <kcc@google.com>,
	Alexander Potapenko <glider@google.com>,
	Andrey Konovalov <andreyknvl@google.com>,
	Sasha Levin <sasha.levin@oracle.com>,
	Andi Kleen <ak@linux.intel.com>,
	kasan-dev <kasan-dev@googlegroups.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Andrew Morton <akpm@linux-foundation.org>,
	Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH v3] fs/proc, core/debug: Don't expose absolute kernel addresses via wchan
Date: Thu, 1 Oct 2015 11:29:14 +0200	[thread overview]
Message-ID: <20151001092914.GC6543@gmail.com> (raw)
In-Reply-To: <CAPAsAGyR8EqT5riJmRPQF-Zh8+POyjYCi4skVDmmexL5oYiexQ@mail.gmail.com>


* Andrey Ryabinin <ryabinin.a.a@gmail.com> wrote:

> 2015-10-01 10:57 GMT+03:00 Ingo Molnar <mingo@kernel.org>:
> > diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
> > index d411ca63c8b6..db64f7d6492d 100644
> > --- a/Documentation/filesystems/proc.txt
> > +++ b/Documentation/filesystems/proc.txt
> > @@ -140,7 +140,8 @@ Table 1-1: Process specific entries in /proc
> >   stat          Process status
> >   statm         Process memory status information
> >   status                Process status in human readable form
> > - wchan         If CONFIG_KALLSYMS is set, a pre-decoded wchan
> > + wchan         If CONFIG_KALLSYMS=y, wchan (the kernel function the process is
> > +               blocked in) symbol string. "0" if not blocked or !KALLSYMS.
> 
> /proc/PID/wchan is under #ifdef CONFIG_KALLSYMS.

Yeah, indeed, so I clarified that text to now read:

+ wchan         Present with CONFIG_KALLSYMS=y: it shows the kernel function
+               symbol the task is blocked in - or "0" if not blocked.

> > diff --git a/fs/proc/base.c b/fs/proc/base.c
> > index b25eee4cead5..6f05aabce3aa 100644
> > --- a/fs/proc/base.c
> > +++ b/fs/proc/base.c
> > @@ -430,13 +430,10 @@ static int proc_pid_wchan(struct seq_file *m, struct pid_namespace *ns,
> >
> >         wchan = get_wchan(task);
> >
> > -       if (lookup_symbol_name(wchan, symname) < 0) {
> > -               if (!ptrace_may_access(task, PTRACE_MODE_READ))
> > -                       return 0;
> > -               seq_printf(m, "%lu", wchan);
> > -       } else {
> > +       if (!lookup_symbol_name(wchan, symname))
> >                 seq_printf(m, "%s", symname);
> > -       }
> > +       else
> > +               seq_putc(m, '0');
> 
> Maybe we should respect 'kptr_restrict' sysctl when we use '%ps', '%pB' etc. 
> printk formats (AFAIK %ps just prints address if KALLSYMS=n, or lookup failed). 
> In that case you could just do 'seq_printf(m, "%ps", wchan)'.
> 
> OTOH, %ps, %pS are used mostly in debugging, so investigating some crash in 
> production kernel with no !KALLSYMS and with kptr_restrict != 0 will be a 
> nightmare.

So this code does not use %pX, it prints the symbol. Yes, the symbol in itself is 
'information' about the execution of the task in itself - but /proc per se is all 
about providing information about tasks in the system (including to unprivileged 
users), so there's IMHO little point in restricting this output any further ...

I think ktrp_restrict is mostly about not exposing absolute addresses.

Thanks,

	Ingo

  reply	other threads:[~2015-10-01  9:29 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-28  9:00 [PATCH] arch/x86: fix out-of-bounds in get_wchan() Dmitry Vyukov
2015-09-28  9:37 ` Borislav Petkov
2015-09-28  9:49   ` Dmitry Vyukov
2015-09-28 10:23     ` Borislav Petkov
2015-09-28 10:33       ` Dmitry Vyukov
2015-09-28 10:51         ` Borislav Petkov
2015-09-28  9:54   ` Dmitry Vyukov
2015-09-28 10:32     ` Borislav Petkov
2015-09-28 15:40 ` Andrey Ryabinin
2015-09-28 16:08   ` Dmitry Vyukov
2015-09-28 16:32     ` Thomas Gleixner
2015-09-29 18:15       ` Andy Lutomirski
2015-09-29 18:30         ` Andy Lutomirski
2015-09-29 18:41           ` Borislav Petkov
2015-09-30  7:15         ` [PATCH] fs/proc: Don't expose absolute kernel addresses via wchan Ingo Molnar
2015-09-30  7:35           ` Thomas Gleixner
2015-09-30 13:59             ` [PATCH v2] " Ingo Molnar
2015-09-30 20:36               ` Thomas Gleixner
2015-09-30 21:21               ` Kees Cook
2015-09-30 21:38                 ` Thomas Gleixner
2015-10-01  7:57                 ` [PATCH v3] fs/proc, core/debug: " Ingo Molnar
2015-10-01  8:57                   ` Andrey Ryabinin
2015-10-01  9:29                     ` Ingo Molnar [this message]
2015-10-01 10:16                       ` Andrey Ryabinin
2015-10-01 10:39                         ` Ingo Molnar
2015-10-01 10:47                           ` Andrey Ryabinin
2015-10-01 10:57                             ` [PATCH v5] " Ingo Molnar
2015-10-01  9:37                   ` [PATCH v4] " Ingo Molnar
2015-10-01 12:49               ` [tip:core/debug] fs/proc, core/debug: Don' t " tip-bot for Ingo Molnar
2015-09-30  8:07         ` [PATCH] arch/x86: fix out-of-bounds in get_wchan() 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=20151001092914.GC6543@gmail.com \
    --to=mingo@kernel.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@google.com \
    --cc=bp@alien8.de \
    --cc=dvlasenk@redhat.com \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=hpa@zytor.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=kcc@google.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=ryabinin.a.a@gmail.com \
    --cc=sasha.levin@oracle.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    --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 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.