linux-kernel - Re: [PATCH] i386: For debugging, make the initial page table setup less forgiving.

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: <m11wi6jtoi.fsf@ebiederm.dsl.xmission.com>
Date:	Thu, 26 Apr 2007 23:02:53 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andi Kleen <ak@...e.de>, Zachary Amsden <zach@...are.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] i386: For debugging, make the initial page table setup less forgiving.

Jeremy Fitzhardinge <jeremy@...p.org> writes:

>> I suspect what we want to do is come up with a function to call
>> to test to see if a page should be read-only and map such pages
>> _PAGE_KERNEL_RO, or _PAGE_KERNEL_RO_EXEC if it's code.
>>   
>
> Hm, I think that's a hard function to write in general. For the special
> case of pagetable_init it wouldn't be too hard, but it doesn't seem like
> a big improvement over the current state of affairs.

There is some difficulty there, and I need to look at the issue some more
but it just occurred to me that this problem of tracking special permissions
on pages is not confined to Xen.

Currently for pages we need to have a consistent global view if a pages
is uncached, write-combining or cached.  We need a way to check this so
that we don't get inconsistencies in how we are caching pages, when
we start controlling this on a per page basis.

Currently we are not doing this and it is blocking merging of PAT
write-combining support in the kernel because of the bad things
(silent data corruption and general cpu undefined behavior) that can
happen if we don't handling things consistently.

I don't know if we can solve the two problems with the same mechanism
but it is worth looking into.

Especially if what we do is just add support for marking some pages
as read-only.  We could use that ensuring there are no writable
mappings of the kernel's text segment for example.

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