Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [RFC PATCH] toolchain-external: instrument wrapper to warn about unsafe paths
Date: Tue, 11 Feb 2014 18:53:30 +0100	[thread overview]
Message-ID: <20140211175330.GA3411@free.fr> (raw)
In-Reply-To: <20140211091855.00e6c483@skate>

Thomas, All,

On 2014-02-11 09:18 +0100, Thomas Petazzoni spake thusly:
> On Tue, 11 Feb 2014 01:33:27 +0100, Yann E. MORIN wrote:
> 
> > > Optionally, if BR_PARANOID_WRAPPER is defined in the environment, the
> > > external wrapper will instead error out and abort the compilation. We
> > > could then one day imagine setting this BR_PARANOID_WRAPPER in the
> > > autobuilders.
> > 
> > I think I'd prefer we do as for BR_DEBUG_WRAPPER:
> >     BR2_PARANOID_WRAPPER undefined or empty: nothing
> >     BR2_PARANOID_WRAPPER=WARNING           : warning
> >     BR2_PARANOID_WRAPPER=ERROR             : error out
> 
> Sure, I don't have any particular feeling about this. However, I would
> maybe like to have this feature enabled as the warning level by default.

Probably sane, indeed.

> > Side-note: BR_DEBUG_WRAPPER should probably be renamed to
> > BR2_DEBUG_WRAPPER, to follow the newly-stated naming scheme, no?
> 
> If I understood the newly-stated naming scheme, yes, I believe you're
> right, it should be renamed BR2_DEBUG_WRAPPER.

Ok, will cook a patch.

> > > A similar change could be made to the internal toolchain backend
> > > either by making it use a wrapper like the external toolchain one, or
> > > by adding some patches to gcc, by borrowing the changes made by the
> > > CodeSourcery people.
> > 
> > Maybe it would be best to not duplicate this, and always use the
> > wrapper, even for the internal backend?
> 
> Which is exactly one of the two solutions I proposed in the paragraph
> you're quoting :-)

And I was just expressing my preference. ;-)

> > > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> > > ---
> > >  .../toolchain-external/ext-toolchain-wrapper.c     | 27 ++++++++++++++++++++++
> > >  1 file changed, 27 insertions(+)
> > > 
> > > diff --git a/toolchain/toolchain-external/ext-toolchain-wrapper.c b/toolchain/toolchain-external/ext-toolchain-wrapper.c
> > > index 81c6ed1..c8dcad5 100644
> > > --- a/toolchain/toolchain-external/ext-toolchain-wrapper.c
> > > +++ b/toolchain/toolchain-external/ext-toolchain-wrapper.c
> > > @@ -77,6 +77,7 @@ int main(int argc, char **argv)
> > >  	char *progpath = argv[0];
> > >  	char *basename;
> > >  	char *env_debug;
> > > +	char *paranoid_wrapper;
> > >  	int ret, i, count = 0, debug;
> > >  
> > >  	/* Calculate the relative paths */
> > > @@ -178,6 +179,32 @@ int main(int argc, char **argv)
> > >  	}
> > >  #endif /* ARCH || TUNE || CPU */
> > >  
> > > +	paranoid_wrapper = getenv("BR_PARANOID_WRAPPER");
> > > +
> > > +	/* Check for unsafe library and header paths */
> > > +	for (i = 1; i < argc; i++) {
> > > +		if (!strncmp(argv[i], "-I/usr", strlen("-I/usr")) ||
> > > +		    !strncmp(argv[i], "-L/usr", strlen("-L/usr"))) {

Don't we also want to check -L/lib as well?

> > No need for strncmp: you're comparing to a constant, so it will not
> > overflow.
> 
> I need strncmp here: I want to match only the first characters of
> argv[i]. I.e, the above condition should match:
> 
> 	-I/usr/bar
> 	-L/usr/local/foo
> 	-I/usr/include/mysql
> 
> etc. If I use strcmp(), it is going to compare the entire string, and
> -I/usr/include/mysql is not the same as -I/usr.

Doh, righto-right. I should not review patches so late in the night...

> > Also, using strlen on an argument of strncmp is flawed to begin with.
> 
> Weird, a certain Yann E. Morin did exactly this in
> http://git.buildroot.net/buildroot/commit/toolchain/toolchain-external/ext-toolchain-wrapper.c?id=2c1dc32647eb308126b0ae80a91988059d39aa7b :-)

Hehe! ;-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

  reply	other threads:[~2014-02-11 17:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-10 23:28 [Buildroot] [RFC PATCH] toolchain-external: instrument wrapper to warn about unsafe paths Thomas Petazzoni
2014-02-11  0:33 ` Yann E. MORIN
2014-02-11  8:18   ` Thomas Petazzoni
2014-02-11 17:53     ` Yann E. MORIN [this message]
2014-02-11  6:21 ` Baruch Siach
2014-02-11  8:24   ` Thomas Petazzoni

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=20140211175330.GA3411@free.fr \
    --to=yann.morin.1998@free.fr \
    --cc=buildroot@busybox.net \
    /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