[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 26 Sep 2019 01:34:36 -0700
From: Joe Perches <joe@...ches.com>
To: Andrew Morton <akpm@...ux-foundation.org>, Julia Lawall
<julia.lawall@...6.fr>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org, Jonathan Corbet <corbet@....net>, Stephen
Kitt <steve@....org>, Kees Cook <keescook@...omium.org>, Nitin Gote
<nitin.r.gote@...el.com>, jannh@...gle.com,
kernel-hardening@...ts.openwall.com, Rasmus Villemoes
<rasmus.villemoes@...vas.dk>
Subject: Re: [PATCH V2 1/2] string: Add stracpy and stracpy_pad mechanisms
On Wed, 2019-09-25 at 14:50 -0700, Andrew Morton wrote:
> On Tue, 23 Jul 2019 06:51:36 -0700 Joe Perches <joe@...ches.com> wrote:
>
> > Several uses of strlcpy and strscpy have had defects because the
> > last argument of each function is misused or typoed.
> >
> > Add macro mechanisms to avoid this defect.
> >
> > stracpy (copy a string to a string array) must have a string
> > array as the first argument (dest) and uses sizeof(dest) as the
> > count of bytes to copy.
> >
> > These mechanisms verify that the dest argument is an array of
> > char or other compatible types like u8 or s8 or equivalent.
> >
> > A BUILD_BUG is emitted when the type of dest is not compatible.
> >
>
> I'm still reluctant to merge this because we don't have code in -next
> which *uses* it. You did have a patch for that against v1, I believe?
> Please dust it off and send it along?
https://lore.kernel.org/lkml/CAHk-=wgqQKoAnhmhGE-2PBFt7oQs9LLAATKbYa573UO=DPBE0Q@mail.gmail.com/
I gave up, especially after the snark from Linus
where he wrote I don't understand this stuff.
He's just too full of himself here merely using
argument from authority.
Creating and using a function like copy_string with
both source and destination lengths specified is
is also potentially a large source of defects where
the stracpy macro atop strscpy does not have a
defect path other than the src not being a string
at all.
I think the analysis of defects in string function
in the kernel is overly difficult today given the
number of possible uses of pointer and length in
strcpy/strncpy/strlcpy/stracpy.
I think also that there is some sense in what he
wrote against the "word salad" use of str<foo>cpy,
but using stracpy as a macro when possible instead
of strscpy also makes the analysis of defects rather
simpler.
The trivial script cocci I posted works well for the
simple cases.
https://lore.kernel.org/cocci/66fcdbf607d7d0bea41edb39e5579d63b62b7d84.camel@perches.com/
The more complicated cocci script Julia posted is
still not quite correct as it required intermediate
compilation for verification of specified lengths.
https://lkml.org/lkml/2019/7/25/1406
Tell me again if you still want it and maybe the
couple conversions that mm/ would get.
via:
$ spatch --all-includes --in-place -sp-file str.cpy.cocci mm
$ git diff --stat -p mm
--
mm/dmapool.c | 2 +-
mm/zswap.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/dmapool.c b/mm/dmapool.c
index fe5d33060415..b3a4feb423f8 100644
--- a/mm/dmapool.c
+++ b/mm/dmapool.c
@@ -158,7 +158,7 @@ struct dma_pool *dma_pool_create(const char *name, struct device *dev,
if (!retval)
return retval;
- strlcpy(retval->name, name, sizeof(retval->name));
+ stracpy(retval->name, name);
retval->dev = dev;
diff --git a/mm/zswap.c b/mm/zswap.c
index 08b6cefae5d8..c6cd38de185a 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -533,7 +533,7 @@ static struct zswap_pool *zswap_pool_create(char *type, char *compressor)
}
pr_debug("using %s zpool\n", zpool_get_type(pool->zpool));
- strlcpy(pool->tfm_name, compressor, sizeof(pool->tfm_name));
+ stracpy(pool->tfm_name, compressor);
pool->tfm = alloc_percpu(struct crypto_comp *);
if (!pool->tfm) {
pr_err("percpu alloc failed\n");
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
