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]
Message-ID: <8707b178-15e0-1ca0-5612-f42d771446cc@imgtec.com>
Date:   Tue, 20 Dec 2016 16:21:44 +0100
From:   Marcin Nowakowski <marcin.nowakowski@...tec.com>
To:     Oleg Nesterov <oleg@...hat.com>,
        tip-bot for Marcin Nowakowski <tipbot@...or.com>
CC:     <linux-tip-commits@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <peterz@...radead.org>,
        <alexander.shishkin@...ux.intel.com>, <acme@...nel.org>,
        <acme@...hat.com>, <mingo@...nel.org>,
        <victor.kamensky@...aro.org>, <jolsa@...hat.com>, <hpa@...or.com>,
        <torvalds@...ux-foundation.org>, <tglx@...utronix.de>
Subject: Re: [tip:perf/urgent] uprobes: Fix uprobes on MIPS, allow for a cache
 flush after ixol breakpoint creation

Hi Oleg,

On 20.12.2016 14:08, Oleg Nesterov wrote:
> On 12/19, tip-bot for Marcin Nowakowski wrote:
>>
>> uprobes: Fix uprobes on MIPS, allow for a cache flush after ixol breakpoint creation
>>
>> Commit:
>>
>>   72e6ae285a1d ('ARM: 8043/1: uprobes need icache flush after xol write'
>>
>> ... has introduced an arch-specific method to ensure all caches are
>> flushed appropriately after an instruction is written to an XOL page.
>
> when this page is already mmaped,
>
>> However, when the XOL area is created and the out-of-line breakpoint
>> instruction is copied, caches are not flushed at all and stale data may
>> be found in icache.
>
> but in this case the page is not mmaped yet, the probed application will
> take a page fault if it tries to execute this insn,

In case of MIPS (and AFAICT ARM as well, and these are the only 
architectures that implement arch_uprobe_copy_ixol), the cache flushing 
is done through the kernel addresses of that page, so the fact that it 
is not mapped yet is not an issue.

Do I understand correctly that your statement implies that after the 
page fault and mmapping the xol page, the page is guaranteed to be 
updated in the cache? As definitely that is not something that is 
happening at the moment.


>> Replace a simple copy_to_page() with arch_uprobe_copy_ixol() to allow
>> the arch to ensure all caches are updated accordingly.
>>
>> This change fixes uprobes on MIPS InterAptiv (tested on Creator Ci40).
>
> OK, I know nothing about MIPS, but could you help me understand this change?
>
> See above. If we really need flush_icache_range() here then perhaps we should
> modify install_special_mapping() and/or __do_fault/special_mapping_fault paths
> instead?

Are you suggesting that those should be updated to force a cache update?

Marcin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ