Re: [PATCH] IB/hfi1: replace deprecated strncpy

2023-09-29 Thread Kees Cook
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 +, 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



Re: [PATCH] IB/hfi1: replace deprecated strncpy

2023-09-26 Thread Dean Luick
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 +, 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?

-Dean

>
> -Kees
>
>>
>>>
>>> [1/1] IB/hfi1: replace deprecated strncpy
>>>   https://git.kernel.org/rdma/rdma/c/c2d0c5b28a77d5
>>>
>>> Best regards,
>>
>> External recipient
>

External recipient



Re: [PATCH] IB/hfi1: replace deprecated strncpy

2023-09-23 Thread Kees Cook
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 +, 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.

-Kees

> 
> >
> > [1/1] IB/hfi1: replace deprecated strncpy
> >   https://git.kernel.org/rdma/rdma/c/c2d0c5b28a77d5
> >
> > Best regards,
> 
> External recipient

-- 
Kees Cook



Re: [PATCH] IB/hfi1: replace deprecated strncpy

2023-09-22 Thread Dean Luick
On 9/22/2023 5:29 AM, Leon Romanovsky wrote:
>
> On Thu, 21 Sep 2023 07:17:47 +, 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.

>
> [1/1] IB/hfi1: replace deprecated strncpy
>   https://git.kernel.org/rdma/rdma/c/c2d0c5b28a77d5
>
> Best regards,

External recipient



Re: [PATCH] IB/hfi1: replace deprecated strncpy

2023-09-22 Thread Leon Romanovsky


On Thu, 21 Sep 2023 07:17:47 +, 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!

[1/1] IB/hfi1: replace deprecated strncpy
  https://git.kernel.org/rdma/rdma/c/c2d0c5b28a77d5

Best regards,
-- 
Leon Romanovsky