On Tue, Sep 26, 2023 at 07:56:34AM -0500, Dean Luick wrote:
> On 9/23/2023 10:20 PM, Kees Cook wrote:
> > On Fri, Sep 22, 2023 at 09:25:39AM -0500, Dean Luick wrote:
> >> On 9/22/2023 5:29 AM, Leon Romanovsky wrote:
> >>>
> >>> On Thu, 21 Sep 2023 07:17:47 +0000, Justin Stitt wrote:
> >>>> `strncpy` is deprecated for use on NUL-terminated destination strings
> >>>> [1] and as such we should prefer more robust and less ambiguous string
> >>>> interfaces.
> >>>>
> >>>> We see that `buf` is expected to be NUL-terminated based on it's use
> >>>> within a trace event wherein `is_misc_err_name` and `is_various_name`
> >>>> map to `is_name` through `is_table`:
> >>>> | TRACE_EVENT(hfi1_interrupt,
> >>>> | TP_PROTO(struct hfi1_devdata *dd, const struct is_table
> >>>> *is_entry,
> >>>> | int src),
> >>>> | TP_ARGS(dd, is_entry, src),
> >>>> | TP_STRUCT__entry(DD_DEV_ENTRY(dd)
> >>>> | __array(char, buf, 64)
> >>>> | __field(int, src)
> >>>> | ),
> >>>> | TP_fast_assign(DD_DEV_ASSIGN(dd);
> >>>> | is_entry->is_name(__entry->buf, 64,
> >>>> | src - is_entry->start);
> >>>> | __entry->src = src;
> >>>> | ),
> >>>> | TP_printk("[%s] source: %s [%d]", __get_str(dev), __entry->buf,
> >>>> | __entry->src)
> >>>> | );
> >>>>
> >>>> [...]
> >>>
> >>> Applied, thanks!
> >>
> >> It is unfortunate that this and the qib patch was accepted so quickly.
> >> The replacement is functionally correct. However, I was going to suggest
> >> using strscpy() since the return value is never looked at and all use
> >> cases only require a NUL-terminated string. Padding is not needed.
> >
> > Is the trace buffer already guaranteed to be zeroed? Since this is
> > defined as a fixed-size string in the buffer, it made sense to me to be
> > sure that the unused bytes were 0 before copying them to userspace.
>
> I was not aware that binary trace records were exposed to user space. If so,
> and the event records are not zeroed (either the buffer as a whole, or
> individual records), then strscpy_pad() is the correct solution. My quick
> review of the tracing system suggests that nothing is zeroed and the record
> is embedded in a larger structure. However, this begs the question for all
> users of tracing: Aren't alignment holes in the fast assign record a leak?
I thought they were passed over direct to userspace somehow, but I
haven't looked at the details in a long time. I could very well be
misunderstanding it.
--
Kees Cook
