linux-kernel - Re: [RFC BUG?] dereference PAGE

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]

Date:	Wed, 02 May 2007 13:13:14 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Bill Irwin <bill.irwin@...cle.com>
Cc:	Jeremy Fitzhardinge <jeremy@...p.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Dan Kruchinin <dubalom@...il.com>,
	linux-kernel@...r.kernel.org,
	Jeremy Fitzhardinge <jeremy@...source.com>,
	Andi Kleen <ak@...e.de>, Ingo Molnar <mingo@...e.hu>
Subject: Re: [RFC BUG?] dereference PAGE_OFFSET address (rc7-mm2)

Bill Irwin <bill.irwin@...cle.com> writes:

> On Wed, May 02, 2007 at 09:28:46AM -0700, Jeremy Fitzhardinge wrote:
>>>> I think this should be fixed now.  Eric made all those writes
>>>> unconditional (to fix a problem with PSE superpages not being created). 
>>>> The patch is in Andi's queue.
>
> Bill Irwin <bill.irwin@...cle.com> writes:
>>> It needs verification with the testcase from this thread.
>
> On Wed, May 02, 2007 at 11:16:27AM -0600, Eric W. Biederman wrote:
>> Sounds reasonable.
>> However there is no reason to suspect it won't fix this case because
>> unconditional writes are what we have always done, and we have always
>> kept swapper_pg_dir from early boot as well.
>> In essence my patch I sent out to Andi was a partial revert.
>
> It would not be so far out to be aware of what pagetable entries were
> carried over from the initial swapper_pg_dir and explicitly clobber
> them (for instance, modifying their protection bits while otherwise
> retaining them).

And that is actually what we do, but without paying attention, when
setting up the identity mappings.

> On Wed, May 02, 2007 at 11:16:27AM -0600, Eric W. Biederman wrote:
>> It isn't slated to go in until nextround but I also rewrote the early
>> page table setup in C.  Allowing set_fixmap to work in the early
>> kernel, and fix problems of not having enough memory mapped to build
>> the identity mappings, because we are then updating the page table
>> we have also in the PAE case.
>
> I'm not sure when we run into those problems, though I understand what
> they are. I suppose it would be good to resolve them.

The nasty one is if you have a kernel sized just right.  All you get
from the early page tables of allocatable memory is the low 640K.  If
you have PSE disabled (because PAGEALLOC_DEBUG is enabled) up only
have enough pages in the mapping to setup a 256M identity mapping unsing
4K pages ouch.

Another issue is that we have boot_ioremap, and bt_ioremap for different
stages of the boot.  Enabling fixmap early solves that.

Then there is my personal hobby horse.  Using new fangled hardware with
memory mapped I/O registers for debugging.  You need to be able to modify
the page table to use it so you might as well setup the fixmap entries
and then you have something that can be used as long as you care to
leave the hardware enabled.

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/