All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Tobin Harding <me@tobin.cc>
Cc: Tycho Andersen <tycho@tycho.pizza>,
	Greg KH <gregkh@linuxfoundation.org>,
	Guixiong Wei <guixiongwei@gmail.com>,
	linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] leaking_addresses: Provide mechanism to scan binary files
Date: Wed, 28 Feb 2024 21:30:06 -0800	[thread overview]
Message-ID: <202402282048.0CA1A50@keescook> (raw)
In-Reply-To: <ZeAKrU9IfcNpIURB@alke>

On Thu, Feb 29, 2024 at 03:40:13PM +1100, Tobin Harding wrote:
> On Thu, Feb 22, 2024 at 04:49:26PM -0700, Tycho Andersen wrote:
> > On Thu, Feb 22, 2024 at 01:00:40PM -0800, Kees Cook wrote:
> > > > This does bring up some interesting questions. From off-list
> > > > discussions with Tobin, I believe he is not particularly interested in
> > > > maintaining this script any more. I was never set up to do the PRs
> > > > myself, I agreed to be a reviewer to help Tobin out. I'm happy to
> > > > adopt it if that makes sense, but I'm curious about the future of the
> > > > script:
> > > > 
> > > > 1. is it useful? (seems like yes if you're adding features)
> > > 
> > > Yes, LKP runs it as part of 0-day, and it's found leaks in the past[1].
> > > (Though its usage could be improved.)
> > 
> > Oh! That is good news :)
> > 
> > > > 2. does it make sense to live here as a separate thing? should we
> > > >    perhaps run it as part of kselftests or similar? I think that e.g.
> > > >    681ff0181bbf ("x86/mm/init/32: Stop printing the virtual memory
> > > >    layout") was not discovered with this script, but maybe if we put it
> > > >    inline with some other stuff people regularly run more of these would
> > > >    fall out? Maybe it makes sense to live somewhere else entirely
> > > >    (syzkaller)? I can probably set up some x86/arm64 infra to run it
> > > >    regularly, but that won't catch other less popular arches.
> > > 
> > > We could certainly do that. It would need some work to clean it up,
> > > though -- it seems like it wasn't designed to run as root (which is how
> > > LKP runs it, and likely how at least some CIs would run it).
> > > 
> > > > 3. perl. I'm mostly not a perl programmer, but would be happy to
> > > >    rewrite it in python pending the outcome of discussion above.
> > > 
> > > I am not a Perl fan either. It does work as-is, though. Address leaks,
> > > while worth fixing, are relatively low priority over all, so I wouldn't
> > > prioritize a rewrite very highly.
> > 
> > Yep, fair enough.
> 
> Thanks for taking this in through your tree Kees! And Tycho for
> picking up the pieces I dropped :)

Hi! You're welcome; I'm glad I have this script to build on!

> I can help review a re-write if it helps though I don't write Python
> daily and I am long way away from kernel work these days so I doubt
> I'd be all that much help.

No worries. I suppose we could rewrite it in Rust! :)

> I originally wrote it in Perl because I figured it would be easier to
> get past the old guys, six moths later I regretted the decision when I
> tried to re-read it.
> 
> Thanks for ping'ing me.

Good to hear from you!

Take care,

-Kees

-- 
Kees Cook

      reply	other threads:[~2024-02-29  5:30 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-18 17:38 [PATCH] leaking_addresses: Provide mechanism to scan binary files Kees Cook
2024-02-18 18:07 ` Greg KH
2024-02-22 15:24 ` Tycho Andersen
2024-02-22 21:00   ` Kees Cook
2024-02-22 21:10     ` Kees Cook
2024-02-22 23:49     ` Tycho Andersen
2024-02-29  4:40       ` Tobin Harding
2024-02-29  5:30         ` Kees Cook [this message]

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=202402282048.0CA1A50@keescook \
    --to=keescook@chromium.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=guixiongwei@gmail.com \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=me@tobin.cc \
    --cc=tycho@tycho.pizza \
    /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.