[MODERATED] Re: [PATCH v5 8/8] NX 8

[MODERATED] Re: [PATCH v5 8/8] NX 8

[Pawan Gupta]

On Thu, Jul 11, 2019 at 10:46:37AM +0200, speck for Paolo Bonzini wrote:
> On 01/07/19 15:52, speck for Paolo Bonzini wrote:
> > From: Junaid Shahid <junaids@google.com>
> > Subject: [PATCH 8/8] kvm: x86: mmu: Recovery of shattered NX large pages
> > 
> > 
> > The page table pages corresponding to broken down large pages are
> > periodically zapped, so that the large page can potentially be
> > recovered, if it is no longer being used for execution.  This removes
> > the performance penalty for walking deeper EPT page tables.
> > 
> > Signed-off-by: Junaid Shahid <junaids@google.com>
> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> 
> Hi all,
> 
> Andrea Arcangeli suggested that zapping everything could cause big
> slowdowns for large guests.  The follow up here changes the recovery
> to process a fraction of the NX pages every minute, in FIFO order.
> 
> Paolo
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 6454e5c79287..6749ebaa3ead 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -2034,9 +2034,11 @@
>  			If the sw workaround is enabled for the host, guests
>  			need not enable it for nested guests.
>  
> -	kvm.nx_huge_pages_recovery_period_secs=
> -			[KVM] Time (s) interval to wait before zapping 4KiB
> -			pages back to huge pages.
> +	kvm.nx_huge_pages_recovery_ratio=
> +			[KVM] Controls how many 4KiB pages are periodically zapped
> +			back to huge pages.  0 disables the recovery, otherwise if
> +			the value is N KVM will zap 1/Nth of the 4KiB pages every
> +			minute.  The default is 60.
>  
>  	kvm-amd.nested=	[KVM,AMD] Allow nested virtualization in KVM/SVM.
>  			Default is 1 (enabled)
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index aea64339c57a..9c0497913ba3 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -54,26 +54,24 @@
>  extern bool itlb_multihit_kvm_mitigation;
>  
>  static int __read_mostly nx_huge_pages = -1;
> -static uint __read_mostly nx_huge_pages_recovery_period_secs = 3600;
> +static uint __read_mostly nx_huge_pages_recovery_ratio = 60;
>  
>  static int set_nx_huge_pages(const char *val, const struct kernel_param *kp);
> -static int set_nx_huge_pages_recovery_period(const char *val,
> -					     const struct kernel_param *kp);
> +static int set_nx_huge_pages_recovery_ratio(const char *val, const struct kernel_param *kp);
>  
>  static struct kernel_param_ops nx_huge_pages_ops = {
>  	.set = set_nx_huge_pages,
>  	.get = param_get_bool,
>  };
>  
> -static struct kernel_param_ops nx_huge_pages_recovery_period_ops = {
> -	.set = set_nx_huge_pages_recovery_period,
> -	.get = param_get_uint,
> +static struct kernel_param_ops nx_huge_pages_recovery_ratio_ops = {
> +	.set = set_nx_huge_pages_recovery_ratio,
> +	.get = param_get_bool,

Should 'param_get_bool' be 'param_get_uint' instead, as we would want to
output the ratio.

Do you want to rebase this series to a more recent version?

Thanks,
Pawan

[MODERATED] Re: [PATCH v5 8/8] NX 8

[Paolo Bonzini]

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

On 02/10/19 22:38, speck for Pawan Gupta wrote:
> Should 'param_get_bool' be 'param_get_uint' instead, as we would want to
> output the ratio.
> 
> Do you want to rebase this series to a more recent version?

Yes, I have other small changes I made so I'll send it out soon together
with a list of preparatory patches that were committed in the past months.

Paolo

[MODERATED] Re: [PATCH v5 8/8] NX 8

[Pawan Gupta]

On Wed, Oct 02, 2019 at 10:59:36PM +0200, speck for Paolo Bonzini wrote:
> On 02/10/19 22:38, speck for Pawan Gupta wrote:
> > Should 'param_get_bool' be 'param_get_uint' instead, as we would want to
> > output the ratio.
> > 
> > Do you want to rebase this series to a more recent version?
> 
> Yes, I have other small changes I made so I'll send it out soon together
> with a list of preparatory patches that were committed in the past months.

Just wanted to add that we would also need to do the backporting and
testing soon.

Thanks,
Pawan

[MODERATED] Re: [PATCH v5 8/8] NX 8

[Paolo Bonzini]

[-- Attachment #1: Type: text/plain, Size: 380 bytes --]

On 07/10/19 21:45, speck for Pawan Gupta wrote:
>> Yes, I have other small changes I made so I'll send it out soon together
>> with a list of preparatory patches that were committed in the past months.
> Just wanted to add that we would also need to do the backporting and
> testing soon.

Sure.  With the full list of required patches it shouldn't be an issue.

Paolo

[MODERATED] Re: [PATCH v5 8/8] NX 8

[Pawan Gupta]

On Wed, Oct 09, 2019 at 08:13:49AM +0200, speck for Paolo Bonzini wrote:
> On 07/10/19 21:45, speck for Pawan Gupta wrote:
> >> Yes, I have other small changes I made so I'll send it out soon together
> >> with a list of preparatory patches that were committed in the past months.
> > Just wanted to add that we would also need to do the backporting and
> > testing soon.
> 
> Sure.  With the full list of required patches it shouldn't be an issue.

When do you think you can post a v6?

Thanks,
Pawan

[MODERATED] Re: [PATCH v5 8/8] NX 8

[Paolo Bonzini]

[-- Attachment #1: Type: text/plain, Size: 763 bytes --]

On 09/10/19 16:41, speck for Pawan Gupta wrote:
> On Wed, Oct 09, 2019 at 08:13:49AM +0200, speck for Paolo Bonzini wrote:
>> On 07/10/19 21:45, speck for Pawan Gupta wrote:
>>>> Yes, I have other small changes I made so I'll send it out soon together
>>>> with a list of preparatory patches that were committed in the past months.
>>> Just wanted to add that we would also need to do the backporting and
>>> testing soon.
>>
>> Sure.  With the full list of required patches it shouldn't be an issue.
> 
> When do you think you can post a v6?

I have gotten a report of a crash, I'm trying to understand if it's my
patches or something pre-existing.  I believe it's the latter, but I'd
rather be sure.  I can post v6 right now though.

Paolo

[MODERATED] Re: [PATCH v5 8/8] NX 8

[Pawan Gupta]

On Wed, Oct 09, 2019 at 05:10:44PM +0200, speck for Paolo Bonzini wrote:
> On 09/10/19 16:41, speck for Pawan Gupta wrote:
> > On Wed, Oct 09, 2019 at 08:13:49AM +0200, speck for Paolo Bonzini wrote:
> >> On 07/10/19 21:45, speck for Pawan Gupta wrote:
> >>>> Yes, I have other small changes I made so I'll send it out soon together
> >>>> with a list of preparatory patches that were committed in the past months.
> >>> Just wanted to add that we would also need to do the backporting and
> >>> testing soon.
> >>
> >> Sure.  With the full list of required patches it shouldn't be an issue.
> > 
> > When do you think you can post a v6?
> 
> I have gotten a report of a crash, I'm trying to understand if it's my
> patches or something pre-existing.  I believe it's the latter, but I'd
> rather be sure.  I can post v6 right now though.

We can help debug the crash. Can you please share the series,
reproduction steps and the crash signature.

Thanks,
Pawan

[MODERATED] Re: [PATCH v5 8/8] NX 8

[Paolo Bonzini]

[-- Attachment #1: Type: text/plain, Size: 1940 bytes --]

On 10/10/19 07:53, speck for Pawan Gupta wrote:
> On Wed, Oct 09, 2019 at 05:10:44PM +0200, speck for Paolo Bonzini wrote:
>> On 09/10/19 16:41, speck for Pawan Gupta wrote:
>>> On Wed, Oct 09, 2019 at 08:13:49AM +0200, speck for Paolo Bonzini wrote:
>>>> On 07/10/19 21:45, speck for Pawan Gupta wrote:
>>>>>> Yes, I have other small changes I made so I'll send it out soon together
>>>>>> with a list of preparatory patches that were committed in the past months.
>>>>> Just wanted to add that we would also need to do the backporting and
>>>>> testing soon.
>>>>
>>>> Sure.  With the full list of required patches it shouldn't be an issue.
>>>
>>> When do you think you can post a v6?
>>
>> I have gotten a report of a crash, I'm trying to understand if it's my
>> patches or something pre-existing.  I believe it's the latter, but I'd
>> rather be sure.  I can post v6 right now though.
> 
> We can help debug the crash. Can you please share the series,
> reproduction steps and the crash signature.

The reproduction steps for v5 are as follows:

- grab the next branch of kvm-unit-tests.git[1] and build it

- create a lot of hugepages, on my machine I use 40 GiB worth of them:

  echo 20480 > /proc/sys/vm/nr_hugepages

- load KVM with kvm.nx_huge_pages_recovery_period_secs=3

- run the following script

  while true; do
    echo N > /sys/module/kvm/parameters/nx_huge_pages; sleep 1
    echo Y > /sys/module/kvm/parameters/nx_huge_pages; sleep 5
  done

- run the testcase with

  MEM=40960  # in megabytes
  qemu-kvm -nodefaults -vnc none -serial stdio -kernel x86/hugetext.flat
    -m $MEM -mem-path /dev/hugepages

You can also add a WARN_ON_ONCE(!sp->lpage_disallowed) to
kvm_recover_nx_lpages before the call to kvm_mmu_prepare_zap_page.  As
soon as it triggers, of course everything will go downhill.

Paolo

[1] git://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git

[MODERATED] Re: [PATCH v5 8/8] NX 8

[Paolo Bonzini]

[-- Attachment #1: Type: text/plain, Size: 1363 bytes --]

On 10/10/19 18:14, Paolo Bonzini wrote:
> On 10/10/19 07:53, speck for Pawan Gupta wrote:
>> We can help debug the crash. Can you please share the series,
>> reproduction steps and the crash signature.

The bug is a race condition between kvm_mmu_zap_all and, well,
everything else.  It is triggered when nx_huge_pages is clear/set while
the recovery thread runs.

Paolo

> The reproduction steps for v5 are as follows:
> 
> - grab the next branch of kvm-unit-tests.git[1] and build it
> 
> - create a lot of hugepages, on my machine I use 40 GiB worth of them:
> 
>   echo 20480 > /proc/sys/vm/nr_hugepages
> 
> - load KVM with kvm.nx_huge_pages_recovery_period_secs=3
> 
> - run the following script
> 
>   while true; do
>     echo N > /sys/module/kvm/parameters/nx_huge_pages; sleep 1
>     echo Y > /sys/module/kvm/parameters/nx_huge_pages; sleep 5
>   done
> 
> - run the testcase with
> 
>   MEM=40960  # in megabytes
>   qemu-kvm -nodefaults -vnc none -serial stdio -kernel x86/hugetext.flat
>     -m $MEM -mem-path /dev/hugepages
> 
> You can also add a WARN_ON_ONCE(!sp->lpage_disallowed) to
> kvm_recover_nx_lpages before the call to kvm_mmu_prepare_zap_page.  As
> soon as it triggers, of course everything will go downhill.
> 
> Paolo
> 
> [1] git://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git
> 

[MODERATED] Re: [PATCH v5 8/8] NX 8

[Paolo Bonzini]

[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]

On 10/10/19 18:50, Paolo Bonzini wrote:
> On 10/10/19 18:14, Paolo Bonzini wrote:
>> On 10/10/19 07:53, speck for Pawan Gupta wrote:
>>> We can help debug the crash. Can you please share the series,
>>> reproduction steps and the crash signature.
> 
> The bug is a race condition between kvm_mmu_zap_all and, well,
> everything else.  It is triggered when nx_huge_pages is clear/set while
> the recovery thread runs.

Gah, figured it out.  It's specific to v6.  I'll post the fixed patches
tomorrow, dinnertime now.

Paolo

> Paolo
> 
>> The reproduction steps for v5 are as follows:
>>
>> - grab the next branch of kvm-unit-tests.git[1] and build it
>>
>> - create a lot of hugepages, on my machine I use 40 GiB worth of them:
>>
>>   echo 20480 > /proc/sys/vm/nr_hugepages
>>
>> - load KVM with kvm.nx_huge_pages_recovery_period_secs=3
>>
>> - run the following script
>>
>>   while true; do
>>     echo N > /sys/module/kvm/parameters/nx_huge_pages; sleep 1
>>     echo Y > /sys/module/kvm/parameters/nx_huge_pages; sleep 5
>>   done
>>
>> - run the testcase with
>>
>>   MEM=40960  # in megabytes
>>   qemu-kvm -nodefaults -vnc none -serial stdio -kernel x86/hugetext.flat
>>     -m $MEM -mem-path /dev/hugepages
>>
>> You can also add a WARN_ON_ONCE(!sp->lpage_disallowed) to
>> kvm_recover_nx_lpages before the call to kvm_mmu_prepare_zap_page.  As
>> soon as it triggers, of course everything will go downhill.
>>
>> Paolo
>>
>> [1] git://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git
>>
> 
> 

[MODERATED] Re: [PATCH v5 6/8] NX 6

[Pawan Gupta]

On Tue, Jul 02, 2019 at 11:21:14PM +0200, speck for Thomas Gleixner wrote:
> On Tue, 2 Jul 2019, speck for Dave Hansen wrote:
> > On 7/2/19 1:46 PM, speck for Thomas Gleixner wrote:
> > >>  static ssize_t itlb_multihit_show_state(char *buf)
> > >>  {
> > >>  	return sprintf(buf, "Processor vulnerable\n");
> > > So this is the default state when KVM_INTEL = n. But if KVM is not in use
> > > is this actually an issue?
> > 
> > IMNHO, there's a very low chance of malicious exploitation without KVM.
> > 
> > There were some ancient huge page errata (details in
> > __split_huge_pmd_locked()) that required us to go through a
> > Present->Not-Present->Present(new size) dance when splitting THPs.  That
> > dance is also an effective mitigation against someone causing lots of
> > huge page splits/joins as a trigger for tlb-multihit.  That covers
> > userspace mappings that might be affected.
> > 
> > The other concern would be for exposure from changes to the kernel's
> > text mappings.  Those probably don't ever happen in response to
> > unprivileged operations.  Folks at Intel were asked to do an audit to
> > make sure that none of them are exposed.  Maybe Mark can share the
> > results of the audit.
>  
> So whatever the result is the mitigation show output needs to be:
> 
> #ifdef KVM_INTEL
> show_bug()
> {
> 	if (kvm_mitigated)
> 		print("Host: ??? KVM: Mitigated\n");
> 	else
> 		print("Host: ??? KVM: Vulnerable\n");
> }
> #else
> show_bug()
> {
> 	print("Host ???\n");
> }
> #endif

Due to previous errata kernel already follows the protocol to avoid this
issue on the host. Host mitigation state can be "Not vulnerable".

Thanks,
Pawan

[MODERATED] Re: [PATCH v5 6/8] NX 6

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]

On Mon, 2019-07-01 at 15:52 +0200, speck for Paolo Bonzini wrote:
> From: Paolo Bonzini <pbonzini@redhat.com>
> Subject: [PATCH 6/8] kvm: mmu: ITLB_MULTIHIT mitigation
[...]
> +static int set_nx_huge_pages(const char *val, const struct kernel_param *kp)
> +{
> +	bool old_val = nx_huge_pages;
> +	bool new_val;
> +
> +	/* In "auto" mode deploy workaround only if CPU has the bug. */
> +	if (sysfs_streq(val, "off"))
> +		new_val = 0;
> +	else if (sysfs_streq(val, "force"))
> +		new_val = 1;
> +	else if (sysfs_streq(val, "auto"))
> +		new_val = boot_cpu_has_bug(X86_BUG_ITLB_MULTIHIT);
> +	else if (strtobool(val, &new_val) < 0)
> +		return -EINVAL;
> +
> +	__set_nx_huge_pages(new_val);
> +
> +	if (new_val != old_val) {
> +		struct kvm *kvm;
> +		int idx;
> +
> +		mutex_lock(&kvm_lock);
> +
> +		list_for_each_entry(kvm, &vm_list, vm_list) {
> +			idx = srcu_read_lock(&kvm->srcu);
> +			kvm_mmu_zap_all(kvm);
> +			srcu_read_unlock(&kvm->srcu, idx);
> +		}
> +		mutex_unlock(&kvm_lock);
> +	}
[...]

I've started trying to backport the NX patches to stable branches, and
I think I can take them back as far as 4.9.

However, kvm_mmu_zap_all() is a relatively new addition and looks hard
to backport.  I intend to make the nx_huge_pages parameter read-only
(0444 permissions) and delete this "if (new_val != old_val)" block. 
Does that seem reasonable?

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[MODERATED] Re: [PATCH v5 6/8] NX 6

[Junaid Shahid]

[-- Attachment #1: Type: text/plain, Size: 593 bytes --]

On 10/9/19 3:42 PM, speck for Ben Hutchings wrote:
> 
> I've started trying to backport the NX patches to stable branches, and
> I think I can take them back as far as 4.9.
> 
> However, kvm_mmu_zap_all() is a relatively new addition and looks hard
> to backport.  I intend to make the nx_huge_pages parameter read-only
> (0444 permissions) and delete this "if (new_val != old_val)" block. 
> Does that seem reasonable?
> 

You could also just replace the call to kvm_mmu_zap_all() with kvm_mmu_invalidate_zap_all_pages(), which is present as far back as 3.11

Thanks,
Junaid

[MODERATED] Re: [PATCH v5 6/8] NX 6

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 845 bytes --]

On Wed, 2019-10-09 at 15:52 -0700, speck for Junaid Shahid wrote:
> On 10/9/19 3:42 PM, speck for Ben Hutchings wrote:
> > I've started trying to backport the NX patches to stable branches, and
> > I think I can take them back as far as 4.9.
> > 
> > However, kvm_mmu_zap_all() is a relatively new addition and looks hard
> > to backport.  I intend to make the nx_huge_pages parameter read-only
> > (0444 permissions) and delete this "if (new_val != old_val)" block. 
> > Does that seem reasonable?
> > 
> 
> You could also just replace the call to kvm_mmu_zap_all() with
> kvm_mmu_invalidate_zap_all_pages(), which is present as far back as
> 3.11

I found that but I wasn't confident that it was safe to call from this
context.

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[MODERATED] Re: [PATCH v5 6/8] NX 6

[Kanth Ghatraju]

[-- Attachment #1: Type: text/plain, Size: 1859 bytes --]

Hi Ben,


A couple of options:

1. You could revert 6ca18b6950f8dee29361722f28f69847724b276f with commit 7390de1e99a70895721165d0ccd4a6e16482960a
2. Use kvm_mmu_invalidate_zap_all_pages()

-kanth

> On Oct 9, 2019, at 6:42 PM, speck for Ben Hutchings <speck@linutronix.de> wrote:
> 
> On Mon, 2019-07-01 at 15:52 +0200, speck for Paolo Bonzini wrote:
>> From: Paolo Bonzini <pbonzini@redhat.com>
>> Subject: [PATCH 6/8] kvm: mmu: ITLB_MULTIHIT mitigation
> [...]
>> +static int set_nx_huge_pages(const char *val, const struct kernel_param *kp)
>> +{
>> +	bool old_val = nx_huge_pages;
>> +	bool new_val;
>> +
>> +	/* In "auto" mode deploy workaround only if CPU has the bug. */
>> +	if (sysfs_streq(val, "off"))
>> +		new_val = 0;
>> +	else if (sysfs_streq(val, "force"))
>> +		new_val = 1;
>> +	else if (sysfs_streq(val, "auto"))
>> +		new_val = boot_cpu_has_bug(X86_BUG_ITLB_MULTIHIT);
>> +	else if (strtobool(val, &new_val) < 0)
>> +		return -EINVAL;
>> +
>> +	__set_nx_huge_pages(new_val);
>> +
>> +	if (new_val != old_val) {
>> +		struct kvm *kvm;
>> +		int idx;
>> +
>> +		mutex_lock(&kvm_lock);
>> +
>> +		list_for_each_entry(kvm, &vm_list, vm_list) {
>> +			idx = srcu_read_lock(&kvm->srcu);
>> +			kvm_mmu_zap_all(kvm);
>> +			srcu_read_unlock(&kvm->srcu, idx);
>> +		}
>> +		mutex_unlock(&kvm_lock);
>> +	}
> [...]
> 
> I've started trying to backport the NX patches to stable branches, and
> I think I can take them back as far as 4.9.
> 
> However, kvm_mmu_zap_all() is a relatively new addition and looks hard
> to backport.  I intend to make the nx_huge_pages parameter read-only
> (0444 permissions) and delete this "if (new_val != old_val)" block.
> Does that seem reasonable?
> 
> Ben.
> 
> --
> Ben Hutchings
> Humans are not rational beings; they are rationalising beings.
> 


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[MODERATED] Re: [PATCH v5 6/8] NX 6

[Paolo Bonzini]

[-- Attachment #1: Type: text/plain, Size: 3831 bytes --]

On 10/10/19 00:42, speck for Ben Hutchings wrote:
> 
> I've started trying to backport the NX patches to stable branches, and
> I think I can take them back as far as 4.9.
> 
> However, kvm_mmu_zap_all() is a relatively new addition and looks hard
> to backport.  I intend to make the nx_huge_pages parameter read-only
> (0444 permissions) and delete this "if (new_val != old_val)" block. 
> Does that seem reasonable?

Just replace it with kvm_mmu_invalidate_zap_all_pages (which will be in 
v6, because we have since brought it back from the dead).

You also have to backport commit 833b45de69a6 ("kvm: x86, powerpc: do 
not allow clearing largepages debugfs entry", 2019-09-30) and make the 
new statistic 0444 as well.  This is the only other change in v6 for now.

This is the list of prerequisites I had prepared, it should go back to 4.3 or so:

17e4bce0ae63c7e03f3c7fa8d80890e7af3d4971 kvm: x86: mmu: fix ubsan index-out-of-range warning
cd1872f028556dc0e8424e58413c0268c159383b kvm: x86: mmu: Make force_pt_level bool
5ed5c5c8fdbab889837c9223fc6f4bdaa830879c kvm: x86: mmu: Simplify force_pt_level calculation code in FNAME(page_fault)()
fd136902187838bcae3a572f41cb703553dd63b8 kvm: x86: mmu: Move mapping_level_dirty_bitmap() call in mapping_level()
d8aacf5df86a961923a2c9c547d341d64a9d9f5d kvm: x86: mmu: Remove mapping_level_dirty_bitmap()
5225fdf8c8bea4418f69875804584c89a27c170e kvm: x86: mmu: Eliminate an extra memory slot search in mapping_level()
018aabb56d6109c8f12397c24e59f67c58870ac1 kvm: x86: mmu: Encapsulate the type of rmap-chain head in a new struct
ded5874946baa15b56b531f638f9c706266deb7b kvm: x86: mmu: Consolidate quickly_check_mmio_pf() and is_mmio_page_fault()
450869d6dbb72b370774fd4ee14c4f275bb08f98 kvm: x86: merge handle_mmio_page_fault and handle_mmio_page_fault_common
e9ee956e311d3d0a1506995b98e8de0b30773e1a kvm: x86: mmu: Move handle_mmio_page_fault() call to kvm_mmu_page_fault()
92f94f1e9e509caa564353c516c904278999e350 kvm: mmu: rename has_wrprotected_page to mmu_gfn_lpage_is_disallowed
547ffaed871af7db8713972eaf630802cac47cb1 kvm: mmu: introduce kvm_mmu_gfn_{allow, disallow}_lpage
029499b477389f7d6486c8c759a8498bcfecf322 kvm: x86: mmu: Make mmu_set_spte() return emulate value
4700579241d2d587765a58dddd1b2a89902767c0 kvm: x86: mmu: Move initialization of parent_ptes out from kvm_mmu_alloc_page()
0e3d0648bd903ff6cda7499f9349a2ce612bccb4 kvm: x86: mmu: always set accessed bit in shadow PTEs
98bba238429e200521594ed30dd1edad7faa0081 kvm: x86: mmu: Move parent_pte handling from kvm_mmu_get_page() to link_shadow_page()
bb11c6c96544737aede6a2eb92e5c6bc8b46534b kvm: x86: mmu: Remove unused parameter parent_pte from kvm_mmu_get_page()
e08d26f0712532c79b5ba6200862eaf2036f8df6 kvm: x86: simplify ept_misconfig
9b8ebbdb74b5ad76b9dfd8b101af17839174b126 kvm: x86: extend usage of RET_MMIO_PF_* constants
42522d08cdba6d8be4247e4f0770f39f4708b71f KVM: MMU: drop vcpu param in gpte_access
0d9ce162cf46c99628cc5da9510b959c7976735b kvm: Convert kvm_lock to a mutex
7ee0e5b29d275ac299cdf8ef67e60bf1648c8c6a KVM: x86: MMU: Remove unused parameter of __direct_map()
43fdcda96e2550c6d1c46fb8a78801aa2f7276ed kvm: mmu: Do not release the page inside mmu_set_spte() 
9de2b2120668d2874570b14105e49235097b70c2 KVM: x86: make FNAME(fetch) and __direct_map more similar
d679b32611c0102ce33b9e1a4e4b94854ed1812a KVM: x86: remove now unneeded hugepage gfn adjustment 
1e823556fd3af3635e174f570d0b85b4e72b2b1c KVM: x86: change kvm_mmu_page_get_gfn BUG_ON to WARN_ON
bf9af89c4146978000eba9b0a1eb43540d893223 KVM: x86: add tracepoints around __direct_map and FNAME(fetch)
833b45de69a6016c4b0cebe6765d526a31a81580 kvm: x86, powerpc: do not allow clearing largepages debugfs entry

None of the backports should be particularly tricky.

Thanks,

Paolo

[MODERATED] Re: [PATCH v5 6/8] NX 6

[Kanth Ghatraju]

[-- Attachment #1: Type: text/plain, Size: 4356 bytes --]

Hi Paolo,

Thanks for the list. I have a version of back port working all the way to 4.1 and my set of back ports is pretty close to what you have. Is the code ready for back ports or are you planning some more changes? In some of the previous mails, you alluded to “minor changes”. Can you please share the plan. Thanks.

-kanth

> On Oct 9, 2019, at 7:08 PM, speck for Paolo Bonzini <speck@linutronix.de> wrote:
> 
> On 10/10/19 00:42, speck for Ben Hutchings wrote:
>> 
>> I've started trying to backport the NX patches to stable branches, and
>> I think I can take them back as far as 4.9.
>> 
>> However, kvm_mmu_zap_all() is a relatively new addition and looks hard
>> to backport.  I intend to make the nx_huge_pages parameter read-only
>> (0444 permissions) and delete this "if (new_val != old_val)" block.
>> Does that seem reasonable?
> 
> Just replace it with kvm_mmu_invalidate_zap_all_pages (which will be in
> v6, because we have since brought it back from the dead).
> 
> You also have to backport commit 833b45de69a6 ("kvm: x86, powerpc: do
> not allow clearing largepages debugfs entry", 2019-09-30) and make the
> new statistic 0444 as well.  This is the only other change in v6 for now.
> 
> This is the list of prerequisites I had prepared, it should go back to 4.3 or so:
> 
> 17e4bce0ae63c7e03f3c7fa8d80890e7af3d4971 kvm: x86: mmu: fix ubsan index-out-of-range warning
> cd1872f028556dc0e8424e58413c0268c159383b kvm: x86: mmu: Make force_pt_level bool
> 5ed5c5c8fdbab889837c9223fc6f4bdaa830879c kvm: x86: mmu: Simplify force_pt_level calculation code in FNAME(page_fault)()
> fd136902187838bcae3a572f41cb703553dd63b8 kvm: x86: mmu: Move mapping_level_dirty_bitmap() call in mapping_level()
> d8aacf5df86a961923a2c9c547d341d64a9d9f5d kvm: x86: mmu: Remove mapping_level_dirty_bitmap()
> 5225fdf8c8bea4418f69875804584c89a27c170e kvm: x86: mmu: Eliminate an extra memory slot search in mapping_level()
> 018aabb56d6109c8f12397c24e59f67c58870ac1 kvm: x86: mmu: Encapsulate the type of rmap-chain head in a new struct
> ded5874946baa15b56b531f638f9c706266deb7b kvm: x86: mmu: Consolidate quickly_check_mmio_pf() and is_mmio_page_fault()
> 450869d6dbb72b370774fd4ee14c4f275bb08f98 kvm: x86: merge handle_mmio_page_fault and handle_mmio_page_fault_common
> e9ee956e311d3d0a1506995b98e8de0b30773e1a kvm: x86: mmu: Move handle_mmio_page_fault() call to kvm_mmu_page_fault()
> 92f94f1e9e509caa564353c516c904278999e350 kvm: mmu: rename has_wrprotected_page to mmu_gfn_lpage_is_disallowed
> 547ffaed871af7db8713972eaf630802cac47cb1 kvm: mmu: introduce kvm_mmu_gfn_{allow, disallow}_lpage
> 029499b477389f7d6486c8c759a8498bcfecf322 kvm: x86: mmu: Make mmu_set_spte() return emulate value
> 4700579241d2d587765a58dddd1b2a89902767c0 kvm: x86: mmu: Move initialization of parent_ptes out from kvm_mmu_alloc_page()
> 0e3d0648bd903ff6cda7499f9349a2ce612bccb4 kvm: x86: mmu: always set accessed bit in shadow PTEs
> 98bba238429e200521594ed30dd1edad7faa0081 kvm: x86: mmu: Move parent_pte handling from kvm_mmu_get_page() to link_shadow_page()
> bb11c6c96544737aede6a2eb92e5c6bc8b46534b kvm: x86: mmu: Remove unused parameter parent_pte from kvm_mmu_get_page()
> e08d26f0712532c79b5ba6200862eaf2036f8df6 kvm: x86: simplify ept_misconfig
> 9b8ebbdb74b5ad76b9dfd8b101af17839174b126 kvm: x86: extend usage of RET_MMIO_PF_* constants
> 42522d08cdba6d8be4247e4f0770f39f4708b71f KVM: MMU: drop vcpu param in gpte_access
> 0d9ce162cf46c99628cc5da9510b959c7976735b kvm: Convert kvm_lock to a mutex
> 7ee0e5b29d275ac299cdf8ef67e60bf1648c8c6a KVM: x86: MMU: Remove unused parameter of __direct_map()
> 43fdcda96e2550c6d1c46fb8a78801aa2f7276ed kvm: mmu: Do not release the page inside mmu_set_spte()
> 9de2b2120668d2874570b14105e49235097b70c2 KVM: x86: make FNAME(fetch) and __direct_map more similar
> d679b32611c0102ce33b9e1a4e4b94854ed1812a KVM: x86: remove now unneeded hugepage gfn adjustment
> 1e823556fd3af3635e174f570d0b85b4e72b2b1c KVM: x86: change kvm_mmu_page_get_gfn BUG_ON to WARN_ON
> bf9af89c4146978000eba9b0a1eb43540d893223 KVM: x86: add tracepoints around __direct_map and FNAME(fetch)
> 833b45de69a6016c4b0cebe6765d526a31a81580 kvm: x86, powerpc: do not allow clearing largepages debugfs entry
> 
> None of the backports should be particularly tricky.
> 
> Thanks,
> 
> Paolo
> 


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[MODERATED] NX backports (was Re: [PATCH v5 6/8] NX 6)

[Paolo Bonzini]

[-- Attachment #1: Type: text/plain, Size: 3187 bytes --]

On 10/10/19 01:20, speck for Kanth Ghatraju wrote:
> This is the list of prerequisites I had prepared, it should go back to 4.3 or so:
> 
> 17e4bce0ae63c7e03f3c7fa8d80890e7af3d4971 kvm: x86: mmu: fix ubsan index-out-of-range warning
> cd1872f028556dc0e8424e58413c0268c159383b kvm: x86: mmu: Make force_pt_level bool
> 5ed5c5c8fdbab889837c9223fc6f4bdaa830879c kvm: x86: mmu: Simplify force_pt_level calculation code in FNAME(page_fault)()
> fd136902187838bcae3a572f41cb703553dd63b8 kvm: x86: mmu: Move mapping_level_dirty_bitmap() call in mapping_level()
> d8aacf5df86a961923a2c9c547d341d64a9d9f5d kvm: x86: mmu: Remove mapping_level_dirty_bitmap()
> 5225fdf8c8bea4418f69875804584c89a27c170e kvm: x86: mmu: Eliminate an extra memory slot search in mapping_level()
> 018aabb56d6109c8f12397c24e59f67c58870ac1 kvm: x86: mmu: Encapsulate the type of rmap-chain head in a new struct
> ded5874946baa15b56b531f638f9c706266deb7b kvm: x86: mmu: Consolidate quickly_check_mmio_pf() and is_mmio_page_fault()
> 450869d6dbb72b370774fd4ee14c4f275bb08f98 kvm: x86: merge handle_mmio_page_fault and handle_mmio_page_fault_common
> e9ee956e311d3d0a1506995b98e8de0b30773e1a kvm: x86: mmu: Move handle_mmio_page_fault() call to kvm_mmu_page_fault()
> 92f94f1e9e509caa564353c516c904278999e350 kvm: mmu: rename has_wrprotected_page to mmu_gfn_lpage_is_disallowed
> 547ffaed871af7db8713972eaf630802cac47cb1 kvm: mmu: introduce kvm_mmu_gfn_{allow, disallow}_lpage
> 029499b477389f7d6486c8c759a8498bcfecf322 kvm: x86: mmu: Make mmu_set_spte() return emulate value
> 4700579241d2d587765a58dddd1b2a89902767c0 kvm: x86: mmu: Move initialization of parent_ptes out from kvm_mmu_alloc_page()
> 0e3d0648bd903ff6cda7499f9349a2ce612bccb4 kvm: x86: mmu: always set accessed bit in shadow PTEs
> 98bba238429e200521594ed30dd1edad7faa0081 kvm: x86: mmu: Move parent_pte handling from kvm_mmu_get_page() to link_shadow_page()
> bb11c6c96544737aede6a2eb92e5c6bc8b46534b kvm: x86: mmu: Remove unused parameter parent_pte from kvm_mmu_get_page()
> e08d26f0712532c79b5ba6200862eaf2036f8df6 kvm: x86: simplify ept_misconfig
> 9b8ebbdb74b5ad76b9dfd8b101af17839174b126 kvm: x86: extend usage of RET_MMIO_PF_* constants
> 42522d08cdba6d8be4247e4f0770f39f4708b71f KVM: MMU: drop vcpu param in gpte_access
> 0d9ce162cf46c99628cc5da9510b959c7976735b kvm: Convert kvm_lock to a mutex
> 7ee0e5b29d275ac299cdf8ef67e60bf1648c8c6a KVM: x86: MMU: Remove unused parameter of __direct_map()
> 43fdcda96e2550c6d1c46fb8a78801aa2f7276ed kvm: mmu: Do not release the page inside mmu_set_spte()
> 9de2b2120668d2874570b14105e49235097b70c2 KVM: x86: make FNAME(fetch) and __direct_map more similar
> d679b32611c0102ce33b9e1a4e4b94854ed1812a KVM: x86: remove now unneeded hugepage gfn adjustment
> 1e823556fd3af3635e174f570d0b85b4e72b2b1c KVM: x86: change kvm_mmu_page_get_gfn BUG_ON to WARN_ON
> bf9af89c4146978000eba9b0a1eb43540d893223 KVM: x86: add tracepoints around __direct_map and FNAME(fetch)
> 833b45de69a6016c4b0cebe6765d526a31a81580 kvm: x86, powerpc: do not allow clearing largepages debugfs entry

Remember to add commit 9167ab79936206118cc60e47dcb926c3489f3bd5,
currently on its way to Linus.

Paolo

[MODERATED] Re: [PATCH v5 6/8] NX 6

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 2943 bytes --]

On Thu, 2019-10-10 at 01:08 +0200, speck for Paolo Bonzini wrote:
> On 10/10/19 00:42, speck for Ben Hutchings wrote:
> > I've started trying to backport the NX patches to stable branches, and
> > I think I can take them back as far as 4.9.
> > 
> > However, kvm_mmu_zap_all() is a relatively new addition and looks hard
> > to backport.  I intend to make the nx_huge_pages parameter read-only
> > (0444 permissions) and delete this "if (new_val != old_val)" block. 
> > Does that seem reasonable?
> 
> Just replace it with kvm_mmu_invalidate_zap_all_pages (which will be in 
> v6, because we have since brought it back from the dead).
> 
> You also have to backport commit 833b45de69a6 ("kvm: x86, powerpc: do 
> not allow clearing largepages debugfs entry", 2019-09-30) and make the 
> new statistic 0444 as well.  This is the only other change in v6 for now.
> 
> This is the list of prerequisites I had prepared, it should go back to 4.3 or so:

Wow, thanks for this.  I still don't think it's worthwile to backport
this mitigation to stable branches older than 4.9 - they never got KVM
mitigations for L1TF so they're already unsuitable for hosting
untrusted guests.  After excluding commits older than 4.9, the list is
then:

[...]
> e08d26f0712532c79b5ba6200862eaf2036f8df6 kvm: x86: simplify ept_misconfig
> 9b8ebbdb74b5ad76b9dfd8b101af17839174b126 kvm: x86: extend usage of RET_MMIO_PF_* constants
> 42522d08cdba6d8be4247e4f0770f39f4708b71f KVM: MMU: drop vcpu param in gpte_access
> 0d9ce162cf46c99628cc5da9510b959c7976735b kvm: Convert kvm_lock to a mutex
[...]
> 43fdcda96e2550c6d1c46fb8a78801aa2f7276ed kvm: mmu: Do not release the page inside mmu_set_spte() 
> 9de2b2120668d2874570b14105e49235097b70c2 KVM: x86: make FNAME(fetch) and __direct_map more similar

Commit hash should be 3fcf2d1bdeb6a513523cb2c77012a6b047aa859c?

> d679b32611c0102ce33b9e1a4e4b94854ed1812a KVM: x86: remove now unneeded hugepage gfn adjustment 
> 1e823556fd3af3635e174f570d0b85b4e72b2b1c KVM: x86: change kvm_mmu_page_get_gfn BUG_ON to WARN_ON

Commit hash should be e9f2a760b158551bfbef6db31d2cae45ab8072e5?

> bf9af89c4146978000eba9b0a1eb43540d893223 KVM: x86: add tracepoints around __direct_map and FNAME(fetch)

Commit hash should be 335e192a3fa415e1202c8b9ecdaaecd643f823cc?

> 833b45de69a6016c4b0cebe6765d526a31a81580 kvm: x86, powerpc: do not allow clearing largepages debugfs entry
> 
> None of the backports should be particularly tricky.

In my previous attempt I found it helpful to pick these two that you
didn't mention:

3ff519f29d98 KVM: x86: adjust kvm_mmu_page member to save 8 bytes
00ae831dfe44 x86/cpu: Add Atom Tremont (Jacobsville)

Ben.

-- 
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be development of an easy way to factor large prime numbers.
                                                           - Bill Gates


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[MODERATED] Re: [PATCH v5 6/8] NX 6

[Paolo Bonzini]

[-- Attachment #1: Type: text/plain, Size: 359 bytes --]

On 14/10/19 00:11, speck for Ben Hutchings wrote:
> In my previous attempt I found it helpful to pick these two that you
> didn't mention:
> 
> 3ff519f29d98 KVM: x86: adjust kvm_mmu_page member to save 8 bytes

Yes, good idea.

> 00ae831dfe44 x86/cpu: Add Atom Tremont (Jacobsville)

... or just drop the Tremont patch from this series.

Paolo

[MODERATED] Re: [PATCH v5 6/8] NX 6

[mark gross]

On Sun, Oct 13, 2019 at 11:11:05PM +0100, speck for Ben Hutchings wrote:
> On Thu, 2019-10-10 at 01:08 +0200, speck for Paolo Bonzini wrote:
> > On 10/10/19 00:42, speck for Ben Hutchings wrote:
> > > I've started trying to backport the NX patches to stable branches, and
> > > I think I can take them back as far as 4.9.
> > > 
> > > However, kvm_mmu_zap_all() is a relatively new addition and looks hard
> > > to backport.  I intend to make the nx_huge_pages parameter read-only
> > > (0444 permissions) and delete this "if (new_val != old_val)" block. 
> > > Does that seem reasonable?
> > 
> > Just replace it with kvm_mmu_invalidate_zap_all_pages (which will be in 
> > v6, because we have since brought it back from the dead).
> > 
> > You also have to backport commit 833b45de69a6 ("kvm: x86, powerpc: do 
> > not allow clearing largepages debugfs entry", 2019-09-30) and make the 
> > new statistic 0444 as well.  This is the only other change in v6 for now.
> > 
> > This is the list of prerequisites I had prepared, it should go back to 4.3 or so:
> 
> Wow, thanks for this.  I still don't think it's worthwile to backport
> this mitigation to stable branches older than 4.9 - they never got KVM
> mitigations for L1TF so they're already unsuitable for hosting
> untrusted guests.  After excluding commits older than 4.9, the list is
> then:

If you have some backports of the NX changes we have some testing setups to
check them out if you can share the work over this list.

I think I will attempt the 4.4 backport for the NX issue as its more of an
errata than a side channel thing.

If someone already has a 4.4 backport done we can help check it out.

Thanks,

--mark


> 
> [...]
> > e08d26f0712532c79b5ba6200862eaf2036f8df6 kvm: x86: simplify ept_misconfig
> > 9b8ebbdb74b5ad76b9dfd8b101af17839174b126 kvm: x86: extend usage of RET_MMIO_PF_* constants
> > 42522d08cdba6d8be4247e4f0770f39f4708b71f KVM: MMU: drop vcpu param in gpte_access
> > 0d9ce162cf46c99628cc5da9510b959c7976735b kvm: Convert kvm_lock to a mutex
> [...]
> > 43fdcda96e2550c6d1c46fb8a78801aa2f7276ed kvm: mmu: Do not release the page inside mmu_set_spte() 
> > 9de2b2120668d2874570b14105e49235097b70c2 KVM: x86: make FNAME(fetch) and __direct_map more similar
> 
> Commit hash should be 3fcf2d1bdeb6a513523cb2c77012a6b047aa859c?
> 
> > d679b32611c0102ce33b9e1a4e4b94854ed1812a KVM: x86: remove now unneeded hugepage gfn adjustment 
> > 1e823556fd3af3635e174f570d0b85b4e72b2b1c KVM: x86: change kvm_mmu_page_get_gfn BUG_ON to WARN_ON
> 
> Commit hash should be e9f2a760b158551bfbef6db31d2cae45ab8072e5?
> 
> > bf9af89c4146978000eba9b0a1eb43540d893223 KVM: x86: add tracepoints around __direct_map and FNAME(fetch)
> 
> Commit hash should be 335e192a3fa415e1202c8b9ecdaaecd643f823cc?
> 
> > 833b45de69a6016c4b0cebe6765d526a31a81580 kvm: x86, powerpc: do not allow clearing largepages debugfs entry
> > 
> > None of the backports should be particularly tricky.
> 
> In my previous attempt I found it helpful to pick these two that you
> didn't mention:
> 
> 3ff519f29d98 KVM: x86: adjust kvm_mmu_page member to save 8 bytes
> 00ae831dfe44 x86/cpu: Add Atom Tremont (Jacobsville)
> 
> Ben.
> 
> -- 
> Ben Hutchings
> The obvious mathematical breakthrough [to break modern encryption]
> would be development of an easy way to factor large prime numbers.
>                                                            - Bill Gates
> 

[MODERATED] Re: ***UNCHECKED*** Re: [PATCH v5 6/8] NX 6

[Michal Hocko]

[-- Attachment #1: Type: text/plain, Size: 368 bytes --]

On Mon 04-11-19 11:43:51, speck for mark gross wrote:
[...]
> If someone already has a 4.4 backport done we can help check it out.

See the attached tarball with our 4.4 based distribution kernel
backport. I expect this to not apply cleanly on top of the latest stable
4.4 kernel though. Please also note that this is on top of TAA patches.
-- 
Michal Hocko
SUSE Labs

[-- Attachment #2: 4.4-backport.tar --]
[-- Type: application/x-tar, Size: 71680 bytes --]

[MODERATED] Re: ***UNCHECKED*** Re: [PATCH v5 6/8] NX 6

[mark gross]

On Tue, Nov 05, 2019 at 01:28:24PM +0100, speck for Michal Hocko wrote:
> On Mon 04-11-19 11:43:51, speck for mark gross wrote:
> [...]
> > If someone already has a 4.4 backport done we can help check it out.
> 
> See the attached tarball with our 4.4 based distribution kernel
> backport. I expect this to not apply cleanly on top of the latest stable
> 4.4 kernel though. Please also note that this is on top of TAA patches.

Thanks  We will, check it out ASAP.  (today and tomorrow depending on how the
other testing is going..)

--mark

> -- 
> Michal Hocko
> SUSE Labs

[MODERATED] Re: ***UNCHECKED*** Re: [PATCH v5 6/8] NX 6

[mark gross]

On Tue, Nov 05, 2019 at 06:53:59AM -0800, speck for mark gross wrote:
> On Tue, Nov 05, 2019 at 01:28:24PM +0100, speck for Michal Hocko wrote:
> > On Mon 04-11-19 11:43:51, speck for mark gross wrote:
> > [...]
> > > If someone already has a 4.4 backport done we can help check it out.
> > 
> > See the attached tarball with our 4.4 based distribution kernel
> > backport. I expect this to not apply cleanly on top of the latest stable
> > 4.4 kernel though. Please also note that this is on top of TAA patches.
> 
> Thanks  We will, check it out ASAP.  (today and tomorrow depending on how the
> other testing is going..)
> 
> --mark

Yeah it fails.  I think your patches depend on having Paulo's pick list
backported before they will apply.

--mark
> 
> > -- 
> > Michal Hocko
> > SUSE Labs
> 
> 

[MODERATED] Re: [PATCH v5 6/8] NX 6

[Pawan Gupta]

On Wed, Oct 09, 2019 at 11:42:51PM +0100, speck for Ben Hutchings wrote:
> On Mon, 2019-07-01 at 15:52 +0200, speck for Paolo Bonzini wrote:
> 
> I've started trying to backport the NX patches to stable branches, and
> I think I can take them back as far as 4.9.

Thanks for taking up the backporting. If you would like we can also
backport some remaining versions. Once you have the backports available,
we can help with testing.

FYI.. Intel is doing the TAA backporting (LTS/stable kernels till 4.14)
and want to base them on NX.

Thanks,
Pawan

[MODERATED] Re: [PATCH v5 6/8] NX 6

[Greg KH]

On Mon, Oct 14, 2019 at 01:46:42PM -0700, speck for Pawan Gupta wrote:
> On Wed, Oct 09, 2019 at 11:42:51PM +0100, speck for Ben Hutchings wrote:
> > On Mon, 2019-07-01 at 15:52 +0200, speck for Paolo Bonzini wrote:
> > 
> > I've started trying to backport the NX patches to stable branches, and
> > I think I can take them back as far as 4.9.
> 
> Thanks for taking up the backporting. If you would like we can also
> backport some remaining versions. Once you have the backports available,
> we can help with testing.
> 
> FYI.. Intel is doing the TAA backporting (LTS/stable kernels till 4.14)
> and want to base them on NX.

Why just till 4.14?  Do you not care about 4.9 and 4.4 anymore?

It's fine if you all don't, just need to know this as there are people
who still do :(

Or, if they aren't relevant for those older kernels, that's good to know
as well and I'll not worry about them.

thanks,

greg k-h

[MODERATED] Re: [PATCH v5 6/8] NX 6

[Jiri Kosina]

On Tue, 15 Oct 2019, speck for Greg KH wrote:

> Or, if they aren't relevant for those older kernels, that's good to know 
> as well and I'll not worry about them.

Both TAA and NX is relevant for 4.4 kernel.

-- 
Jiri Kosina
SUSE Labs

[MODERATED] Re: [PATCH v5 6/8] NX 6

[Pawan Gupta]

On Tue, Oct 15, 2019 at 12:46:48PM +0200, speck for Jiri Kosina wrote:
> On Tue, 15 Oct 2019, speck for Greg KH wrote:
> 
> > Or, if they aren't relevant for those older kernels, that's good to know 
> > as well and I'll not worry about them.
> 
> Both TAA and NX is relevant for 4.4 kernel.

Sure will backport till 4.4.

Thanks,
Pawan

[MODERATED] Re: [PATCH v5 6/8] NX 6

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 878 bytes --]

On Mon, 2019-10-14 at 13:46 -0700, speck for Pawan Gupta wrote:
> On Wed, Oct 09, 2019 at 11:42:51PM +0100, speck for Ben Hutchings wrote:
> > On Mon, 2019-07-01 at 15:52 +0200, speck for Paolo Bonzini wrote:
> > 
> > I've started trying to backport the NX patches to stable branches, and
> > I think I can take them back as far as 4.9.
> 
> Thanks for taking up the backporting. If you would like we can also
> backport some remaining versions. Once you have the backports available,
> we can help with testing.
> 
> FYI.. Intel is doing the TAA backporting (LTS/stable kernels till 4.14)
> and want to base them on NX.

That's good, because I don't think I have access to a CPU that
implements TSX and hasn't already had it disabled due to another bug.
:-)

Ben.

-- 
Ben Hutchings
It's easier to fight for one's principles than to live up to them.



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[MODERATED] Re: [PATCH v5 1/8] NX 1

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1337 bytes --]

On Mon, 2019-07-01 at 15:52 +0200, speck for Paolo Bonzini wrote:
> From: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> Subject: [PATCH 1/8] x86: Add ITLB_MULTIHIT bug infrastructure
[...]
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@ -385,5 +385,6 @@
>  #define X86_BUG_L1TF			X86_BUG(18) /* CPU is affected by L1 Terminal Fault */
>  #define X86_BUG_MDS			X86_BUG(19) /* CPU is affected by Microarchitectural data sampling */
>  #define X86_BUG_MSBDS_ONLY		X86_BUG(20) /* CPU is only affected by the  MSDBS variant of BUG_MDS */
> +#define X86_BUG_ITLB_MULTIHIT		X86_BUG(21) /* CPU may incur MCE during certain page attribute changes */
[...]

So this is now going to need to be renumbered after X86_BUG_SWAPGS. 
But the TAA series also allocates the next bug flag here.

Then in other places there are textual conflicts between the two series
due to insertions in the same place.

I believe both of the issues these are addressing have the same embargo
date, so it would be helpful to backporters if you could decide which
fix belongs first, even if they continue to be developed as separate
branches for now.  (So far I've found it easier to apply NX before
TAA.)

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[MODERATED] Re: [PATCH v5 1/8] NX 1

[Pawan Gupta]

On Thu, Oct 10, 2019 at 12:01:21AM +0100, speck for Ben Hutchings wrote:
> On Mon, 2019-07-01 at 15:52 +0200, speck for Paolo Bonzini wrote:
> > From: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> > Subject: [PATCH 1/8] x86: Add ITLB_MULTIHIT bug infrastructure
> [...]
> > --- a/arch/x86/include/asm/cpufeatures.h
> > +++ b/arch/x86/include/asm/cpufeatures.h
> > @@ -385,5 +385,6 @@
> >  #define X86_BUG_L1TF			X86_BUG(18) /* CPU is affected by L1 Terminal Fault */
> >  #define X86_BUG_MDS			X86_BUG(19) /* CPU is affected by Microarchitectural data sampling */
> >  #define X86_BUG_MSBDS_ONLY		X86_BUG(20) /* CPU is only affected by the  MSDBS variant of BUG_MDS */
> > +#define X86_BUG_ITLB_MULTIHIT		X86_BUG(21) /* CPU may incur MCE during certain page attribute changes */
> [...]
> 
> So this is now going to need to be renumbered after X86_BUG_SWAPGS. 
> But the TAA series also allocates the next bug flag here.
> 
> Then in other places there are textual conflicts between the two series
> due to insertions in the same place.
> 
> I believe both of the issues these are addressing have the same embargo
> date, so it would be helpful to backporters if you could decide which
> fix belongs first, even if they continue to be developed as separate
> branches for now.  (So far I've found it easier to apply NX before
> TAA.)

TAA is more recent than NX, so I guess NX should be applied before TAA.

	#define X86_BUG_SWAPGS                  X86_BUG(21)
	#define X86_BUG_ITLB_MULTIHIT           X86_BUG(22)
	#define X86_BUG_TAA                     X86_BUG(23)

Thanks,
Pawan