Re: [Powertop] [PATCH v2 6/8] Stop buffer overflow

[Sergey Senozhatsky <sergey.senozhatsky at gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1647 bytes --]

On (10/15/14 08:01), Arjan van de Ven wrote:
> >>>yes, this is the reason behind this proposal. these patches a) don't check for
> >>>overrun; b) don't handle overrun. they just shut up the compiler.
> >>
> >>
> >>that's never a good tradeoff.
> >>-D_FORTIFY_SOURCE-2 is an essential compiler feature that has a defined semantic/etc
> >>patches that make behavior worse than that baseline, but shut up some warning, are damage
> >>not value.
> >>
> >
> >well, the macro handles overrun (should probably be snprintf(a, bsz - 1, ...) >= bsz)
> >and replaces small part of the buffer with '...\0'. which is, imho, a bit better
> >than `backtrace(); abort();' (I don't think we can benefit from compile-time checks
> >of -D_FORTIFY_SOURCE=2, only run time ones) for developers that behaviour makes
> >sense, for users it's just "seg fault/core dump/whatever"
> 
> well it's that or corruption....

well '...' is just for example. we usually don't see processes
with '...' or devices with '...' in their names. could be any
error indication. e.g. 'ERROR', 'E2BIG', etc.

> the data is still truncated and partial.. and you keep running with it.

which is not that big deal. I agree, that this is not 100% handy.
but suppose there is a process with very long name. long enough to cause
overrun and powertop abort(). and that process is part of a runtime and
it must be alive, etc... and that automatically leaves only one option --
either that process or powertop. and never together.

	-ss

> (this is why many people first think strlcpy is a good idea, and then they think more about it and realize it's not)
> 
>