On 10/19/2015 08:42 AM, Rasmus Villemoes wrote:
On Mon, Oct 05 2015, Ingo Molnar wrote:
Interesting. I noticed that strscpy() says this in its comments:
* In addition, the implementation is robust to the string changing out
* from underneath it, unlike the current strlcpy() implementation.
On Mon, Oct 05 2015, Ingo Molnar wrote:
> * Linus Torvalds wrote:
>
>> On Thu, Sep 10, 2015 at 8:43 PM, Chris Metcalf wrote:
>> >
>> > Please pull the following changes for 4.3 from:
>> >
>> > git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile.git
>> > strscpy
>>
>> So I fina
* Rasmus Villemoes wrote:
> On Fri, Oct 09 2015, Rasmus Villemoes wrote:
>
> > It's hard not to agree with the overall "let's make it more robust if it
> > can be done sanely+cheaply+cleanly". I was a bit skeptical about whether
> > those three requirements could be met, since we'd have to do
On Fri, Oct 09 2015, Rasmus Villemoes wrote:
> It's hard not to agree with the overall "let's make it more robust if it
> can be done sanely+cheaply+cleanly". I was a bit skeptical about whether
> those three requirements could be met, since we'd have to do
> byte-by-byte traversal of the string,
On Thu, Oct 08 2015, Ingo Molnar wrote:
> * Linus Torvalds wrote:
>
>> So I really refuse to worry about the snprintf() family of functions wrt
>> this
>> race. I don't think it was hugely important for strlcpy() either - more of a
>> "quality of implementation" issue rather than anything fun
* Linus Torvalds wrote:
> So I really refuse to worry about the snprintf() family of functions wrt this
> race. I don't think it was hugely important for strlcpy() either - more of a
> "quality of implementation" issue rather than anything fundamental - but for
> snprintf and friends it's an
On Wed, Oct 7, 2015 at 10:04 AM, Rasmus Villemoes
wrote:
>
> Well, if truncation has happened the return value is different
> (larger). But assuming the output buffer is large enough, the 'compute
> strlen, then do copying, potentially copying a nul byte which wasn't
> there moments before' is pre
On Wed, Oct 07 2015, Ingo Molnar wrote:
> We have procfs and sysfs as well, where format strings are indeed dominant,
> but
> are you sure this race exists in snprintf() in that form? I.e. can the return
> value of snprintf() be different from the true length of the output string,
> if the
>
* Rasmus Villemoes wrote:
> On Tue, Oct 06 2015, Ingo Molnar wrote:
>
> > * Rasmus Villemoes wrote:
> >
> >>
> >> I'm not against making strlcpy more robust, but I think the theoretical
> >> race is
> >> far more likely to manifest through a member of the printf family.
> >
> > So the prin
On Tue, Oct 06 2015, Ingo Molnar wrote:
> * Rasmus Villemoes wrote:
>
>>
>> I'm not against making strlcpy more robust, but I think the theoretical race
>> is
>> far more likely to manifest through a member of the printf family.
>
> So the printf family is generally less frequently used in AB
* Rasmus Villemoes wrote:
> On Mon, Oct 05 2015, Ingo Molnar wrote:
>
> > * Linus Torvalds wrote:
> >
> >> So I finally pulled it. I like the patch, I like the new interface, but
> >> despite that I wasn't really sure if I wanted to pull it in - thus the
> >> long
> >> delay of me just see
* Rasmus Villemoes wrote:
> On Mon, Oct 05 2015, Ingo Molnar wrote:
>
> > * Linus Torvalds wrote:
> >
> >> So I finally pulled it. I like the patch, I like the new interface,
> >> but despite that I wasn't really sure if I wanted to pull it in - thus
> >> the long delay of me just seeing this
On Mon, Oct 05 2015, Ingo Molnar wrote:
> * Linus Torvalds wrote:
>
>> So I finally pulled it. I like the patch, I like the new interface,
>> but despite that I wasn't really sure if I wanted to pull it in - thus
>> the long delay of me just seeing this in my list of pending pulls for
>> almost
On Mon, Oct 5, 2015 at 5:22 PM, Ingo Molnar wrote:
>
> We could do something like:
>
> c = *(unsigned long *)(src+res);
> *(unsigned long *)(dest+res) = c;
>
> if (has_zero(c, &data, &constants)) {
No, I think we'd be better off just moving the "has
* Ingo Molnar wrote:
> We could do something like:
>
> c = *(unsigned long *)(src+res);
> *(unsigned long *)(dest+res) = c;
>
> if (has_zero(c, &data, &constants)) {
> unsigned int zero_pos;
>
> data
* Linus Torvalds wrote:
> > 2) strscpy() will copy garbage past NUL from source into destination. It
> > won't
> > fault but still, who knows what lies after string.
>
> Yes, that's probably worth fixing before we get actual users..
Hm, this is the spot:
c = *(unsigned long
* Ingo Molnar wrote:
>
> * Alexey Dobriyan wrote:
>
> > I want to say two things:
> >
> > 1) strlcpy race
> >
> > > * In addition, the implementation is robust to the string changing out
> > > * from underneath it, unlike the current strlcpy() implementation.
> >
> > Canonical OpenBSD ve
* Alexey Dobriyan wrote:
> I want to say two things:
>
> 1) strlcpy race
>
> > * In addition, the implementation is robust to the string changing out
> > * from underneath it, unlike the current strlcpy() implementation.
>
> Canonical OpenBSD version does byte-by-byte copying,
> this race i
* Linus Torvalds wrote:
> So I don't think a "generic" range check helper can force types like
> "unsigned long".
Yeah.
> That said, doing a simple
>
> git grep '<.*||.*>'
>
> does show that the "positive or non-zero ranges with constant range
> limits" case is fairly common, and maybe w
I want to say two things:
1) strlcpy race
> * In addition, the implementation is robust to the string changing out
> * from underneath it, unlike the current strlcpy() implementation.
Canonical OpenBSD version does byte-by-byte copying,
this race is purely Linux invention.
2) strscpy() will c
On Mon, Oct 5, 2015 at 3:33 PM, Ingo Molnar wrote:
>
> So we could solve that by adding a generic range check:
>
> static inline int range_ok(unsigned long low, unsigned long val, unsigned
> long high)
So what about the type of the thing you're checking?
Maybe negative values are ok. It's unus
* Linus Torvalds wrote:
> On Oct 5, 2015 14:15, "Ingo Molnar" wrote:
> >
> > Hm, so GCC (v4.9.2) will only warn about this bug if -Wtype-limits is
> enabled
> > explicitly:
>
> Some of the warnings are really nasty, and cause people to write worse code.
>
> For example, this is inherently goo
* Linus Torvalds wrote:
> On Oct 5, 2015 14:15, "Ingo Molnar" wrote:
> >
> > Hm, so GCC (v4.9.2) will only warn about this bug if -Wtype-limits is
> > enabled
> > explicitly:
>
> Some of the warnings are really nasty, and cause people to write worse code.
>
> For example, this is inherently
* Ingo Molnar wrote:
> Hm, so GCC (v4.9.2) will only warn about this bug if -Wtype-limits is enabled
> explicitly:
>
> lib/string.c: In function ‘strlcpy’:
> lib/string.c:228:32: warning: comparison of unsigned expression < 0 is
> always false [-Wtype-limits]
>if (unlikely((size_t)dst_s
* Ingo Molnar wrote:
>
> * Ingo Molnar wrote:
>
> > 2)
> >
> > Another problem is that strlcpy() will also happily do bad stuff if we pass
> > it a negative size. Instead of that we will from now on print a (one time)
> > warning and return safely.
>
> Hm, so this check is buggy, as 'size_t
* Linus Torvalds wrote:
> On Mon, Oct 5, 2015 at 12:27 PM, Ingo Molnar wrote:
> >
> > Interesting. I noticed that strscpy() says this in its comments:
> >
> > * In addition, the implementation is robust to the string changing out
> > * from underneath it, unlike the current strlcpy() implemen
On Mon, Oct 5, 2015 at 12:27 PM, Ingo Molnar wrote:
>
> Interesting. I noticed that strscpy() says this in its comments:
>
> * In addition, the implementation is robust to the string changing out
> * from underneath it, unlike the current strlcpy() implementation.
>
> The strscpy() interface is
* Ingo Molnar wrote:
> 2)
>
> Another problem is that strlcpy() will also happily do bad stuff if we pass
> it a negative size. Instead of that we will from now on print a (one time)
> warning and return safely.
Hm, so this check is buggy, as 'size_t' is unsigned - and for some reason GCC
did
9d8f688093f70 Mon Sep 17 00:00:00 2001
From: Ingo Molnar
Date: Mon, 5 Oct 2015 10:56:50 +0200
Subject: [PATCH] string: Improve the generic strlcpy() implementation
The current strlcpy() implementation has two implementational
weaknesses:
1)
There's a race:
size_t strlcpy(char *dest, const
29 matches
Mail list logo
