linux-kernel - Re: [PATCH] arm64: Fix the ptep_set_wrprotect() to set PTE_DIRTY if (PTE_DBM && !PTE

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:	Wed, 9 Mar 2016 10:06:05 +0000
From:	Catalin Marinas <catalin.marinas@....com>
To:	Ganapatrao Kulkarni <gkulkarni@...iumnetworks.com>
Cc:	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Will.Deacon@....com, dann.frazier@...onical.com,
	gpkulkarni@...il.com
Subject: Re: [PATCH] arm64: Fix the ptep_set_wrprotect() to set PTE_DIRTY if
 (PTE_DBM && !PTE_RDONLY)

On Wed, Mar 09, 2016 at 10:32:48AM +0530, Ganapatrao Kulkarni wrote:
> Commit 2f4b829c625e ("arm64: Add support for hardware updates of the
> access and dirty pte bits") introduced support for handling hardware
> updates of the access flag and dirty status.
> 
> ptep_set_wrprotect is setting PTR_DIRTY if !PTE_RDONLY,
> however by design it suppose to set PTE_DIRTY
> only if (PTE_DBM && !PTE_RDONLY). This patch addes code to
> test and set accordingly.

The reasoning behind the original code is that if !PTE_RDONLY, you have
no way to tell whether the page was written or not since it is already
writable, independent of the DBM. So by clearing the DBM bit (making the
page read-only), we need to ensure that a potential dirty state is
transferred to the software PTE_DIRTY bit.

By checking PTE_DBM && !PTE_RDONLY, you kind of imply that you can have
a page with !PTE_DBM && !PTE_RDONLY. Given that PTE_DBM is actually
PTE_WRITE, PTE_RDONLY must always be set when !PTE_DBM. The bug may be
elsewhere not setting these bits correctly.

> This patch fixes BUG,
> kernel BUG at /build/linux-StrpB2/linux-4.4.0/fs/ext4/inode.c:2394!
> Internal error: Oops - BUG: 0 [#1] SMP

Which bug is this? It's a PageWriteback() check in the for-next/core
branch. What kernel version are you using?

BTW, in 4.5-rc2 we pushed commit ac15bd63bbb2 ("arm64: Honour !PTE_WRITE
in set_pte_at() for kernel mappings"), though not sure that's what you
are hitting.

-- 
Catalin