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-next>] [day] [month] [year] [list]
Message-Id: <1441438363-9999-1-git-send-email-mingo@kernel.org>
Date:	Sat,  5 Sep 2015 09:32:28 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	linux-kernel@...r.kernel.org
Cc:	Mikko Rapeli <mikko.rapeli@....fi>,
	Andy Lutomirski <luto@...capital.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Brian Gerst <brgerst@...il.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Borislav Petkov <bp@...en8.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: [PATCH 00/15] x86/headers: Clean up sigcontext types and headers

So Mikko Rapeli reported that sigcontext32.h does not build standalone,
and while trying to fix it I came up with this series that cleans up
all sorts of details and makes the sigcontext types (hopefully) much
more maintainable.

Before this series we had a somewhat messy duplication that resulted
in 3 type definitions (repeated for both sigcontext and for various
FPU state structures):

  - native 32-bit types      (only available on 32-bit kernels)
  - native 64-bit types      (only available on 64-bit kernels)
  - compat 32-bit types      (only available on 64-bit kernels)
  - wrappers defining _32 named variants of these types

... while in reality our compat 32-bit ABI structures are the same as
the native 32-bit ABI structures.

So after the series there's a clear, bitness independent definition
of all the relevant types:

	struct sigcontext_32  (available on all kernels)
	struct sigcontext_64  (available on all kernels)

	struct _fpstate_32    (available on all kernels)
	struct _fpstate_64    (available on all kernels)

and the kernel bitness dependent 'struct sigcontext' and 'struct _fpstate'
structures are then mapped to their respective types, depending on bitness.

Modern user-space can start using these cleaner types. (If they want to: all
old names are kept as well).

I have also extended/harmonized all the disjunct (and often hard to read)
comments in the various structure definitions. The patches add a lot of
new comments, this is why the diffstat shows only a modest line count
reduction:

 13 files changed, 324 insertions(+), 338 deletions(-)

Another effect of the series is that sigcontext32.h is gone (only
a wrapper to sigcontext.h is kept, in case existing user-space relies
on the header), and the kernel side asm/sigcontext.h file is gone as
well. This should solve the original build failure reported by Mikko
Rapeli.

All legacy names are still kept to make sure we don't break user-space
builds, and are collected at the end of the file, without confusing people
who'd only like to read the file to understand the kernel side code.

The various _ia32 names are mostly gone as well from the kernel side,
compatibility wrappers are kept for the user-space side.

There's one new type quirk in patch 11, which is the result of having unified
C code operating on a 32-bit pointer field both from 64-bit kernel and from
a native 32-bit kernel:

 int restore_sigcontext(struct pt_regs *regs, struct sigcontext __user *sc)
 {
 +       unsigned long buf_val;

 -               get_user_ex(buf, &sc->fpstate);
 +               get_user_ex(buf_val, &sc->fpstate);
 +               buf = (void __user *)buf_val;

this is the cleanest I could structure it. If this is the only quirk then I
think the advantages outweigh the ugliness - BYMMV.

So in general this is how I imagine our model should be to define ABIs
going forward.

Comments, suggestions are welcome!

    Ingo

============================>
Ingo Molnar (15):
  x86/headers: Fix (old) header file dependency bug in uapi/asm/sigcontext32.h
  x86/headers: Clean up uapi/asm/sigcontext32.h
  x86/headers: Clean up and better document uapi/asm/sigcontext.h
  x86/headers: Separate out legacy user-space structure definitions
  x86/headers: Use ABI types consistently in sigcontext*.h
  x86/headers: Unify register type definitions between 32-bit compat and i386
  x86/headers: Unify 'struct _fpstate_ia32' and i386 struct _fpstate
  x86/headers: Convert uses of _fpstate_ia32 to _fpstate_32
  x86/headers: Clean up the kernel's struct sigcontext types to be ABI-clean
  x86/headers: Move the 'struct sigcontext' definitions into the UAPI header
  x86/headers: Make sigcontext pointers bit independent
  x86/headers: Unify 'struct sigcontext_ia32' and 'struct sigcontext_32'
  x86/headers: Convert sigcontext_ia32 uses to sigcontext_32
  x86/headers: Remove direct sigcontext32.h uses
  x86/headers: Remove <asm/sigcontext.h>

 arch/x86/ia32/ia32_signal.c              |   8 +-
 arch/x86/include/asm/fpu/signal.h        |   2 +-
 arch/x86/include/asm/ia32.h              |   4 +-
 arch/x86/include/asm/processor.h         |   2 +-
 arch/x86/include/asm/sigcontext.h        |  79 ------
 arch/x86/include/asm/sigframe.h          |   8 +-
 arch/x86/include/asm/signal.h            |   2 +-
 arch/x86/include/uapi/asm/sigcontext.h   | 456 ++++++++++++++++++++-----------
 arch/x86/include/uapi/asm/sigcontext32.h |  73 +----
 arch/x86/kernel/asm-offsets.c            |  18 +-
 arch/x86/kernel/fpu/signal.c             |   4 +-
 arch/x86/kernel/signal.c                 |   4 +-
 arch/x86/math-emu/fpu_emu.h              |   2 +-
 13 files changed, 324 insertions(+), 338 deletions(-)
 delete mode 100644 arch/x86/include/asm/sigcontext.h

-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ