[U-Boot] [PATCH 0/4] Buffer overruns in printf

[Albert ARIBAUD]

Le 24/09/2011 16:00, Simon Glass a écrit :

>> So basically the choice is between:
>>
>> - adding code to the printf() family to try and fix an issue that it is
>> fundamentally unable to properly fix, and for which a solution exists, or
>>
>> - grepping and fixing calls to *sprintf() in U-Boot that do not respect the
>> known contraints of printf(), by resizing the buffer or calling *snprintf()
>> instead.
>>
>> I am definitely not in favor of the first option concerning U-Boot.
>
> Sounds fine to me. So I think we need the nprintf() variants in there,
> but the message is not to use them willy nilly. Going back to my patch
> series, 3/4 is ok, but 4/4 mostly crosses the line. Do I have that
> right?

It is the exact opposite for me : 3/4 makes all printf functions work 
like some kind of *nprintf(), while 4/4 is about the network code 
switching to *nprintf() for safety, so 3/4 would be nak and 4/4 ack as 
far as I am concerned.

Basically, printf family functions which do not have the 'n' are *know* 
by all -- experienced enough :) -- programmers to be *unsafe* (but to 
require less from the caller) and it should remain so: no programmer 
should ever encounter an implementation of printf that pretends to be 
even somewhat safe, because it might bite him/her elsewhere, in another 
project based on another C library where printf is just the beartrap it 
usually is.

IOW, programmers already have assumptions about *printf(), including how 
to deal with length limitations and what happens if you don't, and it is 
best that these assumption remain true whatever project they work with.

> By the way, printf() ends up calling the same code, but without limit
> checking in place. The alternative is to duplicate all the format
> string processing code (a limit-checking version and an unchecked
> version) which would be worse.

I don't intend to dictate the way things can be implemented, so the 
degree of code reuse is an open question as far as I am concerned. I am 
only voicing my opinion that *printf() APIs and their contracts should 
remain identical across all implementations of *printf(), and thus that 
providing *nprintf() where they don't exist is commandable, but 
hardening printf() is not, since you basically cannot do it without 
somewhat departing from the de facto standard.

> Regards,
> Simon

Amicalement,
-- 
Albert.