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: <1377086465-6471-1-git-send-email-heiko.carstens@de.ibm.com>
Date:	Wed, 21 Aug 2013 14:01:02 +0200
From:	Heiko Carstens <heiko.carstens@...ibm.com>
To:	Andrew Morton <akpm@...ux-foundation.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Ingo Molnar <mingo@...nel.org>,
	Martin Schwidefsky <schwidefsky@...ibm.com>
Cc:	linux-kernel@...r.kernel.org,
	Heiko Carstens <heiko.carstens@...ibm.com>
Subject: [PATCH 0/3] kprobes: add new dma insn slot cache for s390

The current kpropes insn caches allocate memory areas for insn slots with
module_alloc(). The assumption is that the kernel image and module area
are both within the same +/- 2GB memory area.
This however is not true for s390 where the kernel image resides within
the first 2GB (DMA memory area), but the module area is far away in the
vmalloc area, usually somewhere close below the 4TB area.

For new pc relative instructions s390 needs insn slots that are within
+/- 2GB of each area. That way we can patch displacements of pc-relative
instructions within the insn slots just like x86 and powerpc.

The module area works already with the normal insn slot allocator, however
there is currently no way to get insn slots that are within the first 2GB
on s390 (aka DMA area).

Therefore this patch set introduces a third insn slot cache besides the
normal insn and optinsn slot caches: the dmainsn slot cache. Slots can be
allocated and freed with get_dmainsn_slot() and free_dmainsn_slot().

Patch 1 unifies the current insn and optinsn caches implementation so we
don't end up with a lot of code duplication when adding a third cache.

Patch 2 simply adds the new dmainsn slot cache.

Patch 3 is the s390 usage of the new cache.

Looking at the last couple of sign-off chains I'm not sure how kprobes
patches should go upstream.. Andrew, Ingo, or simply via the s390 tree?

Heiko Carstens (3):
  kprobes: unify insn caches
  kprobes: provide new dmainsn cache
  s390/kprobes: add support for pc-relative long displacement instructions

 arch/Kconfig                    |    7 +++
 arch/s390/Kconfig               |    1 +
 arch/s390/include/asm/kprobes.h |    4 +-
 arch/s390/kernel/kprobes.c      |  124 ++++++++++++++++++++++++++++++++++++---
 include/linux/kprobes.h         |   31 ++++++++--
 kernel/kprobes.c                |   98 +++++++++++++++----------------
 6 files changed, 203 insertions(+), 62 deletions(-)

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