Hi Kees, On Thu, Jul 17, 2025 at 04:47:04PM -0700, Kees Cook wrote: > On Tue, Jul 15, 2025 at 09:08:14AM +0200, Alejandro Colomar wrote: > > Hi Kees, > > > > On Mon, Jul 14, 2025 at 10:19:39PM -0700, Kees Cook wrote: > > > On Fri, Jul 11, 2025 at 10:58:56AM -0700, Linus Torvalds wrote: > > > > struct seq_buf s; > > > > seq_buf_init(&s, buf, szie); > > > > > > And because some folks didn't like this "declaration that requires a > > > function call", we even added: > > > > > > DECLARE_SEQ_BUF(s, 32); > > > > > > to do it in 1 line. :P > > > > > > I would love to see more string handling replaced with seq_buf. > > > > The thing is, it's not as easy as the fixes I'm proposing, and > > sprintf_end() solves a lot of UB in a minimal diff that you can dumbly > > apply. > > Note that I'm not arguing against your idea -- I just think it's not > going to be likely to end up in Linux soon given Linus's objections.
It would be interesting to hear if Linus holds his objections on v6. > My > perspective is mainly one of pragmatic damage control: what *can* we do > in Linux that would make things better? Currently, seq_buf is better > than raw C strings... TBH, I'm not fully convinced. While it may look simpler at first glance, I'm worried that it might bite in the details. I default to not trusting APIs that hide the complexity in hidden state. On the other hand, I agree that almost anything is safer than snprintf(3). But one good thing of snprintf(3) is that it's simple, and thus relatively obvious to see that it's wrong, so it's easy to fix (it's easy to transition from snprintf(3) to sprintf_end()). So, maybe keeping it bogus until it's replaced by sprintf_end() is a better approach than using seq_buf. (Unless the current code is found exploitable, but I assume not.) Have a lovely night! Alex -- <https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
