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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 9 Mar 2018 15:25:56 +0100
From:   Philipp Rudo <prudo@...ux.vnet.ibm.com>
To:     Dave Young <dyoung@...hat.com>
Cc:     linux-s390@...r.kernel.org,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        AKASHI Takahiro <takahiro.akashi@...aro.org>,
        Michael Ellerman <mpe@...erman.id.au>, x86@...nel.org,
        kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Martin Schwidefsky <schwidefsky@...ibm.com>,
        Eric Biederman <ebiederm@...ssion.com>,
        Thiago Jung Bauermann <bauerman@...ux.vnet.ibm.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Vivek Goyal <vgoyal@...hat.com>
Subject: Re: [PATCH 00/11] kexec_file: Clean up purgatory load

Hi Dave,

On Fri, 9 Mar 2018 13:19:40 +0800
Dave Young <dyoung@...hat.com> wrote:

> Hi Philipp,
> On 02/26/18 at 04:16pm, Philipp Rudo wrote:
> > 
> > Hi everybody
> > 
> > following the discussion with Dave and AKASHI, here are the common code
> > patches extracted from my recent patch set (Add kexec_file_load support to
> > s390) [1]. The patches were extracted to allow upstream integration together
> > with AKASHI's common code patches before the arch code gets adjusted to the
> > new base.
> > 
> > The reason for this series is to prepare common code for adding
> > kexec_file_load to s390 as well as cleaning up the mis-use of the sh_offset
> > field during purgatory load. In detail this series contains:
> > 
> > Patch #1&2: Minor cleanups/fixes.
> > 
> > Patch #3-9: Clean up the purgatory load/relocation code. Especially remove
> > the mis-use of the purgatory_info->sechdrs->sh_offset field, currently
> > holding a pointer into either kexec_purgatory (ro) or purgatory_buf (rw)
> > depending on the section. With these patches the section address will be
> > calculated verbosely and sh_offset will contain the offset of the section
> > in the stripped purgatory binary (purgatory_buf).
> > 
> > Patch #10: Allows architectures to set the purgatory load address. This
> > patch is important for s390 as the kernel and purgatory have to be loaded
> > to fixed addresses. In current code this is impossible as the purgatory
> > load is opaque to the architecture.
> > 
> > Patch #11: Moves x86 purgatories sha implementation to common lib/
> > directory to allow reuse in other architectures.
> > 
> > The patches apply to v4.16-rc3. There are no changes compared to [1] (all
> > requested changes only affected s390 code). Please note that I had to touch
> > arch code for x86 and power a little. In theory this should not change the
> > behavior but I don't have a way to test it. Cross-compiling with
> > defconfig [2] works fine for both.
> > 
> > Thanks
> > Philipp
> > 
> > [1] http://lists.infradead.org/pipermail/kexec/2018-February/019926.html
> > [2] On x86 with the orc unwinder and stack validation turned off. objtool
> >     SEGFAULTs on s390...
> > 
> > Philipp Rudo (11):
> >   kexec_file: Silence compile warnings
> >   kexec_file: Remove checks in kexec_purgatory_load
> >   kexec_file: Make purgatory_info->ehdr const
> >   kexec_file: Search symbols in read-only kexec_purgatory
> >   kexec_file: Use read-only sections in arch_kexec_apply_relocations*
> >   kexec_file: Split up __kexec_load_puragory
> >   kexec_file: Simplify kexec_purgatory_setup_sechdrs 1
> >   kexec_file: Simplify kexec_purgatory_setup_sechdrs 2
> >   kexec_file: Remove mis-use of sh_offset field
> >   kexec_file: Allow archs to set purgatory load address
> >   kexec_file: Move purgatories sha256 to common code
> > 
> >  arch/powerpc/kernel/kexec_elf_64.c             |   9 +-
> >  arch/x86/kernel/kexec-bzimage64.c              |   8 +-
> >  arch/x86/kernel/machine_kexec_64.c             |  66 ++---
> >  arch/x86/purgatory/Makefile                    |   3 +
> >  arch/x86/purgatory/purgatory.c                 |   2 +-
> >  include/linux/kexec.h                          |  38 +--
> >  {arch/x86/purgatory => include/linux}/sha256.h |  10 +-
> >  kernel/kexec_file.c                            | 375 ++++++++++++-------------
> >  {arch/x86/purgatory => lib}/sha256.c           |   4 +-
> >  9 files changed, 244 insertions(+), 271 deletions(-)
> >  rename {arch/x86/purgatory => include/linux}/sha256.h (63%)
> >  rename {arch/x86/purgatory => lib}/sha256.c (99%)
> > 
> > -- 
> > 2.13.5
> >   
> 
> I did a test on x86, but it failed:
> [   15.636489] kexec: Undefined symbol: memcpy
> [   15.636496] kexec-bzImage64: Loading purgatory failed
> [   33.603356] kexec: Undefined symbol: memcpy
> [   33.603362] kexec-bzImage64: Loading purgatory failed
> 
> I think this relates to the sha256 splitting patch.

I looked into this a little closer and i think i understood what happens. 

There is no definition of memcpy in arch/x86/boot/string.c, instead it's defined
in arch/x86/boot/string.h as __buildin_memcpy (same for memset). Thus by
switching to linux/string.h there is no more definition for it. Leaving us with

$ readelf -s purgatory.ro
[...]
 45: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND memcpy
[...]

To solve this problem I see two possibilities (example patches are at the end of
the mail):

1) Have arch dependent includes in lib/sha256.c
2) Add makefile magic so memcpy is defined

With both solutions the resulting purgatory.ro looks good. However both
solutions aren't perfect. For example in 2) i had too mix the linux/string.h
header with arch/x86/boot/string.c, because lib/string.c has too many
dependencies and does not compile in the purgatory. On the other hand having
arch dependent includes isn't that nice either ...

What's your opinion on this?

Thanks
Philipp

-----
Example solution 1

--- a/lib/sha256.c
+++ b/lib/sha256.c
@@ -17,9 +17,14 @@
 
 #include <linux/bitops.h>
 #include <linux/sha256.h>
-#include <linux/string.h>
 #include <asm/byteorder.h>
 
+#ifdef CONFIG_X86
+#include "../arch/x86/boot/string.h"
+#else
+#include <linux/string.h>
+#endif /* CONFIG_X86 */
+
 static inline u32 Ch(u32 x, u32 y, u32 z)
 {
 	return z ^ (x & (y ^ z));

-----
Example solution 2

--- a/arch/x86/purgatory/Makefile
+++ b/arch/x86/purgatory/Makefile
@@ -1,7 +1,8 @@
 # SPDX-License-Identifier: GPL-2.0
 OBJECT_FILES_NON_STANDARD := y
 
-purgatory-y := purgatory.o stack.o setup-x86_$(BITS).o sha256.o entry64.o string.o
+purgatory-y := purgatory.o stack.o setup-x86_$(BITS).o sha256.o entry64.o \
+	string.o memcpy_$(BITS).o memset_$(BITS).o
 
 targets += $(purgatory-y)
 PURGATORY_OBJS = $(addprefix $(obj)/,$(purgatory-y))
@@ -9,6 +10,15 @@ PURGATORY_OBJS = $(addprefix $(obj)/,$(purgatory-y))
 $(obj)/sha256.o: $(srctree)/lib/sha256.c
 	$(call if_changed_rule,cc_o_c)
 
+$(obj)/string.o: $(srctree)/arch/x86/boot/string.c
+	$(call if_changed_rule,cc_o_c)
+
+$(obj)/memset_$(BITS).o: $(srctree)/arch/x86/lib/memset_$(BITS).S
+	$(call if_changed_rule,as_o_S)
+
+$(obj)/memcpy_$(BITS).o: $(srctree)/arch/x86/lib/memcpy_$(BITS).S
+	$(call if_changed_rule,as_o_S)
+
 LDFLAGS_purgatory.ro := -e purgatory_start -r --no-undefined -nostdlib -z nodefaultlib
 targets += purgatory.ro
 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ