From: Francis Laniel <[email protected]>
Hi.
I hope your families, friends and yourselves are fine.
This patch set answers to this issue:
https://github.com/KSPP/linux/issues/46
I based my modifications on top of two patches from Daniel Axtens which modify
calls to __builtin_object_size to ensure the true size of char * are returned
and not the surrounding structure size.
To sum up, in my first patch I implemented a fortified version of strscpy.
This new version ensures the following before calling vanilla strscpy:
1. There is no read overflow because either size is smaller than src length
or we shrink size to src length by calling fortified strnlen.
2. There is no write overflow because we either failed during compilation or at
runtime by checking that size is smaller than dest size.
The second patch brings a new file in LKDTM driver to test this new version.
The test ensures the fortified version still returns the same value as the
vanilla one while panic'ing when there is a write overflow.
The third just corrects some typos in LKDTM related file.
If you see any problem or way to improve the code, feel free to share it.
Best regards.
Daniel Axtens (2):
string.h: detect intra-object overflow in fortified string functions
lkdtm: tests for FORTIFY_SOURCE
Francis Laniel (3):
string.h: Add FORTIFY coverage for strscpy()
Add new file in LKDTM to test fortified strscpy.
Correct wrong filenames in comment.
drivers/misc/lkdtm/Makefile | 1 +
drivers/misc/lkdtm/bugs.c | 50 +++++++++++++++
drivers/misc/lkdtm/core.c | 3 +
drivers/misc/lkdtm/fortify.c | 82 +++++++++++++++++++++++++
drivers/misc/lkdtm/lkdtm.h | 19 +++---
include/linux/string.h | 75 ++++++++++++++++++----
tools/testing/selftests/lkdtm/tests.txt | 1 +
7 files changed, 213 insertions(+), 18 deletions(-)
create mode 100644 drivers/misc/lkdtm/fortify.c
--
2.20.1
From: Francis Laniel <[email protected]>
In lkdtm.h, files targeted in comments are named "lkdtm_file.c" while there are
named "file.c" in directory.
Signed-off-by: Francis Laniel <[email protected]>
Acked-by: Kees Cook <[email protected]>
---
drivers/misc/lkdtm/lkdtm.h | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/misc/lkdtm/lkdtm.h b/drivers/misc/lkdtm/lkdtm.h
index 138f06254b61..6aa6d6a1a839 100644
--- a/drivers/misc/lkdtm/lkdtm.h
+++ b/drivers/misc/lkdtm/lkdtm.h
@@ -6,7 +6,7 @@
#include <linux/kernel.h>
-/* lkdtm_bugs.c */
+/* bugs.c */
void __init lkdtm_bugs_init(int *recur_param);
void lkdtm_PANIC(void);
void lkdtm_BUG(void);
@@ -35,7 +35,7 @@ void lkdtm_CORRUPT_PAC(void);
void lkdtm_FORTIFY_OBJECT(void);
void lkdtm_FORTIFY_SUBOBJECT(void);
-/* lkdtm_heap.c */
+/* heap.c */
void __init lkdtm_heap_init(void);
void __exit lkdtm_heap_exit(void);
void lkdtm_OVERWRITE_ALLOCATION(void);
@@ -47,7 +47,7 @@ void lkdtm_SLAB_FREE_DOUBLE(void);
void lkdtm_SLAB_FREE_CROSS(void);
void lkdtm_SLAB_FREE_PAGE(void);
-/* lkdtm_perms.c */
+/* perms.c */
void __init lkdtm_perms_init(void);
void lkdtm_WRITE_RO(void);
void lkdtm_WRITE_RO_AFTER_INIT(void);
@@ -62,7 +62,7 @@ void lkdtm_EXEC_NULL(void);
void lkdtm_ACCESS_USERSPACE(void);
void lkdtm_ACCESS_NULL(void);
-/* lkdtm_refcount.c */
+/* refcount.c */
void lkdtm_REFCOUNT_INC_OVERFLOW(void);
void lkdtm_REFCOUNT_ADD_OVERFLOW(void);
void lkdtm_REFCOUNT_INC_NOT_ZERO_OVERFLOW(void);
@@ -83,10 +83,10 @@ void lkdtm_REFCOUNT_SUB_AND_TEST_SATURATED(void);
void lkdtm_REFCOUNT_TIMING(void);
void lkdtm_ATOMIC_TIMING(void);
-/* lkdtm_rodata.c */
+/* rodata.c */
void lkdtm_rodata_do_nothing(void);
-/* lkdtm_usercopy.c */
+/* usercopy.c */
void __init lkdtm_usercopy_init(void);
void __exit lkdtm_usercopy_exit(void);
void lkdtm_USERCOPY_HEAP_SIZE_TO(void);
@@ -98,7 +98,7 @@ void lkdtm_USERCOPY_STACK_FRAME_FROM(void);
void lkdtm_USERCOPY_STACK_BEYOND(void);
void lkdtm_USERCOPY_KERNEL(void);
-/* lkdtm_stackleak.c */
+/* stackleak.c */
void lkdtm_STACKLEAK_ERASING(void);
/* cfi.c */
--
2.20.1
On Thu, 19 Nov 2020 17:49:10 +0100 [email protected] wrote:
> From: Francis Laniel <[email protected]>
>
> Hi.
>
>
> I hope your families, friends and yourselves are fine.
Thanks. You too ;)
> This patch set answers to this issue:
> https://github.com/KSPP/linux/issues/46
I fail to understand what this patchset has to do with that
one-element-array issue :(
> I based my modifications on top of two patches from Daniel Axtens which modify
> calls to __builtin_object_size to ensure the true size of char * are returned
> and not the surrounding structure size.
>
> To sum up, in my first patch I implemented a fortified version of strscpy.
> This new version ensures the following before calling vanilla strscpy:
> 1. There is no read overflow because either size is smaller than src length
> or we shrink size to src length by calling fortified strnlen.
> 2. There is no write overflow because we either failed during compilation or at
> runtime by checking that size is smaller than dest size.
> The second patch brings a new file in LKDTM driver to test this new version.
> The test ensures the fortified version still returns the same value as the
> vanilla one while panic'ing when there is a write overflow.
> The third just corrects some typos in LKDTM related file.
>
> If you see any problem or way to improve the code, feel free to share it.
Could you please send along a reworked [0/n] cover letter? Explain in
your own words, without requiring that readers go off and read web
pages
- What problem the patchset solves
- How it solves it
- The value of the patchset (to kernel developers or to end-users) so that we
can understand why it should be merged.
Thanks.
Le vendredi 20 novembre 2020, 02:35:43 CET Andrew Morton a ?crit :
> On Thu, 19 Nov 2020 17:49:10 +0100 [email protected] wrote:
> > From: Francis Laniel <[email protected]>
> >
> > Hi.
> >
> >
> > I hope your families, friends and yourselves are fine.
>
> Thanks. You too ;)
Thank you!
> > This patch set answers to this issue:
> > https://github.com/KSPP/linux/issues/46
>
> I fail to understand what this patchset has to do with that
> one-element-array issue :(
I think I linked another issue totally not related with that one...
> > I based my modifications on top of two patches from Daniel Axtens which
> > modify calls to __builtin_object_size to ensure the true size of char *
> > are returned and not the surrounding structure size.
> >
> > To sum up, in my first patch I implemented a fortified version of strscpy.
> > This new version ensures the following before calling vanilla strscpy:
> > 1. There is no read overflow because either size is smaller than src
> > length
> > or we shrink size to src length by calling fortified strnlen.
> > 2. There is no write overflow because we either failed during compilation
> > or at runtime by checking that size is smaller than dest size.
> > The second patch brings a new file in LKDTM driver to test this new
> > version. The test ensures the fortified version still returns the same
> > value as the vanilla one while panic'ing when there is a write overflow.
> > The third just corrects some typos in LKDTM related file.
> >
> > If you see any problem or way to improve the code, feel free to share it.
>
> Could you please send along a reworked [0/n] cover letter? Explain in
> your own words, without requiring that readers go off and read web
> pages
>
> - What problem the patchset solves
> - How it solves it
> - The value of the patchset (to kernel developers or to end-users) so that
> we can understand why it should be merged.
>
> Thanks.
I will do it, moreover Kees Cook already told me that cover letter should
suffices itself (e.g. if the issue disappeared on GitHub).
So I will rework the cover letter for the v7!
From: Andrew Morton
> Sent: 20 November 2020 01:36
...
> Could you please send along a reworked [0/n] cover letter? Explain in
> your own words, without requiring that readers go off and read web
> pages
>
> - What problem the patchset solves
> - How it solves it
> - The value of the patchset (to kernel developers or to end-users) so that we
> can understand why it should be merged.
- How much it slows things down.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Le vendredi 20 novembre 2020, 14:33:53 CET David Laight a ?crit :
> From: Andrew Morton
>
> > Sent: 20 November 2020 01:36
>
> ...
>
> > Could you please send along a reworked [0/n] cover letter? Explain in
> > your own words, without requiring that readers go off and read web
> > pages
> >
> > - What problem the patchset solves
> > - How it solves it
> > - The value of the patchset (to kernel developers or to end-users) so that
> > we>
> > can understand why it should be merged.
>
> - How much it slows things down.
I will add it for the next version!
> David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1
> 1PT, UK Registration No: 1397386 (Wales)
On Fri, Nov 20, 2020 at 10:40:38AM +0100, Francis Laniel wrote:
> Le vendredi 20 novembre 2020, 02:35:43 CET Andrew Morton a ?crit :
> > On Thu, 19 Nov 2020 17:49:10 +0100 [email protected] wrote:
> > > This patch set answers to this issue:
> > > https://github.com/KSPP/linux/issues/46
> >
> > I fail to understand what this patchset has to do with that
> > one-element-array issue :(
>
> I think I linked another issue totally not related with that one...
This just looks like a typo. The URL should be:
https://github.com/KSPP/linux/issues/96
--
Kees Cook
Le vendredi 20 novembre 2020, 20:52:07 CET Kees Cook a ?crit :
> On Fri, Nov 20, 2020 at 10:40:38AM +0100, Francis Laniel wrote:
> > Le vendredi 20 novembre 2020, 02:35:43 CET Andrew Morton a ?crit :
> > > On Thu, 19 Nov 2020 17:49:10 +0100 [email protected]
wrote:
> > > > This patch set answers to this issue:
> > > > https://github.com/KSPP/linux/issues/46
> > >
> > > I fail to understand what this patchset has to do with that
> > > one-element-array issue :(
> >
> > I think I linked another issue totally not related with that one...
>
> This just looks like a typo. The URL should be:
> https://github.com/KSPP/linux/issues/96
This is not a typo because my branch to work on this issue is called 46-
fortifiy_strscpy.
I just think I got mixed up!
But I completely removed the link to this issue in the v7, so it does not
matter a lot now.