linux-kernel - Re: [PATCH] x86: simplify mtrr_bp

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:	Thu, 26 Jul 2012 08:01:51 +0100
From:	"Jan Beulich" <JBeulich@...e.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	<mingo@...e.hu>, "Yinghai Lu" <yinghai@...nel.org>,
	<tglx@...utronix.de>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: simplify mtrr_bp_init()

>>> On 25.07.12 at 18:57, "H. Peter Anvin" <hpa@...or.com> wrote:
> On 07/25/2012 12:59 AM, Jan Beulich wrote:
>>>
>>> should drop all phys_addr assignment in this function.
>>>
>>> x86_phys_bits should have all correct value?
>>
>> Is it certain that all special cases (setting phys_addr to 32) are
>> covered by those CPUs not having PAE/PSE36? One would
>> think that this is valid to imply, but getting cpu_info's phys_bits
>> wrong isn't fatal as long as no addresses beyond 4G would ever
>> be encountered anywhere, whereas using too large an address
>> width here would result in the MTRR writes causing #GP. So
>> when I did this adjustment (a couple of years ago already - this
>> isn't the first submission), I decided to remain on the safe side.
>>
>> Does any of the maintainers have an opinion either way?
>>
> 
> There are definitely CPUs which have PAE but only has a 32-bit address 
> bus.  On the other hand there are tons of chipsets which arbitrary 
> address caps that almost nothing in the system knows about, so I don't 
> think this matters.

The first sentence implies to me that you consider the patch
fine as is, yet the last phrase makes me rather think you want
it adjusted as per Yinghai's response.

In any case, address capping by the chipset doesn't matter
here, all we're after is determining how may bits the MTRRs
(or equivalents) implement (so that size_or_mask and
size_and_mask end up being correct).

Bottom line - I'm confused as to what (if any) adjustments
the patch needs in order to be acceptable.

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/