linux-kernel - Some questions about DEBUG

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: <53F739C2.8070809@linaro.org>
Date:	Fri, 22 Aug 2014 20:38:26 +0800
From:	"zhichang.yuan" <zhichang.yuan@...aro.org>
To:	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <Will.Deacon@....com>
CC:	Deepak Saxena <dsaxena@...aro.org>, linux-kernel@...r.kernel.org
Subject: Some questions about DEBUG_PAGEALLOC on ARMv8

Hi Catalin, Will,

I am working to implement the DEBUG_PAGEALLOC on ARMv8.
After i investigated the DEBUG_PAGEALLOC implementation on x86 arch, some questions are standing in the way to
start coding.

1. How to handle the large page when DEBUG_PAGEALLOC is enabled
In ARMv8, the kernel direct memory page table entries will set the block flag for better performance. When
DEBUG_PAGEALLOC is configured, if the size of freed page is not multiply of page block size, there is no
corresponding page table entry. In the old x86 kernel version, the large page to be freed will be split into
normal page size and build the corresponding PTEs. And afterwards, someone done a patch to remove the
splitting process. It will make the code simpler and easily stable.

I prefer the current design in x86, what are your thoughts here?

2. Does ARMv8 support HIBERNATION?

The HIBERNATION has some dependency on DEBUG_PAGEALLOC.
It seems that current kernel does not support hibernation, does it?

3. Is the hypothesis of DEBUG_PAGEALLOC always true?

>From the x86 code, DEBUG_PAGEALLOC use the invalid page table entries to catch the accesses to free pages.
This mechanism is based on the hypothesis that all the corresponding page table entries that are corresponding
to the free pages are cleared correctly. Supposed this condition is always true, what we need to do is just to
clear the kernel linear mapping page entries, since those page tables are fixable after initialization.
DEBUG_PAGEALLOC on x86 seems to do like that.

Is it possible the hypothesis will be broken?
If the answer is yes, DEBUG_PAGEALLOC can catch the accesses to free page with kernel linear mapping address.
But if the virtual address is from other mapped areas and target to the free pages, DEBUG_PAGEALLOC will do
nothing.

Is this result the original objective of DEBUG_PAGEALLOC?
I can not find the initial commit log in kernel Git, i am not sure about it.

Thanks!
Zhichang
--
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/