linux-kernel - Re: [Xen-devel] [PATCH RFC 2/3] x86: Enable PAT to use cache mode translation tables

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: <53FB2A8B.1040500@suse.com>
Date:	Mon, 25 Aug 2014 14:22:35 +0200
From:	Juergen Gross <jgross@...e.com>
To:	Jan Beulich <JBeulich@...e.com>
CC:	stefan.bader@...onical.com, toshi.kani@...com, x86@...nel.org,
	ville.syrjala@...ux.intel.com,
	xen-devel <xen-devel@...ts.xenproject.org>,
	konrad.wilk@...cle.com, linux-kernel@...r.kernel.org, hpa@...or.com
Subject: Re: [Xen-devel] [PATCH RFC 2/3] x86: Enable PAT to use cache mode
 translation tables

On 08/22/2014 11:32 AM, Jan Beulich wrote:
>>>> On 19.08.14 at 15:25, <JGross@...e.com> wrote:
>> @@ -118,8 +167,14 @@ void pat_init(void)
>>   	      PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, UC);
>>
>>   	/* Boot CPU check */
>> -	if (!boot_pat_state)
>> +	if (!boot_pat_state) {
>>   		rdmsrl(MSR_IA32_CR_PAT, boot_pat_state);
>> +		/*
>> +		 * Init cache mode tables before writing MSR to give Xen a
>> +		 * chance to correct the changes when doing the write.
>> +		 */
>
> This comment seems pretty odd to me: For one, a PV guest on Xen
> shouldn't be trying to write PAT MSR at all under the current ABI
> (the write will be ignored, yes, but accompanied with a warning
> message, which PV kernels - by the mere fact that they're PV -
> should try to avoid). And then "correct the changes" both gives
> the impression as if they were wrong and as if some of what the
> kernel writes may be under the kernel's control. Hence I think this
> code and comment should either be consistently assuming that the
> kernel has no control at all, or should read back the value after
> having written it, and set the internal tables based on the value
> read back.

I think the latter alternative is the better one. I'll change the
patch.

Juergen

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