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:	Wed, 12 Nov 2014 14:41:04 +0100
From:	Thierry Reding <thierry.reding@...il.com>
To:	Ralf Baechle <ralf@...ux-mips.org>
Cc:	Paul Burton <paul.burton@...tec.com>, linux-mips@...ux-mips.org,
	Alexander Viro <viro@...iv.linux.org.uk>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 03/10] binfmt_elf: allow arch code to examine PT_LOPROC
 ... PT_HIPROC headers

On Thu, Sep 11, 2014 at 08:30:16AM +0100, Paul Burton wrote:
> MIPS is introducing new variants of its O32 ABI which differ in their
> handling of floating point, in order to enable a gradual transition
> towards a world where mips32 binaries can take advantage of new hardware
> features only available when configured for certain FP modes. In order
> to do this ELF binaries are being augmented with a new section that
> indicates, amongst other things, the FP mode requirements of the binary.
> The presence & location of such a section is indicated by a program
> header in the PT_LOPROC ... PT_HIPROC range.
> 
> In order to allow the MIPS architecture code to examine the program
> header & section in question, pass all program headers in this range
> to an architecture-specific arch_elf_pt_proc function. This function
> may return an error if the header is deemed invalid or unsuitable for
> the system, in which case that error will be returned from
> load_elf_binary and upwards through the execve syscall.
> 
> A means is required for the architecture code to make a decision once
> it is known that all such headers have been seen, but before it is too
> late to return from an execve syscall. For this purpose the
> arch_check_elf function is added, and called once, after all PT_LOPROC
> to PT_HIPROC headers have been passed to arch_elf_pt_proc but before
> the code which invoked execve has been lost. This enables the
> architecture code to make a decision based upon all the headers present
> in an ELF binary and its interpreter, as is required to forbid
> conflicting FP ABI requirements between an ELF & its interpreter.
> 
> In order to allow data to be stored throughout the calls to the above
> functions, struct arch_elf_state is introduced.
> 
> Finally a variant of the SET_PERSONALITY macro is introduced which
> accepts a pointer to the struct arch_elf_state, allowing it to act
> based upon state observed from the architecture specific program
> headers.
> 
> Signed-off-by: Paul Burton <paul.burton@...tec.com>
> ---
>  fs/Kconfig.binfmt   |  3 +++
>  fs/binfmt_elf.c     | 36 ++++++++++++++++++++++++--
>  include/linux/elf.h | 73 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 110 insertions(+), 2 deletions(-)

Hi Ralf,

This commit showed up in linux-next and causes a warning in linux/elf.h
because it doesn't know struct file. I've fixed it locally with this:

---
diff --git a/include/linux/elf.h b/include/linux/elf.h
index 6bd15043a585..dac5caaa3509 100644
--- a/include/linux/elf.h
+++ b/include/linux/elf.h
@@ -4,6 +4,8 @@
 #include <asm/elf.h>
 #include <uapi/linux/elf.h>
 
+struct file;
+
 #ifndef elf_read_implies_exec
   /* Executables for which elf_read_implies_exec() returns TRUE will
      have the READ_IMPLIES_EXEC personality flag set automatically.
---

Would you mind squashing that into the above commit to get rid of the
warning?

Thierry

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists