Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1669916 > unrolled thread

[PATCH 0/7] CONFIG_FORTIFY_SOURCE

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/7] CONFIG_FORTIFY_SOURCE Kees Cook <keescook@chromium.org> - 2017-06-19 22:30 +0200
    [PATCH 3/7] kexec_file: Adjust declaration of kexec_purgatory Kees Cook <keescook@chromium.org> - 2017-06-19 22:30 +0200
    [PATCH 5/7] powerpc: Don't fortify prom_init Kees Cook <keescook@chromium.org> - 2017-06-19 22:30 +0200
    [PATCH 1/7] efi: Avoid fortify checks in EFI stub Kees Cook <keescook@chromium.org> - 2017-06-19 22:30 +0200
    Re: [PATCH 0/7] CONFIG_FORTIFY_SOURCE Andrew Morton <akpm@linux-foundation.org> - 2017-06-20 00:00 +0200
      Re: [PATCH 0/7] CONFIG_FORTIFY_SOURCE Kees Cook <keescook@chromium.org> - 2017-06-20 00:20 +0200
        Re: [PATCH 0/7] CONFIG_FORTIFY_SOURCE Andrew Morton <akpm@linux-foundation.org> - 2017-06-20 00:40 +0200

#1669916 — [PATCH 0/7] CONFIG_FORTIFY_SOURCE

Here are the outstanding fixes for CONFIG_FORTIFY_SOURCE, along with Daniel's
v5 patch and a tweak from me to add CONFIG_ARCH_HAS_FORTIFY_SOURCE to avoid
failing the build on architectures that have not hunted down all the needed
fixes yet.

This was in my for-next/kspp tree, but since it depends on fixes in other
trees, the preference is for these to all get carried in -mm instead of
in KSPP. The extra needed fixes in -next are:

        scsi: csiostor: Avoid content leaks and casts
        arm64, vdso: Define vdso_{start,end} as array
        staging/rts5208: Fix read overflow in memcpy
        libertas: Avoid reading past end of buffer
        ray_cs: Avoid reading past end of buffer

All the other fixes are already in Linus's tree.

-Kees

[toc] | [next] | [standalone]

#1669917 — [PATCH 3/7] kexec_file: Adjust declaration of kexec_purgatory

Defining kexec_purgatory as a zero-length char array upsets compile
time size checking. Since this is built on a per-arch basis, define
it as an unsized char array (like is done for other similar things,
e.g. linker sections). This silences the warning generated by the future
CONFIG_FORTIFY_SOURCE, which did not like the memcmp() of a "0 byte"
array. This drops the __weak and uses an extern instead, since both
users define kexec_purgatory.

Cc: Daniel Micay <danielmicay@gmail.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
 kernel/kexec_file.c     | 7 -------
 kernel/kexec_internal.h | 2 ++
 2 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index b118735fea9d..7a147a7add2e 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -26,13 +26,6 @@
 #include <linux/vmalloc.h>
 #include "kexec_internal.h"
 
-/*
- * Declare these symbols weak so that if architecture provides a purgatory,
- * these will be overridden.
- */
-char __weak kexec_purgatory[0];
-size_t __weak kexec_purgatory_size = 0;
-
 static int kexec_calculate_store_digests(struct kimage *image);
 
 /* Architectures can provide this probe function */
diff --git a/kernel/kexec_internal.h b/kernel/kexec_internal.h
index 799a8a452187..50dfcb039a41 100644
--- a/kernel/kexec_internal.h
+++ b/kernel/kexec_internal.h
@@ -17,6 +17,8 @@ extern struct mutex kexec_mutex;
 #ifdef CONFIG_KEXEC_FILE
 #include <linux/purgatory.h>
 void kimage_file_post_load_cleanup(struct kimage *image);
+extern char kexec_purgatory[];
+extern size_t kexec_purgatory_size;
 #else /* CONFIG_KEXEC_FILE */
 static inline void kimage_file_post_load_cleanup(struct kimage *image) { }
 #endif /* CONFIG_KEXEC_FILE */
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1669918 — [PATCH 5/7] powerpc: Don't fortify prom_init

From: Daniel Axtens <dja@axtens.net>

prom_init is a bit special; in theory it should be able to be
linked separately to the kernel. To keep this from getting too
complex, the symbols that prom_init.c uses are checked.

Fortification adds symbols, and it gets quite messy as it includes
things like panic(). So just don't fortify prom_init.c for now.

Cc: Kees Cook <keescook@chromium.org>
Cc: Daniel Micay <danielmicay@gmail.com>
Signed-off-by: Daniel Axtens <dja@axtens.net>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 arch/powerpc/kernel/prom_init.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index dd8a04f3053a..613f79f03877 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -15,6 +15,9 @@
 
 #undef DEBUG_PROM
 
+/* we cannot use FORTIFY as it brings in new symbols */
+#define __NO_FORTIFY
+
 #include <stdarg.h>
 #include <linux/kernel.h>
 #include <linux/string.h>
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1669919 — [PATCH 1/7] efi: Avoid fortify checks in EFI stub

This avoids CONFIG_FORTIFY_SOURCE from being enabled during the EFI stub
build, as adding a panic() implementation may not work well. This can be
adjusted in the future.

Suggested-by: Daniel Micay <danielmicay@gmail.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Mark Rutland <mark.rutland@arm.com>
---
 drivers/firmware/efi/libstub/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
index f7425960f6a5..37e24f525162 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -17,6 +17,7 @@ cflags-$(CONFIG_ARM)		:= $(subst -pg,,$(KBUILD_CFLAGS)) \
 cflags-$(CONFIG_EFI_ARMSTUB)	+= -I$(srctree)/scripts/dtc/libfdt
 
 KBUILD_CFLAGS			:= $(cflags-y) -DDISABLE_BRANCH_PROFILING \
+				   -D__NO_FORTIFY \
 				   $(call cc-option,-ffreestanding) \
 				   $(call cc-option,-fno-stack-protector)
 
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1669983

On Mon, 19 Jun 2017 13:26:20 -0700 Kees Cook <keescook@chromium.org> wrote:

> Here are the outstanding fixes for CONFIG_FORTIFY_SOURCE, along with Daniel's
> v5 patch and a tweak from me to add CONFIG_ARCH_HAS_FORTIFY_SOURCE to avoid
> failing the build on architectures that have not hunted down all the needed
> fixes yet.
> 
> This was in my for-next/kspp tree, but since it depends on fixes in other
> trees, the preference is for these to all get carried in -mm instead of
> in KSPP.

All the patches you sent are already in -next (from the kspp tree?) so
I can't use them.

> The extra needed fixes in -next are:
> 
>         scsi: csiostor: Avoid content leaks and casts
>         arm64, vdso: Define vdso_{start,end} as array
>         staging/rts5208: Fix read overflow in memcpy
>         libertas: Avoid reading past end of buffer
>         ray_cs: Avoid reading past end of buffer

These didn't get sent out?

If the kspp tree is already in -next then how about leaving things that
way, and send Linus a pull request for -rc1?

[toc] | [prev] | [next] | [standalone]

#1670003

On Mon, Jun 19, 2017 at 2:50 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Mon, 19 Jun 2017 13:26:20 -0700 Kees Cook <keescook@chromium.org> wrote:
>
>> Here are the outstanding fixes for CONFIG_FORTIFY_SOURCE, along with Daniel's
>> v5 patch and a tweak from me to add CONFIG_ARCH_HAS_FORTIFY_SOURCE to avoid
>> failing the build on architectures that have not hunted down all the needed
>> fixes yet.
>>
>> This was in my for-next/kspp tree, but since it depends on fixes in other
>> trees, the preference is for these to all get carried in -mm instead of
>> in KSPP.
>
> All the patches you sent are already in -next (from the kspp tree?) so
> I can't use them.

Err... that's what you asked me to send? And I had removed them from
kspp so you could carry them.

>> The extra needed fixes in -next are:
>>
>>         scsi: csiostor: Avoid content leaks and casts
>>         arm64, vdso: Define vdso_{start,end} as array
>>         staging/rts5208: Fix read overflow in memcpy
>>         libertas: Avoid reading past end of buffer
>>         ray_cs: Avoid reading past end of buffer
>
> These didn't get sent out?

These are all already in -next from other non-kspp trees. I was just
trying to be complete about showing where all the needed fixes were.

> If the kspp tree is already in -next then how about leaving things that
> way, and send Linus a pull request for -rc1?

*sob* I'm happy to do that. I just want you and sfr to agree. :P If I
carry them in my kspp tree, it'll depend on -next (which I'm fine
with, but sfr does not like).

I can add it all back to kspp, just let me what you both can agree on. :P

-Kees

-- 
Kees Cook
Pixel Security

[toc] | [prev] | [next] | [standalone]

#1670012

On Mon, 19 Jun 2017 15:12:22 -0700 Kees Cook <keescook@chromium.org> wrote:

> >> This was in my for-next/kspp tree, but since it depends on fixes in other
> >> trees, the preference is for these to all get carried in -mm instead of
> >> in KSPP.
> >
> > All the patches you sent are already in -next (from the kspp tree?) so
> > I can't use them.
> 
> Err... that's what you asked me to send? And I had removed them from
> kspp so you could carry them.

Oh, OK, I'll take a look later in the week after -next has caught up.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web