linux-kernel - Re: testing pmdval/pteval page presence bit

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

Message-ID: <49931E24.6080409@goop.org>
Date:	Wed, 11 Feb 2009 10:51:16 -0800
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Pekka Paalanen <pq@....fi>
CC:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Vegard Nossum <vegard.nossum@...il.com>,
	Stuart Bennett <stuart@...edesktop.org>,
	Oliver McFadden <z3ro.geek@...il.com>,
	david jeannot <djeannot24@...il.com>
Subject: Re: testing pmdval/pteval page presence bit

Pekka Paalanen wrote:
> This is good to know. So far these are kernel mappings, as they are all
> created by ioremap*(), but there are plans to extend mmiotrace to
> trace IO-mappings accessed from user space. Do you have hints for that?
>   

Set _PAGE_PROTNONE, which will make the kernel logically treat it as a 
present pte with no page permissions, which is what you're doing.  Bear 
in mind that _PAGE_PROTNONE is overloaded with _PAGE_GLOBAL, so you'll 
need to make sure you restore that properly too (kernel mappings are 
generally global).

On the other hand, I assume you intercept mmiotrace faults fairly early 
in the fault handler, so that path shouldn't ever see an unexpected 
not-present pte.  But other code, like mprotect, mlock, etc, may inspect 
those ptes and get a nasty surprise if it sees them non-present.

(What happens if someone uses mprotect on a mapping that mmiotrace has 
made non-present?)

> OTOH, we are always dealing with PCI IO-mem-mappings, so would those ever
> be not present, excluding the mmiotrace case?
>
> Well, Stuart already found out that the kernel ioremap*()'ed pages might
> not really be present, there are some fixes coming up to mmiotrace to
> cope with that. The plan is to restore the state of the pte like it was
> before mmiotrace cleared the _PAGE_PRESENT flag, and if the same
> instruction and address faults again, fall through to the normal page
> fault handling. How can/will this fail? And if it is a user page?
>   

My main concern is non-fault handler code which looks at ptes.  How will 
it know what its looking at if mmiotrace has fiddled with the state?

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