linux-kernel - Re: Have any influence on set_memory

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-next>] [day] [month] [year] [list]

Date:	Tue, 12 Jan 2016 09:20:54 +0800
From:	Xishi Qiu <qiuxishi@...wei.com>
To:	Mark Rutland <mark.rutland@....com>
CC:	zhong jiang <zhongjiang@...wei.com>,
	Laura Abbott <labbott@...oraproject.org>,
	Hanjun Guo <guohanjun@...wei.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Have any influence on set_memory_** about below patch ??

On 2016/1/11 21:31, Mark Rutland wrote:

> Hi,
> 
> On Mon, Jan 11, 2016 at 08:59:44PM +0800, zhong jiang wrote:
>>
>> http://www.spinics.net/lists/arm-kernel/msg472090.html
>>
>> Hi, Can I ask you a question? Say, This patch tells that the section spilting
>> and merging wiil produce confilct in the liner mapping area. Based on the
>> situation, Assume that set up page table in 4kb page table way in the liner
>> mapping area, Does the set_memroy_** will work without any conplict??
> 
> I'm not sure I understand the question.
> 
> I'm also not a fan of responding to off-list queries as information gets
> lost.
> 
> Please ask your question on the mailing list. I am more than happy to
> respond there.
> 
> Thanks,
> Mark.
> 

Hi Mark,

In your patch it said "The presence of conflicting TLB entries may result in
a variety of behaviours detrimental to the system " and "but this(break-before-make
approach) cannot work for modifications to the swapper page tables that cover the
kernel text and data."

I'm not quite understand this, why the direct mapping can't work?
flush tlb can't resolve it?

I find x86 does not have this limit. e.g. set_memory_r*.

Thanks,
Xishi Qiu

> .
>