[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 26 Jun 2011 21:46:18 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Vasiliy Kulikov <segoon@...nwall.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
James Morris <jmorris@...ei.org>, Namhyung Kim <namhyung@...il.com>,
Greg Kroah-Hartman <gregkh@...e.de>,
kernel-hardening@...ts.openwall.com, linux-kernel@...r.kernel.org,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH v2] kernel: escape non-ASCII and control characters in
printk()
* Vasiliy Kulikov <segoon@...nwall.com> wrote:
> On Sun, Jun 26, 2011 at 20:26 +0200, Ingo Molnar wrote:
>
> > > > Also, i think it would be better to make this opt-out, i.e.
> > > > exclude the handful of control characters that are harmful
> > > > (such as backline and console escape), instead of trying to
> > > > include the known-useful ones.
> > >
> > > Do you see any issue with the check above?
> >
> > There were clear problems with the first version you posted and
> > that's enough proof to request the exclusion of known-dangerous
> > characters instead of including known-useful characters.
>
> It doesn't proof anything. If I/someone else did a mistake with
> blacklisting would you say it is enough proof to request the
> inclusion of well-known allowed characters?
No, because the problems such a mistake causes are not equivalent: it
would have been far more harmful to not print out the *very real*
product names written in some non-US language than to accidentally
include some control character you did not think of.
> > A black list is well-defined: it disables the display of certain
> > characters because they are *known to be dangerous*.
>
> What do you do with dangerous characters that are *not yet known*
> to be dangerous?
I'm ready to act on facts only. Also, i really prefer the policy of
acting on known dangers instead of being afraid of the unknown.
The whole 'trust but verify' thing.
> > A white list on the other hand does it the wrong way around: it
> > tries to put the 'burden of proof' on the useful, good guys - and
> > that's counter-productive really.
>
> Really? I think strict API definition is productive, unlike using
> it in cases where it looks like working, but creating tricky and
> obscure bugs.
You werent really creating a well-defined API here, were you?
> Yes, drawing multicolor logs is funny, but ...egrrr... printk() is
> not written for these things.
maybe, but i still think that such a change works better, has fewer
unintended side effects and is better documented if it excludes known
dangers instead of trying to include known useful bits imperfectly.
Thanks,
Ingo
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
