linux-kernel - Re: pud_bad vs pud

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: <Pine.LNX.4.64.0902052004550.12955@blonde.anvils>
Date:	Thu, 5 Feb 2009 20:12:44 +0000 (GMT)
From:	Hugh Dickins <hugh@...itas.com>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Jeremy Fitzhardinge <jeremy@...p.org>,
	William Lee Irwin III <wli@...ementarian.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Memory Management List <linux-mm@...ck.org>
Subject: Re: pud_bad vs pud_bad

On Thu, 5 Feb 2009, Ingo Molnar wrote:
> * Hugh Dickins <hugh@...itas.com> wrote:
> > 
> > Simpler and more compact, but not as strict: in particular, a value of
> > 0 or 1 is identified as bad by that 64-bit test, but not by the 32-bit.
> 
> yes, indeed you are right - the 64-bit test does not allow the KERNPG_TABLE 
> bits to go zero.
> 
> Those are the present, rw, accessed and dirty bits. Do they really matter 
> that much? If a toplevel entry goes !present or readonly, we notice that 
> _fast_, without any checks. If it goes !access or !dirty - does that matter?

I've not given it a great deal of thought, why this or that bit.
These p??_bad checks originate from 2.4 or earlier, and by mistake
got weakened somewhere along the way, and last time it was discussed
we agreed to strenghthen them (and IIRC Jeremy himself did so).

> 
> These checks are done all the time, and even a single instruction can count. 
> The bits that are checked are enough to notice random memory corruption.

Well, I am surprised that you would be arguing for weakening such
a very simple check.

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