[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKwvOdm9GMcR8rAwaEL8Nv7xJ-gAgo1NmmihF=CG72x0qj2MKw@mail.gmail.com>
Date: Thu, 26 Aug 2021 11:08:47 -0700
From: Nick Desaulniers <ndesaulniers@...gle.com>
To: Kees Cook <keescook@...omium.org>
Cc: linux-kernel@...r.kernel.org,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Rasmus Villemoes <linux@...musvillemoes.dk>,
Daniel Micay <danielmicay@...il.com>,
Francis Laniel <laniel_francis@...vacyrequired.com>,
Bart Van Assche <bvanassche@....org>,
David Gow <davidgow@...gle.com>, linux-mm@...ck.org,
clang-built-linux@...glegroups.com, linux-hardening@...r.kernel.org
Subject: Re: [PATCH for-next 14/25] lib/string: Move helper functions out of string.c
On Wed, Aug 25, 2021 at 7:47 PM Kees Cook <keescook@...omium.org> wrote:
>
> On Wed, Aug 25, 2021 at 02:48:30PM -0700, Nick Desaulniers wrote:
> > are memset16, memset32, and memset64 worth moving as well? Also,
> > memscan(), check_bytes(), memchr_inv()?
>
> All of these are implementations, so they should stay put.
All of the functions being moved here are definitions. So what's the
difference between moving the definitions of functions like
strrreplace, fortify_panic, etc., but not memscan(), check_bytes(),
memchr_inv(), etc? ie. it looks to me like a few more functions can
or should be moved as well. If the point of this patch is to "move
all the helper functions into string_helpers.c so that they gain the
fortification coverage they had been missing" then it looks like you
missed a few. I don't think the compiler will recognize those
non-libc identifiers for any fortification related transforms (unlike
memcpy and friends which are left in place).
--
Thanks,
~Nick Desaulniers
Powered by blists - more mailing lists