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: <1458079320.6393.376.camel@hpe.com>
Date:	Tue, 15 Mar 2016 16:02:00 -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 Tue, 2016-03-15 at 12:00 +0100, Borislav Petkov wrote:
> On Mon, Mar 14, 2016 at 03:37:23PM -0600, Toshi Kani wrote:
> > 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.
> 
> You couldnt've structured your reply better: remember how I split a
> convoluted patch of yours already? A patch which was trying to do a
> bunch of things in one go.
> 
> The situation here is the same. You need to do *one* *logical*
> *non-trivial* thing in a patch. If there's something else that needs to
> be done, add it in a *separate* patch which explains why that new change
> is needed.

Got it!

> > - 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.
> 
> That should be a separate patch which explains *why* the change is being
> done.
> 
> > - 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.
> 
> The code which you carved out from get_mtrr_state() didn't check
> mtrr_enabled() before. That needs to be another patch *again* with
> explanations.
> 
> > - 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().
> 
> Yet another patch.
> 
> > - When CONFIG_MTRR is unset, it does not call pat_setup().
> 
> Aaaand... can you guess what I'm going to say here?
> 
> I hope it is coming across as I intend it: please use my hunk to do a
> single fix and then prepare all those changes above in separate patches
> with explanations:

Unfortunately, this single fix will break Xen.  So, I think we will need to
make a few enhancements first before making the fix.

> "Problem is A. We need to do B. I'm doing it/I'm doing C because."
> 
> Ok?

Yes, I will try to separate the patches to change one logical thing at a
time. 

Thanks,
-Toshi