linux-kernel - Re: [PATCH 1/2] x86/mm/pat: Change pat

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: <1457991443.6393.290.camel@hpe.com>
Date:	Mon, 14 Mar 2016 15:37:23 -0600
From:	Toshi Kani <toshi.kani@....com>
To:	Borislav Petkov <bp@...en8.de>
Cc:	"mingo@...nel.org" <mingo@...nel.org>,
	"hpa@...or.com" <hpa@...or.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"mcgrof@...e.com" <mcgrof@...e.com>,
	"jgross@...e.com" <jgross@...e.com>,
	"paul.gortmaker@...driver.com" <paul.gortmaker@...driver.com>,
	"x86@...nel.org" <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] x86/mm/pat: Change pat_disable() to emulate PAT
 table

On Sat, 2016-03-12 at 12:55 +0100, Borislav Petkov wrote:
> Ok, let's start again.
> 
> So what's wrong with this simpler, cleaner version below?
> 
> * It makes sure to run the rendezvous handler on the BP on init.
> 
> * It disables PAT otherwise.
> 
> * Oh, and it boots fine with Paul's reproducer, X is there (even though
> vncviewer dies when X starts with "Rect too large: 640x480 at (0, 0)"
> and I have to reconnect to see the X window).
> 
> In dmesg I see "x86/PAT: Disabled by MTRR".

Your patch is a simplified version of mine.  So, yes, it fixes the Paul's
issue, but it does not address other issues that my patchset also
addressed.  In specific, I think your patch has the following issues.

- pat_disable() is now callable from other modules. So, it needs to check
with boot_cpu_done. We cannot disable PAT once it is initialized.

- mtrr_bp_init() needs to check with mtrr_enabled() when it
calls mtrr_pat_setup_bp(). Otherwise, PAT is left initialized on BSP only
when MTRR is disabled by its MSR. In your patch, mtrr_bp_init() calls
pat_setup() again, but it does not help since boot_cpu_done is set.

- When PAT is disabled in CPU feature, pat_bsp_init() calls pat_disable()
and returns. However, it does not initialize a PAT table by calling
pat_init_cache_modes().

- When CONFIG_MTRR is unset, it does not call pat_setup().

Thanks,
-Toshi