linux-kernel - [PATCH 0/8] x86: Disentangle the vdso and clean it up

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]

Message-Id: <cover.1411494540.git.luto@amacapital.net>
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/