linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Petr Mladek <pmladek@suse.com>
Cc: Timur Tabi <timur@kernel.org>, Kees Cook <keescook@chromium.org>,
	Matthew Wilcox <willy@infradead.org>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	roman.fietze@magna.com, Steven Rostedt <rostedt@goodmis.org>,
	John Ogness <john.ogness@linutronix.de>,
	Linux-MM <linux-mm@kvack.org>,
	Akinobu Mita <akinobu.mita@gmail.com>
Subject: Re: [PATCH 0/2] introduce DUMP_PREFIX_UNHASHED for hex dumps
Date: Wed, 20 Jan 2021 11:39:49 -0800	[thread overview]
Message-ID: <CAHk-=wjnEV2E6vCRxv5S5m27iOjHeVWNbfK=JV8qxot4Do-FgA@mail.gmail.com> (raw)
In-Reply-To: <YAf1lS8zsHwhShCr@alley>

On Wed, Jan 20, 2021 at 1:19 AM Petr Mladek <pmladek@suse.com> wrote:
>
> And we should definitely add Linus into CC when sending v2.
> His expected opinion has been mentioned several times in this
> thread. It would be better to avoid these speculations
> and get his real opinion. IMHO, it is too late to add
> him in this long thread.

I've seen it, I've just not cared deeply.

I suspect the main issue is if you can cause debug dumps as a normal
user and find kernel addresses that way, but I'm not sure how much we
care. Somebody _actively_ debugging things might need the address, and
KASRL etc be damned.

I also suspect that everybody has already accepted that KASLR isn't
really working locally anyway (due to all the hw leak models with
cache and TLB timing), so anybody who can look at kernel messages
already probably could figure most of those things out.

So as long as the dumping isn't doing something actively stupid, and
as long as hex dumping isn't something that is easily triggered, this
probably falls under "nobody cares".

             Linus

  parent reply	other threads:[~2021-01-20 19:46 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-16 22:09 [PATCH 0/2] introduce DUMP_PREFIX_UNHASHED for hex dumps Timur Tabi
2021-01-16 22:09 ` [PATCH 1/2] [v2] lib/hexdump: introduce DUMP_PREFIX_UNHASHED for unhashed addresses Timur Tabi
2021-01-18 10:03   ` Andy Shevchenko
2021-01-18 15:57     ` Timur Tabi
2021-01-18 17:14       ` Andy Shevchenko
2021-01-18 17:53         ` Timur Tabi
2021-01-16 22:09 ` [PATCH 2/2] mm/page_poison: use unhashed address in hexdump for check_poison_mem() Timur Tabi
2021-01-18 18:26 ` [PATCH 0/2] introduce DUMP_PREFIX_UNHASHED for hex dumps Matthew Wilcox
2021-01-18 19:03   ` Timur Tabi
2021-01-19  0:53     ` Sergey Senozhatsky
2021-01-19  1:47       ` Matthew Wilcox
2021-01-19 10:38         ` Sergey Senozhatsky
2021-01-19 19:45           ` Kees Cook
2021-01-26 16:47           ` Vlastimil Babka
2021-01-26 16:59             ` Timur Tabi
2021-01-26 17:14               ` Steven Rostedt
2021-01-26 17:14               ` Vlastimil Babka
2021-01-26 17:30                 ` Timur Tabi
2021-01-26 17:39                   ` Steven Rostedt
2021-01-26 17:40                     ` Steven Rostedt
2021-01-26 19:23                       ` John Ogness
2021-01-27  2:11                         ` Sergey Senozhatsky
2021-01-27  3:22                           ` Timur Tabi
2021-01-27 10:11                       ` Petr Mladek
2021-01-27 10:38                         ` Vlastimil Babka
2021-01-19 19:45         ` Kees Cook
2021-01-19 19:55           ` Timur Tabi
2021-01-19 20:10             ` Steven Rostedt
2021-01-19 20:49               ` Timur Tabi
2021-01-19 21:15                 ` Steven Rostedt
2021-01-19 21:25                   ` Timur Tabi
2021-01-20  9:19             ` Petr Mladek
2021-01-20 12:17               ` Matthew Wilcox
2021-01-20 19:39               ` Linus Torvalds [this message]
2021-01-19 20:18           ` Randy Dunlap
2021-01-20 20:28             ` Kees Cook
2021-01-19  2:30       ` Timur Tabi

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='CAHk-=wjnEV2E6vCRxv5S5m27iOjHeVWNbfK=JV8qxot4Do-FgA@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=akinobu.mita@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=john.ogness@linutronix.de \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=pmladek@suse.com \
    --cc=roman.fietze@magna.com \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=timur@kernel.org \
    --cc=willy@infradead.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;
as well as URLs for NNTP newsgroup(s).