linux-kernel - Re: [PATCH 0/3] kprobes: add new dma insn slot cache for s390

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:	Thu, 22 Aug 2013 11:21:54 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	Heiko Carstens <heiko.carstens@...ibm.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Ingo Molnar <mingo@...nel.org>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] kprobes: add new dma insn slot cache for s390

Hi Heiko,

(2013/08/21 21:01), Heiko Carstens wrote:
> 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).

The reason why we allocate instruction buffers from module area is
to execute a piece of code on the buffer, which should be executable.
I'm not good for s390, is that allows kernel to execute the code
on such DMA buffer?

> 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().

OK, but it seems that your patch introduced unneeded complexity. Perhaps,
you just have to introduce 2 weak functions to allocate/release such
executable and jump-able buffers, like below,

void * __weak arch_allocate_executable_page(void)
{
	return module_alloc(PAGE_SIZE);
}

void __weak arch_free_executable_page(void *page)
{
	module_free(NULL, page);
}

Thus, all you need to do is implementing dmaalloc() version of above
functions on s390. No kconfig, no ifdefs are needed. :)

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

Hmm, AFAIK, currently all noarch kprobes works go to -tip tree, and
the arch dependent parts go to each arch tree (only x86 goes to -tip tree).

Thank you,

-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@...achi.com


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