On Fri, Oct 20, 2023 at 11:30:49AM -0700, Kees Cook wrote:
> I'm curious where you looked and didn't find documentation -- perhaps
> there is an improvement to be made to aim one to where the existing
> documentation lives?
My order was the following:
- look for kernel doc on the main function i
On Thu, 2023-10-26 at 12:01 +0200, Christoph Hellwig wrote:
> > > There's some docs at [1]. Perhaps there could be more?
> > >
> > > [1]:
> > > https://elixir.bootlin.com/linux/v6.6-rc6/source/include/linux/fortify-string.h#L292
> >
> > Right, And it's even valid kern-doc, which gets rendered in
> > > [1]:
> > > https://elixir.bootlin.com/linux/v6.6-rc6/source/include/linux/fortify-string.h#L292
I found that https://elixir.bootlin.com/linux is the best way to find
Documentation for functions and structures. I would suggest try it
first, and only when what fails to start using grep.
On Thu, Oct 26, 2023 at 03:44:22PM +0200, Andrew Lunn wrote:
> > > > [1]:
> > > > https://elixir.bootlin.com/linux/v6.6-rc6/source/include/linux/fortify-string.h#L292
>
> I found that https://elixir.bootlin.com/linux is the best way to find
> Documentation for functions and structures. I would su
On Thu, 26 Oct 2023 07:39:44 -0400
James Bottomley wrote:
> While it's nice in theory to have everything documented, it's not much
> use if no one can actually find the information ...
Does kerneldoc provide an automated index? That is, if we had a single file
that had every function in the kern
Hi Steven,
On Thu, Oct 26, 2023 at 3:52 PM Steven Rostedt wrote:
> On Thu, 26 Oct 2023 07:39:44 -0400
> James Bottomley wrote:
>
> > While it's nice in theory to have everything documented, it's not much
> > use if no one can actually find the information ...
>
> Does kerneldoc provide an automa
Steven Rostedt writes:
> On Thu, 26 Oct 2023 07:39:44 -0400
> James Bottomley wrote:
>
>> While it's nice in theory to have everything documented, it's not much
>> use if no one can actually find the information ...
>
> Does kerneldoc provide an automated index?
If you go to https://www.kernel.
On Thu, 2023-10-26 at 15:44 +0200, Andrew Lunn wrote:
> > > > [1]:
> > > > https://elixir.bootlin.com/linux/v6.6-rc6/source/include/linux/fortify-string.h#L292
>
> I found that https://elixir.bootlin.com/linux
That's a 404, I think you mean
https://elixir.bootlin.com/linux/latest/source
> is t
Solve two ergonomic issues with struct seq_buf:
1) Too much boilerplate is required to initialize:
struct seq_buf s;
char buf[32];
seq_buf_init(s, buf, sizeof(buf));
Instead, we can build this directly on the stack. Provide
DECLARE_SEQ_BUF() macro to do this:
DE
The use of strlcat() is fragile at best, and we'd like to remove it from
the available string APIs in the kernel. Instead, use the safer seq_buf
APIs.
Cc: Kalle Valo
Cc: Johannes Berg
Cc: Max Chen
Cc: Yang Shen
Cc: Steven Rostedt
Cc: "Matthew Wilcox (Oracle)"
Cc: Christoph Hellwig
Cc: Justi
On Tue, Oct 24, 2023 at 04:39:36PM -0700, Kees Cook wrote:
> As the replacements get longer, I would encourage you to use seq_buf
> instead -- it does all the length math internally. For example:
There's some ongoing work to make seq_buf easier to use:
https://lore.kernel.org/lkml/20231026170722.w
On Tue, Oct 17, 2023 at 08:11:28PM +, Justin Stitt wrote:
> Let's move away from using strncpy and instead favor a less ambiguous
> and more robust interface.
>
> For ifp->ndev->name, we expect ifp->ndev->name to be NUL-terminated based
> on its use in format strings within core.c:
> 67 |
On Wed, Oct 18, 2023 at 05:03:02PM -0700, Kees Cook wrote:
> On Tue, Oct 17, 2023 at 08:11:29PM +, Justin Stitt wrote:
> > Let's move away from using strncpy and instead use the more obvious
> > interface for this context.
> [...]
> So, this change results in the same behavior ...
I should hav
On Tue, Oct 17, 2023 at 03:51:58PM -0700, Jeff Johnson wrote:
> On 10/17/2023 2:12 PM, 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.
> >
> > `extra` is clearly
On Thu, 26 Oct 2023 10:07:28 -0700
Kees Cook wrote:
> Solve two ergonomic issues with struct seq_buf:
"ergonomic"? Does it cause carpal tunnel? ;-)
>
> 1) Too much boilerplate is required to initialize:
>
> struct seq_buf s;
> char buf[32];
>
> seq_buf_init(s, buf, sizeof(b
On Thu, Oct 26, 2023 at 01:47:32AM +, 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.
>
> This whole process of 1) determining smaller length so we don't overread
On Thu, Oct 26, 2023 at 01:53:13AM +, 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.
>
> To keep node->current_state_name and node->prev_state_name NUL-padded
> a
On Thu, Oct 26, 2023 at 01:38:50PM -0400, Steven Rostedt wrote:
> On Thu, 26 Oct 2023 10:07:28 -0700
> Kees Cook wrote:
>
> > Solve two ergonomic issues with struct seq_buf:
>
> "ergonomic"? Does it cause carpal tunnel? ;-)
>
> >
> > 1) Too much boilerplate is required to initialize:
> >
> >
On Thu, 26 Oct 2023 10:54:26 -0700
Kees Cook wrote:
> > Do we really need to call it _cstr? Why not just have seq_buf_str() ?
> >
> > I mean, this is C, do we need to state that in the name too?
>
> I'm fine either way. I did that just to make the distinction between our
> length-managed stri
On Thu, Oct 26, 2023 at 02:02:47PM -0400, Steven Rostedt wrote:
> On Thu, 26 Oct 2023 10:54:26 -0700
> Kees Cook wrote:
>
> > > Do we really need to call it _cstr? Why not just have seq_buf_str() ?
> > >
> > > I mean, this is C, do we need to state that in the name too?
> >
> > I'm fine eithe
On Thu, 26 Oct 2023 12:35:43 -0700
Kees Cook wrote:
> I'll send a v2 as seq_buf_str()...
Thanks.
-- Steve
Solve two ergonomic issues with struct seq_buf;
1) Too much boilerplate is required to initialize:
struct seq_buf s;
char buf[32];
seq_buf_init(s, buf, sizeof(buf));
Instead, we can build this directly on the stack. Provide
DECLARE_SEQ_BUF() macro to do this:
DE
On Thu, 26 Oct 2023 12:40:37 -0700
Kees Cook wrote:
> @@ -81,16 +88,20 @@ static inline unsigned int seq_buf_used(struct seq_buf *s)
> *
> * After this function is called, s->buffer is safe to use
> * in string operations.
> + *
> + * Returns @s->buf after making sure it is terminated.
>
On Thu, Oct 26, 2023 at 12:40:37PM -0700, Kees Cook wrote:
> Solve two ergonomic issues with struct seq_buf;
>
> 1) Too much boilerplate is required to initialize:
>
> struct seq_buf s;
> char buf[32];
>
> seq_buf_init(s, buf, sizeof(buf));
>
> Instead, we can build this direc
On Thu, 26 Oct 2023 23:20:15 +0300
Andy Shevchenko wrote:
> > +#define DECLARE_SEQ_BUF(NAME, SIZE)
> > \
> > + char __ ## NAME ## _buffer[SIZE] = ""; \
> > + struct seq_buf NAME = { .buffer = &__ ## NAME ## _buffer, \
> >
On Thu, Oct 26, 2023 at 10:13 AM Kees Cook wrote:
>
> The use of strlcat() is fragile at best, and we'd like to remove it from
> the available string APIs in the kernel. Instead, use the safer seq_buf
> APIs.
>
> Cc: Kalle Valo
> Cc: Johannes Berg
> Cc: Max Chen
> Cc: Yang Shen
> Cc: Steven Ro
nux-manual-4.8/strscpy.9.en.html [2]
Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Cc: Kees Cook
Signed-off-by: Justin Stitt
---
Changes in v2:
- use stack for buffers (thanks Kees)
- use kstrtoint (thanks Kees)
- Link to v1:
https://lore.kernel.org/r/202310
strncpy() is deprecated for use on NUL-terminated destination strings
[1] and as such we should prefer more robust and less ambiguous string
interfaces.
`extra` is clearly supposed to be NUL-terminated which is evident by the
manual NUL-byte assignment as well as its immediate usage with strlen().
We're doing some needless string copies when trying to assign the proper
`prop` string. We can make `prop` a const char* and simply assign to
string literals.
For the case where a format string is used, let's allocate some memory
via kasprintf() and point prop to it.
This also cleans up some depr
ARRAY_SIZE(prop));
> > + strscpy(prop, "semtech,ph01-proxraw-strength",
> > sizeof(prop));
> > else
> > - strncpy(prop, "semtech,ph23-proxraw-strength",
> > - ARRAY_SIZE(prop));
> > + strscpy(prop, "semtech,ph23-proxraw-strength",
> > sizeof(prop));
> > ret = device_property_read_u32(dev, prop, &raw);
> > if (ret)
> > break;
> >
> > ---
> > base-commit: 2cf0f715623872823a72e451243bbf555d10d032
> > change-id: 20230921-strncpy-drivers-iio-proximity-sx9324-c-8c3437676039
> >
> > Best regards,
> > --
> > Justin Stitt
> >
>
[v2]:
https://lore.kernel.org/r/20231026-strncpy-drivers-iio-proximity-sx9324-c-v2-1-cee6e5db7...@google.com
Thanks
Justin
On 10/26/2023 4:19 PM, 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.
`extra` is clearly supposed to be NUL-terminated which is evident by the
manual NUL-byte assignment
On Thu, Oct 26, 2023 at 12:40:37PM -0700, Kees Cook wrote:
> Solve two ergonomic issues with struct seq_buf;
>
> 1) Too much boilerplate is required to initialize:
>
> struct seq_buf s;
> char buf[32];
>
> seq_buf_init(s, buf, sizeof(buf));
>
> Instead, we can build this direc
32 matches
Mail list logo
