linux-kernel - Re: [PATCH] x86: set PAE PHYSICAL_MASK

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:	Thu, 05 Jun 2008 16:34:53 +0100
From:	"Jan Beulich" <jbeulich@...ell.com>
To:	"Ingo Molnar" <mingo@...e.hu>,
	"Jeremy Fitzhardinge" <jeremy@...p.org>
Cc:	"Stable Kernel" <stable@...nel.org>, <x86@...nel.org>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: set PAE PHYSICAL_MASK_SHIFT to match 64-bit

>The 46-bit mask used in 64-bit seems pretty arbitrary.  The physical
>size could be between 40 and 52 bits.  Setting the mask to 40 bits
>would restrict the physical size to 1TB, which is definitely too
>small.  Setting it to 52 would be ridiculously large, and runs the
>risk that one of the vendors may decide to put flags rather than
>physical address in one of the upper reserved bits.

Hmm? There's 11 bits available - why would anyone want to assign bits
from the sufficiently official (at least as far as AMD is concerned, I'm not
sure I saw a precise statement on Intel's side) frame number bits? And
even if they would, it would certainly take some control register bit to
enable the feature, so shrinking the mask if that would ever happen
would seem more appropriate.

Bottom line - I'd suggest pushing both 32- and 64-bits up to 52.

Jan

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