lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Thu, 16 Oct 2014 23:28:59 +0200
From:	Rickard Strandqvist <rickard_strandqvist@...ctrumdigital.se>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Grant Likely <grant.likely@...aro.org>,
	Andi Kleen <ak@...ux.intel.com>,
	Dan Carpenter <dan.carpenter@...cle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] lib: string.c: Added a funktion function strzcpy

2014-10-16 23:17 GMT+02:00 Andrew Morton <akpm@...ux-foundation.org>:
> On Thu, 16 Oct 2014 23:09:00 +0200 Rickard Strandqvist <rickard_strandqvist@...ctrumdigital.se> wrote:
>
>> 2014-10-16 0:15 GMT+02:00 Andrew Morton <akpm@...ux-foundation.org>:
>> > On Sun,  5 Oct 2014 15:06:17 +0200 Rickard Strandqvist <rickard_strandqvist@...ctrumdigital.se> wrote:
>> >
>> >> Added a function strzcpy which works the same as strncpy,
>> >> but guaranteed to produce the trailing null character.
>> >>
>> >> There are many places in the code where strncpy used although it
>> >> must be zero terminated, and switching to strlcpy is not an option
>> >> because the string must nonetheless be fyld with zero characters.
>> >
>> > As I mentioned last time, I think this patch would be better if it came
>> > with follow-on patches which convert at least some of those callsites.
>> > As it stands, this function has no callers and hence it won't get
>> > tested.  Plus those follow-on patches will demonstrate the value of
>> > this patch and will provide example usages.
>>
>>
>> Hi
>>
>> Sure I can do that! I have saved some patches just to be able to use
>> this new feature.
>> But should I submit everything as one patch then?
>> Or is there some kind of dependency thing I can use...
>
> [patch 1/N] lib/string.c: add strzcpy()
> [patch 2/N] foo/bar/zot.c: use strzcpy()
> [patch 3/N] fooz/barz/zot.c: use strzcpy()
> ...
>
>> I have also e-mailed with Dan about this, he pointed out the same as
>> some of my tests indicate that strzcpy maybe just should use strncpy
>> and add a null character instead because strncpy is optimized
>> depending on the hardware it runs on.
>> What do you think about that?
>
> Sounds like strzcpy() should be used in places where the entire buffer
> will be copied out to userspace, or in other situations where we want to
> zero it out for security reasons?


Hi

So that's how you write it, ok I will send them this weekend when I
have some more time.

Yes it was the safety aspect I was most yelled at when I start
swapping strncpy with strlcpy, although much of it was justified!

Even Linus was getting into the debate.  See more:
https://plus.google.com/111049168280159033135/posts/1amLbuhWbh5


Kind regards
Rickard Strandqvist
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ