linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arusekk <arek_koz@o2.pl>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Christoph Hellwig <hch@lst.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH v3] proc: Use seq_read_iter for /proc/*/maps
Date: Tue, 04 May 2021 22:23:20 +0200	[thread overview]
Message-ID: <1777114.atdPhlSkOF@swift.dev.arusekk.pl> (raw)
In-Reply-To: <CAHk-=whEjY7eOqPg2Ndw=iM2Mih0BC9LVyX9c6Uc_W=wmwnkkA@mail.gmail.com>

We wtorek, 4 maja 2021 18:01:33 CEST Linus Torvalds pisze:
> it's one of the reasons I didn't feel like doing splice() on
> everything should be encouraged.

This is why I agreed to change only /proc/*/maps.

> The only reason to do this is basically for nefarious purposes,

No real exploit I can think of needs to send this specific file, there are 
better candidates in procfs already.  It only helps inspecting memory mappings 
off-line more reliably than LD_TRACE_LOADED_OBJECTS=1 in as little bytes as 
possible.
Or maybe should it be discouraged on regular ext4 files as well?

> Yes, yes, I'm sure pwntools can be used by white hats, but honestly,
> that seems to be an almost secondary purpose.

You got me.  But honestly, I disagree, I have already seen pwntools used by 
malware analysts and python fans.

> Why should the kernel _encourage_ and make it easy to do things like
> this? What are the actual advantages for us to do this?

Keeping it the way it is for the sake of security of userspace applications 
looks more like security through obscurity to me. 
I still agree that it may increase attack surface of the kernel.  I did not 
try racing misaligned splices, nor mmapping files with strange names.

Pwntools need to be adapted anyway in order to support 5.10-5.13 kernels;
I just thought that this is a kind of a regression in the kernel, so I felt 
obliged to contribute a fix here, especially after I realized how simple the fix 
was.
I heard that patches and their descriptions must really be top quality, but I 
was not prepared for justifying the change with anything more than 'it used to 
work, but is broken now, this patch brings it back'.

-- 
Arusekk



  reply	other threads:[~2021-05-04 20:21 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-27 18:34 [PATCH] proc: Use seq_read_iter where possible Arkadiusz Kozdra (Arusekk)
2021-04-28  6:12 ` Christoph Hellwig
2021-04-28 13:02   ` Arusekk
2021-04-28 13:03     ` Christoph Hellwig
2021-04-28 17:46       ` Linus Torvalds
2021-04-29 10:05         ` [PATCH v2] proc: Use seq_read_iter for /proc/*/maps Arkadiusz Kozdra (Arusekk)
2021-04-29 10:07           ` Greg Kroah-Hartman
2021-05-04 11:53             ` [PATCH v3] " Arkadiusz Kozdra (Arusekk)
2021-05-04 16:01               ` Linus Torvalds
2021-05-04 20:23                 ` Arusekk [this message]
2021-05-04 20:24                   ` Linus Torvalds
2021-04-29 16:36           ` [PATCH v2] " Linus Torvalds

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=1777114.atdPhlSkOF@swift.dev.arusekk.pl \
    --to=arek_koz@o2.pl \
    --cc=adobriyan@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /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).