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 for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 23 Sep 2014 10:50:50 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org
Cc:	linux-kernel@...r.kernel.org, Andy Lutomirski <luto@...capital.net>
Subject: [PATCH 0/8] x86: Disentangle the vdso and clean it up

Hi Ingo and Thomas,

This should all be straightforward.  It's primarily a cleanup, but it
fixes what is arguably a bug in the PER_CPU mechanism.

The first two patches just rearrange code to disentangle the vdso from
the vsyscall emulation code.

The next three patches are tiny.  Patch 3 rewrites the PER_CPU setup
code to make it comprehensible; it has no effect other than clarify.
Patches 4 and 5 fix two problems with the PER_CPU segment that are
apparent after the code has been cleaned up.  (Patch 5 fixes a glitch
that that is almost, but not quote, a security bug.)

Patches 6 and 7 are just cleanups.  Patch 6 removes the "jiffies" vvar,
which has been unused for years.  Patch 7 cleans up some initialization
code.

Patch 8 removes the vvar that selects the getcpu mode.  That vvar
has been unnecessary for a couple of years, ever since alternative
patching has worked in the vdso.

There is a small but non quote zero chance that I will want to revert
patch 8 at some point.  Reverting it will be needed to be able to
disable the TSC (in the CR4.TSC sense) without breaking the vdso, unless
we patch the vdso text.  That being said, I think it'll be a lot less
messy to just patch the vdso text if we do that.

Please consider applying these, or at least applying patches 1-7,
to tip/x86/vdso for 3.18.

Thanks,
Andy


Changes from way back when: This has been floating around since June in
some form. See:
http://lkml.kernel.org/g/cover.1404164803.git.luto@amacapital.net

This version just disentangles the vdso and vsyscall code and does the
vdso cleanups/fixes.  It does *not* contain the PER_CPU removal on
RDTSCP systems, since hpa mentioned that this is potentially
problematic, and, if we were to try it, it should soak in -next for a
*long* time.  It is also heavily cleaned up since last time.


Andy Lutomirski (8):
  x86_64,vsyscall: Move all of the gate_area code to vsyscall_64.c
  x86_64: Move getcpu code from vsyscall_64.c to vdso/vma.c
  x86,vdso: Change the PER_CPU segment to use struct desc_struct
  x86,vdso: Make the PER_CPU segment start out accessed
  x86,vdso: Make the PER_CPU segment 32 bits
  x86_64,vdso: Remove jiffies from the vvar page
  x86_64,vdso: Clean up vgetcpu init and merge the vdso initcalls
  x86,vdso: Replace vgetcpu_mode with static_cpu_has

 arch/x86/include/asm/vgtod.h    | 21 ++++++++++
 arch/x86/include/asm/vsyscall.h | 29 --------------
 arch/x86/include/asm/vvar.h     |  2 -
 arch/x86/kernel/cpu/common.c    | 10 -----
 arch/x86/kernel/time.c          |  2 +-
 arch/x86/kernel/vsyscall_64.c   | 84 ++++++++++++++++++----------------------
 arch/x86/mm/init_64.c           | 49 ------------------------
 arch/x86/vdso/vclock_gettime.c  |  3 ++
 arch/x86/vdso/vgetcpu.c         |  5 ++-
 arch/x86/vdso/vma.c             | 85 ++++++++++++++++++++++++++++++++---------
 10 files changed, 132 insertions(+), 158 deletions(-)

-- 
1.9.3

--
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