public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Tobin C. Harding" <me@tobin.cc>
To: Joe Perches <joe@perches.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Andy Whitcroft <apw@canonical.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] checkpatch: warn for use of %px
Date: Tue, 5 Dec 2017 20:44:32 +1100	[thread overview]
Message-ID: <20171205094432.GA11064@eros> (raw)
In-Reply-To: <1512458664.6321.71.camel@perches.com>

On Mon, Dec 04, 2017 at 11:24:24PM -0800, Joe Perches wrote:
> On Tue, 2017-12-05 at 08:17 +1100, Tobin C. Harding wrote:
> > Usage of the new %px specifier potentially leaks sensitive
> > inforamtion. Printing kernel addresses exposes the kernel layout in
> 
> information

I don't understand this comment? Do you mean the wording is wrong? I'll
re-word as suggested below.

> > memory, this is potentially exploitable. We have tools in the kernel to
> > help us do the right thing. We can have checkpatch warn developers of
> > potential dangers of using %px.
> > 
> > Have checkpatch emit a warning for usage of specifier %px.
> > 
> > Suggested-by: Andrew Morton <akpm@linux-foundation.org>
> > Signed-off-by: Tobin C. Harding <me@tobin.cc>
> > Co-Developed-by: Joe Perches <joe@perches.com>
> > 
> > ---
> > 
> > Joe,
> > 
> > Are you happy with this tagging? Needs your signed-off-by still.
> 
> Maybe with a few corrections (below)

thanks for the tips.

> > Andrew,
> > 
> > Is it okay to add your Suggested-by tag here?
> > 
> > I'm not entirely sure when one is supposed to add someones signed-off-by
> > tag since the docs state that it should not be added without
> > permission. I am also unsure where/when is the best time to request this
> > permission.
> []
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> []
> > @@ -1612,6 +1612,17 @@ sub raw_line {
> >  	return $line;
> >  }
> >  
> > +sub stat_real {
> > +	my ($linenr, $lc) = @_;
> > +
> > +	my $stat_real = raw_line($linenr, 0);
> > +	for (my $count = $linenr + 1; $count <= $lc; $count++) {
> > +		$stat_real = $stat_real . "\n" . raw_line($count, 0);
> > +	}
> > +
> > +	return $stat_real;
> > +}
> 
> If you are going to make a subroutine of this
> there are some other places it could be used too.

Ok, I'm not super happy with sub routine name. Have you a better suggestion?

> > +
> >  sub cat_vet {
> >  	my ($vet) = @_;
> >  	my ($res, $coded);
> > @@ -5747,24 +5758,35 @@ sub process {
> >  		    defined $stat &&
> >  		    $stat =~ /^\+(?![^\{]*\{\s*).*\b(\w+)\s*\(.*$String\s*,/s &&
> >  		    $1 !~ /^_*volatile_*$/) {
> > -			my $bad_extension = "";
> > +			my ($specifier, $extension, $stat_real);
> 
> My preference is not to define multiple variables on a single line.
> I'd rather have:
> 			my $specifier;
> 			my $extension;
> 			my $stat_real;

No problem, is this a kernel wide thing or just a checkpatch thing (so I
can follow your lead if need be in leaking_addresses.pl). Or is it the
same as we do in C, in which case $extension and $specifier could be on
a single line but not $stat_real?

> > +			my $bad_specifier = "";
> >  			my $lc = $stat =~ tr@\n@@;
> >  			$lc = $lc + $linenr;
> >  		        for (my $count = $linenr; $count <= $lc; $count++) {
> >  				my $fmt = get_quoted_string($lines[$count - 1], raw_line($count, 0));
> >  				$fmt =~ s/%%//g;
> > -				if ($fmt =~ /(\%[\*\d\.]*p(?![\WFfSsBKRraEhMmIiUDdgVCbGNOx]).)/) {
> > -					$bad_extension = $1;
> > -					last;
> > +
> > +				while ($fmt =~ /(\%[\*\d\.]*p(\w))/g) {
> > +					$specifier = $1;
> > +					$extension = $2;
> > +					if ($extension !~ /[FfSsBKRraEhMmIiUDdgVCbGNOx]/) {
> > +						$bad_specifier = $specifier;
> > +						last;
> > +					}
> > +					if ($extension eq "x" && !defined($stat_real)) {
> > +						if (!defined($stat_real)) {
> > +							$stat_real = stat_real($linenr, $lc);
> > +						}
> > +						WARN("VSPRINTF_SPECIFIER_PX",
> > +						     "Using vsprintf specifier '\%px' potentially exposes the kernel layout in memory, if you don't _realy_ need the address please consider using '\%p'.\n" . "$here\n$stat_real\n");	
> 
> "kernel memory layout" not "kernel layout in memory"
> "really" not "_realy_"

Got it.

thanks,
Tobin.

  reply	other threads:[~2017-12-05  9:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-04 21:17 [PATCH] checkpatch: warn for use of %px Tobin C. Harding
2017-12-05  7:24 ` Joe Perches
2017-12-05  9:44   ` Tobin C. Harding [this message]
2017-12-05 15:27     ` Joe Perches
2017-12-05 20:27       ` Tobin C. Harding

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=20171205094432.GA11064@eros \
    --to=me@tobin.cc \
    --cc=akpm@linux-foundation.org \
    --cc=apw@canonical.com \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox