[patch V6 00/14] MDS basics 0

[patch V6 00/14] MDS basics 0

[Thomas Gleixner]

Changes vs. V5:

  - Fix tools/ build (Josh)

  - Dropped the AIRMONT_MID change as it needs confirmation from Intel

  - Made the consolidated whitelist more readable and correct

  - Added the MSBDS only quirk for XEON PHI, made the idle flush
    depend on it and updated the sysfs output accordingly.

  - Fixed the protection matrix in the admin documentation and clarified
    the SMT situation vs. MSBDS only.

  - Updated the KVM/VMX changelog.

Delta patch against V5 below.

Available from git:

   cvs.ou.linutronix.de:linux/speck/linux WIP.mds

The linux-4.20.y, linux-4.19.y and linux-4.14.y branches are updated as
well and contain the untested backports of the pile for reference.

I'll send git bundles of the pile as well.

Thanks,

	tglx

8<---------------------------
diff --git a/Documentation/admin-guide/hw-vuln/mds.rst b/Documentation/admin-guide/hw-vuln/mds.rst
index 73cdc390aece..1de29d28903d 100644
--- a/Documentation/admin-guide/hw-vuln/mds.rst
+++ b/Documentation/admin-guide/hw-vuln/mds.rst
@@ -23,6 +23,10 @@ vulnerability is not present on:
 Whether a processor is affected or not can be read out from the MDS
 vulnerability file in sysfs. See :ref:`mds_sys_info`.
 
+Not all processors are affected by all variants of MDS, but the mitigation
+is identical for all of them so the kernel treats them as a single
+vulnerability.
+
 Related CVEs
 ------------
 
@@ -112,6 +116,7 @@ to the above information:
 
     ========================  ============================================
     'SMT vulnerable'          SMT is enabled
+    'SMT mitigated'           SMT is enabled and mitigated
     'SMT disabled'            SMT is disabled
     'SMT Host state unknown'  Kernel runs in a VM, Host SMT state unknown
     ========================  ============================================
@@ -153,8 +158,12 @@ CPU buffer clearing
   The mitigation for MDS clears the affected CPU buffers on return to user
   space and when entering a guest.
 
-  If SMT is enabled it also clears the buffers on idle entry, but that's not
-  a sufficient SMT protection for all MDS variants; it covers solely MSBDS.
+  If SMT is enabled it also clears the buffers on idle entry when the CPU
+  is only affected by MSBDS and not any other MDS variant, because the
+  other variants cannot be protected against cross Hyper-Thread attacks.
+
+  For CPUs which are only affected by MSBDS the user space, guest and idle
+  transition mitigations are sufficient and SMT is not affected.
 
 .. _virt_mechanism:
 
@@ -168,8 +177,10 @@ Virtualization mitigation
 
     If the L1D flush mitigation is enabled and up to date microcode is
     available, the L1D flush mitigation is automatically protecting the
-    guest transition. If the L1D flush mitigation is disabled the MDS
-    mitigation is disabled as well.
+    guest transition.
+
+    If the L1D flush mitigation is disabled then the MDS mitigation is
+    invoked explicit when the host MDS mitigation is enabled.
 
     For details on L1TF and virtualization see:
     :ref:`Documentation/admin-guide/hw-vuln//l1tf.rst <mitigation_control_kvm>`.
@@ -177,16 +188,18 @@ Virtualization mitigation
   - CPU is not affected by L1TF:
 
     CPU buffers are flushed before entering the guest when the host MDS
-    protection is enabled.
+    mitigation is enabled.
 
   The resulting MDS protection matrix for the host to guest transition:
 
   ============ ===== ============= ============ =================
-   L1TF         MDS   VMX-L1FLUSH   Host MDS     State
+   L1TF         MDS   VMX-L1FLUSH   Host MDS     MDS-State
 
    Don't care   No    Don't care    N/A          Not affected
 
-   Yes          Yes   Disabled      Don't care   Vulnerable
+   Yes          Yes   Disabled      Off          Vulnerable
+
+   Yes          Yes   Disabled      Full         Mitigated
 
    Yes          Yes   Enabled       Don't care   Mitigated
 
@@ -196,7 +209,7 @@ Virtualization mitigation
   ============ ===== ============= ============ =================
 
   This only covers the host to guest transition, i.e. prevents leakage from
-  host to guest, but does not protect the guest internally. Guest need to
+  host to guest, but does not protect the guest internally. Guests need to
   have their own protections.
 
 .. _xeon_phi:
@@ -210,14 +223,22 @@ XEON PHI specific considerations
   for malicious user space. The exposure can be disabled on the kernel
   command line with the 'ring3mwait=disable' command line option.
 
+  XEON PHI is not affected by the other MDS variants and MSBDS is mitigated
+  before the CPU enters a idle state. As XEON PHI is not affected by L1TF
+  either disabling SMT is not required for full protection.
+
 .. _mds_smt_control:
 
 SMT control
 ^^^^^^^^^^^
 
-  To prevent the SMT issues of MDS it might be necessary to disable SMT
-  completely. Disabling SMT can have a significant performance impact, but
-  the impact depends on the type of workloads.
+  All MDS variants except MSBDS can be attacked cross Hyper-Threads. That
+  means on CPUs which are affected by MFBDS or MLPDS it is necessary to
+  disable SMT for full protection. These are most of the affected CPUs; the
+  exception is XEON PHI, see :ref:`xeon_phi`.
+
+  Disabling SMT can have a significant performance impact, but the impact
+  depends on the type of workloads.
 
   See the relevant chapter in the L1TF mitigation documentation for details:
   :ref:`Documentation/admin-guide/hw-vuln/l1tf.rst <smt_control>`.
@@ -260,9 +281,7 @@ Mitigation selection guide
 2. Virtualization with trusted guests
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-   The same considerations as above versus trusted user space apply. See
-   also: :ref:`Documentation/admin-guide/hw-vuln//l1tf.rst <mitigation_selection>`.
-
+   The same considerations as above versus trusted user space apply.
 
 3. Virtualization with untrusted guests
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -270,6 +289,8 @@ Mitigation selection guide
    The protection depends on the state of the L1TF mitigations.
    See :ref:`virt_mechanism`.
 
+   If the MDS mitigation is enabled and SMT is disabled, guest to host and
+   guest to guest attacks are prevented.
 
 .. _mds_default_mitigations:
 
diff --git a/Documentation/x86/mds.rst b/Documentation/x86/mds.rst
index b050623c869c..3d6f943f1afb 100644
--- a/Documentation/x86/mds.rst
+++ b/Documentation/x86/mds.rst
@@ -107,19 +107,19 @@ user space or VM guests.
 Kernel internal mitigation modes
 --------------------------------
 
- ======= ===========================================================
- off     Mitigation is disabled. Either the CPU is not affected or
-         mds=off is supplied on the kernel command line
+ ======= ============================================================
+ off      Mitigation is disabled. Either the CPU is not affected or
+          mds=off is supplied on the kernel command line
 
- full    Mitigation is eanbled. CPU is affected and MD_CLEAR is
-         advertised in CPUID.
+ full     Mitigation is eanbled. CPU is affected and MD_CLEAR is
+          advertised in CPUID.
 
- vmwerv	 Mitigation is enabled. CPU is affected and MD_CLEAR is not
-	 advertised in CPUID. That is mainly for virtualization
-	 scenarios where the host has the updated microcode but the
-	 hypervisor does not expose MD_CLEAR in CPUID. It's a best
-	 effort approach without guarantee.
- ======= ===========================================================
+ vmwerv	  Mitigation is enabled. CPU is affected and MD_CLEAR is not
+	  advertised in CPUID. That is mainly for virtualization
+	  scenarios where the host has the updated microcode but the
+	  hypervisor does not expose MD_CLEAR in CPUID. It's a best
+	  effort approach without guarantee.
+ ======= ============================================================
 
 If the CPU is affected and mds=off is not supplied on the kernel command
 line then the kernel selects the appropriate mitigation mode depending on
@@ -189,6 +189,13 @@ Mitigation points
    When SMT is inactive, i.e. either the CPU does not support it or all
    sibling threads are offline CPU buffer clearing is not required.
 
+   The idle clearing is enabled on CPUs which are only affected by MSBDS
+   and not by any other MDS variant. The other MDS variants cannot be
+   protected against cross Hyper-Thread attacks because the Fill Buffer and
+   the Load Ports are shared. So on CPUs affected by other variants, the
+   idle clearing would be a window dressing exercise and is therefore not
+   activated.
+
    The invocation is controlled by the static key mds_idle_clear which is
    switched depending on the chosen mitigation mode and the SMT state of
    the system.
diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index ae3f987b24f1..bdcea163850a 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -383,5 +383,6 @@
 #define X86_BUG_SPEC_STORE_BYPASS	X86_BUG(17) /* CPU is affected by speculative store bypass attack */
 #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 */
 
 #endif /* _ASM_X86_CPUFEATURES_H */
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index aea871e69d64..e11654f93e71 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -667,6 +667,15 @@ static void update_indir_branch_cond(void)
 /* Update the static key controlling the MDS CPU buffer clear in idle */
 static void update_mds_branch_idle(void)
 {
+	/*
+	 * Enable the idle clearing on CPUs which are affected only by
+	 * MDBDS and not any other MDS variant. The other variants cannot
+	 * be mitigated when SMT is enabled, so clearing the buffers on
+	 * idle would be a window dressing exercise.
+	 */
+	if (!boot_cpu_has(X86_BUG_MSBDS_ONLY))
+		return;
+
 	if (sched_smt_active())
 		static_branch_enable(&mds_idle_clear);
 	else
@@ -1174,6 +1183,11 @@ static ssize_t mds_show_state(char *buf)
 			       mds_strings[mds_mitigation]);
 	}
 
+	if (boot_cpu_has(X86_BUG_MSBDS_ONLY)) {
+		return sprintf(buf, "%s; SMT %s\n", mds_strings[mds_mitigation],
+			       sched_smt_active() ? "mitigated" : "disabled");
+	}
+
 	return sprintf(buf, "%s; SMT %s\n", mds_strings[mds_mitigation],
 		       sched_smt_active() ? "vulnerable" : "disabled");
 }
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 389853338c2f..71d953a2c4db 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -953,38 +953,57 @@ static void identify_cpu_without_cpuid(struct cpuinfo_x86 *c)
 #define NO_SSB		BIT(2)
 #define NO_L1TF		BIT(3)
 #define NO_MDS		BIT(4)
+#define MSBDS_ONLY	BIT(5)
+
+#define VULNWL(_vendor, _family, _model, _whitelist)	\
+	{ X86_VENDOR_##_vendor, _family, _model, X86_FEATURE_ANY, _whitelist }
+
+#define VULNWL_INTEL(model, whitelist)		\
+	VULNWL(INTEL, 6, INTEL_FAM6_##model, whitelist)
+
+#define VULNWL_AMD(family, whitelist)		\
+	VULNWL(AMD, family, X86_MODEL_ANY, whitelist)
+
+#define VULNWL_HYGON(family, whitelist)		\
+	VULNWL(HYGON, family, X86_MODEL_ANY, whitelist)
 
 static const __initconst struct x86_cpu_id cpu_vuln_whitelist[] = {
-	{ X86_VENDOR_ANY,	4, X86_MODEL_ANY,			X86_FEATURE_ANY, NO_SPECULATION },
-	{ X86_VENDOR_CENTAUR,	5, X86_MODEL_ANY,			X86_FEATURE_ANY, NO_SPECULATION },
-	{ X86_VENDOR_INTEL,	5, X86_MODEL_ANY,			X86_FEATURE_ANY, NO_SPECULATION },
-	{ X86_VENDOR_NSC,	5, X86_MODEL_ANY,			X86_FEATURE_ANY, NO_SPECULATION },
-	{ X86_VENDOR_INTEL,	6, INTEL_FAM6_ATOM_SALTWELL,		X86_FEATURE_ANY, NO_SPECULATION },
-	{ X86_VENDOR_INTEL,	6, INTEL_FAM6_ATOM_SALTWELL_TABLET,	X86_FEATURE_ANY, NO_SPECULATION },
-	{ X86_VENDOR_INTEL,	6, INTEL_FAM6_ATOM_BONNELL_MID,		X86_FEATURE_ANY, NO_SPECULATION },
-	{ X86_VENDOR_INTEL,	6, INTEL_FAM6_ATOM_SALTWELL_MID,	X86_FEATURE_ANY, NO_SPECULATION },
-	{ X86_VENDOR_INTEL,	6, INTEL_FAM6_ATOM_BONNELL,		X86_FEATURE_ANY, NO_SPECULATION },
-
-	{ X86_VENDOR_AMD,	X86_FAMILY_ANY, X86_MODEL_ANY,		X86_FEATURE_ANY, NO_MELTDOWN | NO_L1TF },
-	{ X86_VENDOR_HYGON,	X86_FAMILY_ANY, X86_MODEL_ANY,		X86_FEATURE_ANY, NO_MELTDOWN | NO_L1TF },
-
-	{ X86_VENDOR_INTEL,	6, INTEL_FAM6_ATOM_SILVERMONT,		X86_FEATURE_ANY, NO_SSB | NO_L1TF },
-	{ X86_VENDOR_INTEL,	6, INTEL_FAM6_ATOM_SILVERMONT_X,	X86_FEATURE_ANY, NO_SSB | NO_L1TF },
-	{ X86_VENDOR_INTEL,	6, INTEL_FAM6_ATOM_SILVERMONT_MID,	X86_FEATURE_ANY, NO_SSB | NO_L1TF },
-	{ X86_VENDOR_INTEL,	6, INTEL_FAM6_ATOM_AIRMONT,		X86_FEATURE_ANY, NO_SSB | NO_L1TF },
-	{ X86_VENDOR_INTEL,	6, INTEL_FAM6_ATOM_AIRMONT_MID,		X86_FEATURE_ANY, NO_SSB | NO_L1TF },
-	{ X86_VENDOR_INTEL,	6, INTEL_FAM6_CORE_YONAH,		X86_FEATURE_ANY, NO_SSB | NO_L1TF },
-	{ X86_VENDOR_INTEL,	6, INTEL_FAM6_XEON_PHI_KNL,		X86_FEATURE_ANY, NO_SSB | NO_L1TF },
-	{ X86_VENDOR_INTEL,	6, INTEL_FAM6_XEON_PHI_KNM,		X86_FEATURE_ANY, NO_SSB | NO_L1TF },
-
-	{ X86_VENDOR_INTEL,	6, INTEL_FAM6_ATOM_GOLDMONT,		X86_FEATURE_ANY, NO_L1TF | NO_MDS },
-	{ X86_VENDOR_INTEL,	6, INTEL_FAM6_ATOM_GOLDMONT_X,		X86_FEATURE_ANY, NO_L1TF | NO_MDS },
-	{ X86_VENDOR_INTEL,	6, INTEL_FAM6_ATOM_GOLDMONT_PLUS,	X86_FEATURE_ANY, NO_L1TF | NO_MDS },
-
-	{ X86_VENDOR_AMD,	0x0f, X86_MODEL_ANY,			X86_FEATURE_ANY, NO_SSB },
-	{ X86_VENDOR_AMD,	0x10, X86_MODEL_ANY,			X86_FEATURE_ANY, NO_SSB },
-	{ X86_VENDOR_AMD,	0x11, X86_MODEL_ANY,			X86_FEATURE_ANY, NO_SSB },
-	{ X86_VENDOR_AMD,	0x12, X86_MODEL_ANY,			X86_FEATURE_ANY, NO_SSB },
+	VULNWL(ANY,	4, X86_MODEL_ANY,	NO_SPECULATION),
+	VULNWL(CENTAUR,	5, X86_MODEL_ANY,	NO_SPECULATION),
+	VULNWL(INTEL,	5, X86_MODEL_ANY,	NO_SPECULATION),
+	VULNWL(NSC,	5, X86_MODEL_ANY,	NO_SPECULATION),
+
+	/* Intel Family 6 */
+	VULNWL_INTEL(ATOM_SALTWELL,		NO_SPECULATION),
+	VULNWL_INTEL(ATOM_SALTWELL_TABLET,	NO_SPECULATION),
+	VULNWL_INTEL(ATOM_SALTWELL_MID,		NO_SPECULATION),
+	VULNWL_INTEL(ATOM_BONNELL,		NO_SPECULATION),
+	VULNWL_INTEL(ATOM_BONNELL_MID,		NO_SPECULATION),
+
+	VULNWL_INTEL(ATOM_SILVERMONT,		NO_SSB | NO_L1TF),
+	VULNWL_INTEL(ATOM_SILVERMONT_X,		NO_SSB | NO_L1TF),
+	VULNWL_INTEL(ATOM_SILVERMONT_MID,	NO_SSB | NO_L1TF),
+	VULNWL_INTEL(ATOM_AIRMONT,		NO_SSB | NO_L1TF),
+	VULNWL_INTEL(XEON_PHI_KNL,		NO_SSB | NO_L1TF | MSBDS_ONLY),
+	VULNWL_INTEL(XEON_PHI_KNM,		NO_SSB | NO_L1TF | MSBDS_ONLY),
+
+	VULNWL_INTEL(CORE_YONAH,		NO_SSB),
+
+	VULNWL_INTEL(ATOM_AIRMONT_MID,		NO_L1TF),
+
+	VULNWL_INTEL(ATOM_GOLDMONT,		NO_MDS | NO_L1TF),
+	VULNWL_INTEL(ATOM_GOLDMONT_X,		NO_MDS | NO_L1TF),
+	VULNWL_INTEL(ATOM_GOLDMONT_PLUS,	NO_MDS | NO_L1TF),
+
+	/* AMD Family 0xf - 0x12 */
+	VULNWL_AMD(0x0f,	NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS),
+	VULNWL_AMD(0x10,	NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS),
+	VULNWL_AMD(0x11,	NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS),
+	VULNWL_AMD(0x12,	NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS),
+
+	/* FAMILY_ANY must be last, otherwise 0x0f - 0x12 matches won't work */
+	VULNWL_AMD(X86_FAMILY_ANY,	NO_MELTDOWN | NO_L1TF | NO_MDS),
+	VULNWL_HYGON(X86_FAMILY_ANY,	NO_MELTDOWN | NO_L1TF | NO_MDS),
 	{}
 };
 
@@ -1015,8 +1034,11 @@ static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)
 	if (ia32_cap & ARCH_CAP_IBRS_ALL)
 		setup_force_cpu_cap(X86_FEATURE_IBRS_ENHANCED);
 
-	if (!cpu_matches(NO_MDS) && !(ia32_cap & ARCH_CAP_MDS_NO))
+	if (!cpu_matches(NO_MDS) && !(ia32_cap & ARCH_CAP_MDS_NO)) {
 		setup_force_cpu_bug(X86_BUG_MDS);
+		if (cpu_matches(MSBDS_ONLY))
+			setup_force_cpu_bug(X86_BUG_MSBDS_ONLY);
+	}
 
 	if (cpu_matches(NO_MELTDOWN))
 		return;
diff --git a/tools/power/x86/turbostat/Makefile b/tools/power/x86/turbostat/Makefile
index 1598b4fa0b11..045f5f7d68ab 100644
--- a/tools/power/x86/turbostat/Makefile
+++ b/tools/power/x86/turbostat/Makefile
@@ -9,7 +9,7 @@ ifeq ("$(origin O)", "command line")
 endif
 
 turbostat : turbostat.c
-override CFLAGS +=	-Wall
+override CFLAGS +=	-Wall -I../../../include
 override CFLAGS +=	-DMSRHEADER='"../../../../arch/x86/include/asm/msr-index.h"'
 override CFLAGS +=	-DINTEL_FAMILY_HEADER='"../../../../arch/x86/include/asm/intel-family.h"'
 
diff --git a/tools/power/x86/x86_energy_perf_policy/Makefile b/tools/power/x86/x86_energy_perf_policy/Makefile
index ae7a0e09b722..1fdeef864e7c 100644
--- a/tools/power/x86/x86_energy_perf_policy/Makefile
+++ b/tools/power/x86/x86_energy_perf_policy/Makefile
@@ -9,7 +9,7 @@ ifeq ("$(origin O)", "command line")
 endif
 
 x86_energy_perf_policy : x86_energy_perf_policy.c
-override CFLAGS +=	-Wall
+override CFLAGS +=	-Wall -I../../../include
 override CFLAGS +=	-DMSRHEADER='"../../../../arch/x86/include/asm/msr-index.h"'
 
 %: %.c

[patch V6 01/14] MDS basics 1

[Thomas Gleixner]

Subject: [patch V6 01/14] x86/msr-index: Cleanup bit defines
From: Thomas Gleixner <tglx@linutronix.de>

Greg pointed out that speculation related bit defines are using (1 << N)
format instead of BIT(N). Aside of that (1 << N) is wrong as it should use
1UL at least.

Clean it up.

[ Josh Poimboeuf: Fix tools build ]

Reported-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Borislav Petkov <bp@suse.de>
---
V5 -> V6: Fix tools build (Josh)
---
 arch/x86/include/asm/msr-index.h                |   34 ++++++++++++------------
 tools/power/x86/turbostat/Makefile              |    2 -
 tools/power/x86/x86_energy_perf_policy/Makefile |    2 -
 3 files changed, 20 insertions(+), 18 deletions(-)

--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -2,6 +2,8 @@
 #ifndef _ASM_X86_MSR_INDEX_H
 #define _ASM_X86_MSR_INDEX_H
 
+#include <linux/bits.h>
+
 /*
  * CPU model specific register (MSR) numbers.
  *
@@ -40,14 +42,14 @@
 /* Intel MSRs. Some also available on other CPUs */
 
 #define MSR_IA32_SPEC_CTRL		0x00000048 /* Speculation Control */
-#define SPEC_CTRL_IBRS			(1 << 0)   /* Indirect Branch Restricted Speculation */
+#define SPEC_CTRL_IBRS			BIT(0)	   /* Indirect Branch Restricted Speculation */
 #define SPEC_CTRL_STIBP_SHIFT		1	   /* Single Thread Indirect Branch Predictor (STIBP) bit */
-#define SPEC_CTRL_STIBP			(1 << SPEC_CTRL_STIBP_SHIFT)	/* STIBP mask */
+#define SPEC_CTRL_STIBP			BIT(SPEC_CTRL_STIBP_SHIFT)	/* STIBP mask */
 #define SPEC_CTRL_SSBD_SHIFT		2	   /* Speculative Store Bypass Disable bit */
-#define SPEC_CTRL_SSBD			(1 << SPEC_CTRL_SSBD_SHIFT)	/* Speculative Store Bypass Disable */
+#define SPEC_CTRL_SSBD			BIT(SPEC_CTRL_SSBD_SHIFT)	/* Speculative Store Bypass Disable */
 
 #define MSR_IA32_PRED_CMD		0x00000049 /* Prediction Command */
-#define PRED_CMD_IBPB			(1 << 0)   /* Indirect Branch Prediction Barrier */
+#define PRED_CMD_IBPB			BIT(0)	   /* Indirect Branch Prediction Barrier */
 
 #define MSR_PPIN_CTL			0x0000004e
 #define MSR_PPIN			0x0000004f
@@ -69,20 +71,20 @@
 #define MSR_MTRRcap			0x000000fe
 
 #define MSR_IA32_ARCH_CAPABILITIES	0x0000010a
-#define ARCH_CAP_RDCL_NO		(1 << 0)   /* Not susceptible to Meltdown */
-#define ARCH_CAP_IBRS_ALL		(1 << 1)   /* Enhanced IBRS support */
-#define ARCH_CAP_SKIP_VMENTRY_L1DFLUSH	(1 << 3)   /* Skip L1D flush on vmentry */
-#define ARCH_CAP_SSB_NO			(1 << 4)   /*
-						    * Not susceptible to Speculative Store Bypass
-						    * attack, so no Speculative Store Bypass
-						    * control required.
-						    */
+#define ARCH_CAP_RDCL_NO		BIT(0)	/* Not susceptible to Meltdown */
+#define ARCH_CAP_IBRS_ALL		BIT(1)	/* Enhanced IBRS support */
+#define ARCH_CAP_SKIP_VMENTRY_L1DFLUSH	BIT(3)	/* Skip L1D flush on vmentry */
+#define ARCH_CAP_SSB_NO			BIT(4)	/*
+						 * Not susceptible to Speculative Store Bypass
+						 * attack, so no Speculative Store Bypass
+						 * control required.
+						 */
 
 #define MSR_IA32_FLUSH_CMD		0x0000010b
-#define L1D_FLUSH			(1 << 0)   /*
-						    * Writeback and invalidate the
-						    * L1 data cache.
-						    */
+#define L1D_FLUSH			BIT(0)	/*
+						 * Writeback and invalidate the
+						 * L1 data cache.
+						 */
 
 #define MSR_IA32_BBL_CR_CTL		0x00000119
 #define MSR_IA32_BBL_CR_CTL3		0x0000011e
--- a/tools/power/x86/turbostat/Makefile
+++ b/tools/power/x86/turbostat/Makefile
@@ -9,7 +9,7 @@ ifeq ("$(origin O)", "command line")
 endif
 
 turbostat : turbostat.c
-override CFLAGS +=	-Wall
+override CFLAGS +=	-Wall -I../../../include
 override CFLAGS +=	-DMSRHEADER='"../../../../arch/x86/include/asm/msr-index.h"'
 override CFLAGS +=	-DINTEL_FAMILY_HEADER='"../../../../arch/x86/include/asm/intel-family.h"'
 
--- a/tools/power/x86/x86_energy_perf_policy/Makefile
+++ b/tools/power/x86/x86_energy_perf_policy/Makefile
@@ -9,7 +9,7 @@ ifeq ("$(origin O)", "command line")
 endif
 
 x86_energy_perf_policy : x86_energy_perf_policy.c
-override CFLAGS +=	-Wall
+override CFLAGS +=	-Wall -I../../../include
 override CFLAGS +=	-DMSRHEADER='"../../../../arch/x86/include/asm/msr-index.h"'
 
 %: %.c

[patch V6 02/14] MDS basics 2

[Thomas Gleixner]

Subject: [patch V6 02/14] x86/speculation: Consolidate CPU whitelists
From: Thomas Gleixner <tglx@linutronix.de>

The CPU vulnerability whitelists have some overlap and there are more
whitelists coming along.

Use the driver_data field in the x86_cpu_id struct to denote the
whitelisted vulnerabilities and combine all whitelists into one.

Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---

V5 --> V6: Use a helper macro to make it more readable
           Fix the AMD family 0xf-0x12 vs. ANY ordering
---
 arch/x86/kernel/cpu/common.c |  110 +++++++++++++++++++++++--------------------
 1 file changed, 60 insertions(+), 50 deletions(-)

--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -948,61 +948,72 @@ static void identify_cpu_without_cpuid(s
 #endif
 }
 
-static const __initconst struct x86_cpu_id cpu_no_speculation[] = {
-	{ X86_VENDOR_INTEL,	6, INTEL_FAM6_ATOM_SALTWELL,	X86_FEATURE_ANY },
-	{ X86_VENDOR_INTEL,	6, INTEL_FAM6_ATOM_SALTWELL_TABLET,	X86_FEATURE_ANY },
-	{ X86_VENDOR_INTEL,	6, INTEL_FAM6_ATOM_BONNELL_MID,	X86_FEATURE_ANY },
-	{ X86_VENDOR_INTEL,	6, INTEL_FAM6_ATOM_SALTWELL_MID,	X86_FEATURE_ANY },
-	{ X86_VENDOR_INTEL,	6, INTEL_FAM6_ATOM_BONNELL,	X86_FEATURE_ANY },
-	{ X86_VENDOR_CENTAUR,	5 },
-	{ X86_VENDOR_INTEL,	5 },
-	{ X86_VENDOR_NSC,	5 },
-	{ X86_VENDOR_ANY,	4 },
+#define NO_SPECULATION	BIT(0)
+#define NO_MELTDOWN	BIT(1)
+#define NO_SSB		BIT(2)
+#define NO_L1TF		BIT(3)
+
+#define VULNWL(_vendor, _family, _model, _whitelist)	\
+	{ X86_VENDOR_##_vendor, _family, _model, X86_FEATURE_ANY, _whitelist }
+
+#define VULNWL_INTEL(model, whitelist)		\
+	VULNWL(INTEL, 6, INTEL_FAM6_##model, whitelist)
+
+#define VULNWL_AMD(family, whitelist)		\
+	VULNWL(AMD, family, X86_MODEL_ANY, whitelist)
+
+#define VULNWL_HYGON(family, whitelist)		\
+	VULNWL(HYGON, family, X86_MODEL_ANY, whitelist)
+
+static const __initconst struct x86_cpu_id cpu_vuln_whitelist[] = {
+	VULNWL(ANY,	4, X86_MODEL_ANY,	NO_SPECULATION),
+	VULNWL(CENTAUR,	5, X86_MODEL_ANY,	NO_SPECULATION),
+	VULNWL(INTEL,	5, X86_MODEL_ANY,	NO_SPECULATION),
+	VULNWL(NSC,	5, X86_MODEL_ANY,	NO_SPECULATION),
+
+	VULNWL_INTEL(ATOM_SALTWELL,		NO_SPECULATION),
+	VULNWL_INTEL(ATOM_SALTWELL_TABLET,	NO_SPECULATION),
+	VULNWL_INTEL(ATOM_SALTWELL_MID,		NO_SPECULATION),
+	VULNWL_INTEL(ATOM_BONNELL,		NO_SPECULATION),
+	VULNWL_INTEL(ATOM_BONNELL_MID,		NO_SPECULATION),
+
+	VULNWL_INTEL(ATOM_SILVERMONT,		NO_SSB | NO_L1TF),
+	VULNWL_INTEL(ATOM_SILVERMONT_X,		NO_SSB | NO_L1TF),
+	VULNWL_INTEL(ATOM_SILVERMONT_MID,	NO_SSB | NO_L1TF),
+	VULNWL_INTEL(ATOM_AIRMONT,		NO_SSB | NO_L1TF),
+	VULNWL_INTEL(XEON_PHI_KNL,		NO_SSB | NO_L1TF),
+	VULNWL_INTEL(XEON_PHI_KNM,		NO_SSB | NO_L1TF),
+
+	VULNWL_INTEL(CORE_YONAH,		NO_SSB),
+
+	VULNWL_INTEL(ATOM_AIRMONT_MID,		NO_L1TF),
+	VULNWL_INTEL(ATOM_GOLDMONT,		NO_L1TF),
+	VULNWL_INTEL(ATOM_GOLDMONT_X,		NO_L1TF),
+	VULNWL_INTEL(ATOM_GOLDMONT_PLUS,	NO_L1TF),
+
+	VULNWL_AMD(0x0f,		NO_MELTDOWN | NO_SSB | NO_L1TF),
+	VULNWL_AMD(0x10,		NO_MELTDOWN | NO_SSB | NO_L1TF),
+	VULNWL_AMD(0x11,		NO_MELTDOWN | NO_SSB | NO_L1TF),
+	VULNWL_AMD(0x12,		NO_MELTDOWN | NO_SSB | NO_L1TF),
+
+	/* FAMILY_ANY must be last, otherwise 0x0f - 0x12 matches won't work */
+	VULNWL_AMD(X86_FAMILY_ANY,	NO_MELTDOWN | NO_L1TF),
+	VULNWL_HYGON(X86_FAMILY_ANY,	NO_MELTDOWN | NO_L1TF),
 	{}
 };
 
-static const __initconst struct x86_cpu_id cpu_no_meltdown[] = {
-	{ X86_VENDOR_AMD },
-	{ X86_VENDOR_HYGON },
-	{}
-};
-
-/* Only list CPUs which speculate but are non susceptible to SSB */
-static const __initconst struct x86_cpu_id cpu_no_spec_store_bypass[] = {
-	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_ATOM_SILVERMONT	},
-	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_ATOM_AIRMONT		},
-	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_ATOM_SILVERMONT_X	},
-	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_ATOM_SILVERMONT_MID	},
-	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_CORE_YONAH		},
-	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_XEON_PHI_KNL		},
-	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_XEON_PHI_KNM		},
-	{ X86_VENDOR_AMD,	0x12,					},
-	{ X86_VENDOR_AMD,	0x11,					},
-	{ X86_VENDOR_AMD,	0x10,					},
-	{ X86_VENDOR_AMD,	0xf,					},
-	{}
-};
+static bool __init cpu_matches(unsigned long which)
+{
+	const struct x86_cpu_id *m = x86_match_cpu(cpu_vuln_whitelist);
 
-static const __initconst struct x86_cpu_id cpu_no_l1tf[] = {
-	/* in addition to cpu_no_speculation */
-	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_ATOM_SILVERMONT	},
-	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_ATOM_SILVERMONT_X	},
-	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_ATOM_AIRMONT		},
-	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_ATOM_SILVERMONT_MID	},
-	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_ATOM_AIRMONT_MID	},
-	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_ATOM_GOLDMONT	},
-	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_ATOM_GOLDMONT_X	},
-	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_ATOM_GOLDMONT_PLUS	},
-	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_XEON_PHI_KNL		},
-	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_XEON_PHI_KNM		},
-	{}
-};
+	return m && !!(m->driver_data & which);
+}
 
 static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)
 {
 	u64 ia32_cap = 0;
 
-	if (x86_match_cpu(cpu_no_speculation))
+	if (cpu_matches(NO_SPECULATION))
 		return;
 
 	setup_force_cpu_bug(X86_BUG_SPECTRE_V1);
@@ -1011,15 +1022,14 @@ static void __init cpu_set_bug_bits(stru
 	if (cpu_has(c, X86_FEATURE_ARCH_CAPABILITIES))
 		rdmsrl(MSR_IA32_ARCH_CAPABILITIES, ia32_cap);
 
-	if (!x86_match_cpu(cpu_no_spec_store_bypass) &&
-	   !(ia32_cap & ARCH_CAP_SSB_NO) &&
+	if (!cpu_matches(NO_SSB) && !(ia32_cap & ARCH_CAP_SSB_NO) &&
 	   !cpu_has(c, X86_FEATURE_AMD_SSB_NO))
 		setup_force_cpu_bug(X86_BUG_SPEC_STORE_BYPASS);
 
 	if (ia32_cap & ARCH_CAP_IBRS_ALL)
 		setup_force_cpu_cap(X86_FEATURE_IBRS_ENHANCED);
 
-	if (x86_match_cpu(cpu_no_meltdown))
+	if (cpu_matches(NO_MELTDOWN))
 		return;
 
 	/* Rogue Data Cache Load? No! */
@@ -1028,7 +1038,7 @@ static void __init cpu_set_bug_bits(stru
 
 	setup_force_cpu_bug(X86_BUG_CPU_MELTDOWN);
 
-	if (x86_match_cpu(cpu_no_l1tf))
+	if (cpu_matches(NO_L1TF))
 		return;
 
 	setup_force_cpu_bug(X86_BUG_L1TF);

[patch V6 03/14] MDS basics 3

[Thomas Gleixner]

Subject: [patch V6 03/14] x86/speculation/mds: Add basic bug infrastructure for MDS
From: Andi Kleen <ak@linux.intel.com>

Microarchitectural Data Sampling (MDS), is a class of side channel attacks
on internal buffers in Intel CPUs. The variants are:

 - Microarchitectural Store Buffer Data Sampling (MSBDS) (CVE-2018-12126)
 - Microarchitectural Fill Buffer Data Sampling (MFBDS) (CVE-2018-12130)
 - Microarchitectural Load Port Data Sampling (MLPDS) (CVE-2018-12127)

MSBDS leaks Store Buffer Entries which can be speculatively forwarded to a
dependent load (store-to-load forwarding) as an optimization. The forward
can also happen to a faulting or assisting load operation for a different
memory address, which can be exploited under certain conditions. Store
buffers are partitioned between Hyper-Threads so cross thread forwarding is
not possible. But if a thread enters or exits a sleep state the store
buffer is repartitioned which can expose data from one thread to the other.

MFBDS leaks Fill Buffer Entries. Fill buffers are used internally to manage
L1 miss situations and to hold data which is returned or sent in response
to a memory or I/O operation. Fill buffers can forward data to a load
operation and also write data to the cache. When the fill buffer is
deallocated it can retain the stale data of the preceding operations which
can then be forwarded to a faulting or assisting load operation, which can
be exploited under certain conditions. Fill buffers are shared between
Hyper-Threads so cross thread leakage is possible.

MLDPS leaks Load Port Data. Load ports are used to perform load operations
from memory or I/O. The received data is then forwarded to the register
file or a subsequent operation. In some implementations the Load Port can
contain stale data from a previous operation which can be forwarded to
faulting or assisting loads under certain conditions, which again can be
exploited eventually. Load ports are shared between Hyper-Threads so cross
thread leakage is possible.

All variants have the same mitigation for single CPU thread case (SMT off),
so the kernel can treat them as one MDS issue.

Add the basic infrastructure to detect if the current CPU is affected by
MDS.

[ tglx: Rewrote changelog ]

Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
V5: Adopt to the consolidated quirk table
V3: Addressed Borislav's review comments
---
 arch/x86/include/asm/cpufeatures.h |    2 ++
 arch/x86/include/asm/msr-index.h   |    5 +++++
 arch/x86/kernel/cpu/common.c       |   27 +++++++++++++++++----------
 3 files changed, 24 insertions(+), 10 deletions(-)

--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -344,6 +344,7 @@
 /* Intel-defined CPU features, CPUID level 0x00000007:0 (EDX), word 18 */
 #define X86_FEATURE_AVX512_4VNNIW	(18*32+ 2) /* AVX-512 Neural Network Instructions */
 #define X86_FEATURE_AVX512_4FMAPS	(18*32+ 3) /* AVX-512 Multiply Accumulation Single precision */
+#define X86_FEATURE_MD_CLEAR		(18*32+10) /* VERW clears CPU buffers */
 #define X86_FEATURE_PCONFIG		(18*32+18) /* Intel PCONFIG */
 #define X86_FEATURE_SPEC_CTRL		(18*32+26) /* "" Speculation Control (IBRS + IBPB) */
 #define X86_FEATURE_INTEL_STIBP		(18*32+27) /* "" Single Thread Indirect Branch Predictors */
@@ -381,5 +382,6 @@
 #define X86_BUG_SPECTRE_V2		X86_BUG(16) /* CPU is affected by Spectre variant 2 attack with indirect branches */
 #define X86_BUG_SPEC_STORE_BYPASS	X86_BUG(17) /* CPU is affected by speculative store bypass attack */
 #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 */
 
 #endif /* _ASM_X86_CPUFEATURES_H */
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -79,6 +79,11 @@
 						 * attack, so no Speculative Store Bypass
 						 * control required.
 						 */
+#define ARCH_CAP_MDS_NO			BIT(5)   /*
+						  * Not susceptible to
+						  * Microarchitectural Data
+						  * Sampling (MDS) vulnerabilities.
+						  */
 
 #define MSR_IA32_FLUSH_CMD		0x0000010b
 #define L1D_FLUSH			BIT(0)	/*
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -952,6 +952,7 @@ static void identify_cpu_without_cpuid(s
 #define NO_MELTDOWN	BIT(1)
 #define NO_SSB		BIT(2)
 #define NO_L1TF		BIT(3)
+#define NO_MDS		BIT(4)
 
 #define VULNWL(_vendor, _family, _model, _whitelist)	\
 	{ X86_VENDOR_##_vendor, _family, _model, X86_FEATURE_ANY, _whitelist }
@@ -971,6 +972,7 @@ static const __initconst struct x86_cpu_
 	VULNWL(INTEL,	5, X86_MODEL_ANY,	NO_SPECULATION),
 	VULNWL(NSC,	5, X86_MODEL_ANY,	NO_SPECULATION),
 
+	/* Intel Family 6 */
 	VULNWL_INTEL(ATOM_SALTWELL,		NO_SPECULATION),
 	VULNWL_INTEL(ATOM_SALTWELL_TABLET,	NO_SPECULATION),
 	VULNWL_INTEL(ATOM_SALTWELL_MID,		NO_SPECULATION),
@@ -987,18 +989,20 @@ static const __initconst struct x86_cpu_
 	VULNWL_INTEL(CORE_YONAH,		NO_SSB),
 
 	VULNWL_INTEL(ATOM_AIRMONT_MID,		NO_L1TF),
-	VULNWL_INTEL(ATOM_GOLDMONT,		NO_L1TF),
-	VULNWL_INTEL(ATOM_GOLDMONT_X,		NO_L1TF),
-	VULNWL_INTEL(ATOM_GOLDMONT_PLUS,	NO_L1TF),
-
-	VULNWL_AMD(0x0f,		NO_MELTDOWN | NO_SSB | NO_L1TF),
-	VULNWL_AMD(0x10,		NO_MELTDOWN | NO_SSB | NO_L1TF),
-	VULNWL_AMD(0x11,		NO_MELTDOWN | NO_SSB | NO_L1TF),
-	VULNWL_AMD(0x12,		NO_MELTDOWN | NO_SSB | NO_L1TF),
+
+	VULNWL_INTEL(ATOM_GOLDMONT,		NO_MDS | NO_L1TF),
+	VULNWL_INTEL(ATOM_GOLDMONT_X,		NO_MDS | NO_L1TF),
+	VULNWL_INTEL(ATOM_GOLDMONT_PLUS,	NO_MDS | NO_L1TF),
+
+	/* AMD Family 0xf - 0x12 */
+	VULNWL_AMD(0x0f,	NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS),
+	VULNWL_AMD(0x10,	NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS),
+	VULNWL_AMD(0x11,	NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS),
+	VULNWL_AMD(0x12,	NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS),
 
 	/* FAMILY_ANY must be last, otherwise 0x0f - 0x12 matches won't work */
-	VULNWL_AMD(X86_FAMILY_ANY,	NO_MELTDOWN | NO_L1TF),
-	VULNWL_HYGON(X86_FAMILY_ANY,	NO_MELTDOWN | NO_L1TF),
+	VULNWL_AMD(X86_FAMILY_ANY,	NO_MELTDOWN | NO_L1TF | NO_MDS),
+	VULNWL_HYGON(X86_FAMILY_ANY,	NO_MELTDOWN | NO_L1TF | NO_MDS),
 	{}
 };
 
@@ -1029,6 +1033,9 @@ static void __init cpu_set_bug_bits(stru
 	if (ia32_cap & ARCH_CAP_IBRS_ALL)
 		setup_force_cpu_cap(X86_FEATURE_IBRS_ENHANCED);
 
+	if (!cpu_matches(NO_MDS) && !(ia32_cap & ARCH_CAP_MDS_NO))
+		setup_force_cpu_bug(X86_BUG_MDS);
+
 	if (cpu_matches(NO_MELTDOWN))
 		return;
 

[patch V6 04/14] MDS basics 4

[Thomas Gleixner]

Subject: [patch V6 04/14] x86/speculation/mds: Add BUG_MSBDS_ONLY
From: Thomas Gleixner <tglx@linutronix.de>

This bug bit is set on CPUs which are only affected by Microarchitectural
Store Buffer Data Sampling (MSBDS) and not by any other MDS variant.

This is important because the Store Buffers are partitioned between
Hyper-Threads so cross thread forwarding is not possible. But if a thread
enters or exits a sleep state the store buffer is repartitioned which can
expose data from one thread to the other. This transition can be mitigated.

That means that for CPUs which are only affected by MSBDS SMT can be
enabled, if the CPU is not affected by other SMT sensitive vulnerabilities,
e.g. L1TF. The XEON PHI variants fall into that category.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/include/asm/cpufeatures.h |    1 +
 arch/x86/kernel/cpu/common.c       |   10 +++++++---
 2 files changed, 8 insertions(+), 3 deletions(-)

--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -383,5 +383,6 @@
 #define X86_BUG_SPEC_STORE_BYPASS	X86_BUG(17) /* CPU is affected by speculative store bypass attack */
 #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 */
 
 #endif /* _ASM_X86_CPUFEATURES_H */
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -953,6 +953,7 @@ static void identify_cpu_without_cpuid(s
 #define NO_SSB		BIT(2)
 #define NO_L1TF		BIT(3)
 #define NO_MDS		BIT(4)
+#define MSBDS_ONLY	BIT(5)
 
 #define VULNWL(_vendor, _family, _model, _whitelist)	\
 	{ X86_VENDOR_##_vendor, _family, _model, X86_FEATURE_ANY, _whitelist }
@@ -983,8 +984,8 @@ static const __initconst struct x86_cpu_
 	VULNWL_INTEL(ATOM_SILVERMONT_X,		NO_SSB | NO_L1TF),
 	VULNWL_INTEL(ATOM_SILVERMONT_MID,	NO_SSB | NO_L1TF),
 	VULNWL_INTEL(ATOM_AIRMONT,		NO_SSB | NO_L1TF),
-	VULNWL_INTEL(XEON_PHI_KNL,		NO_SSB | NO_L1TF),
-	VULNWL_INTEL(XEON_PHI_KNM,		NO_SSB | NO_L1TF),
+	VULNWL_INTEL(XEON_PHI_KNL,		NO_SSB | NO_L1TF | MSBDS_ONLY),
+	VULNWL_INTEL(XEON_PHI_KNM,		NO_SSB | NO_L1TF | MSBDS_ONLY),
 
 	VULNWL_INTEL(CORE_YONAH,		NO_SSB),
 
@@ -1033,8 +1034,11 @@ static void __init cpu_set_bug_bits(stru
 	if (ia32_cap & ARCH_CAP_IBRS_ALL)
 		setup_force_cpu_cap(X86_FEATURE_IBRS_ENHANCED);
 
-	if (!cpu_matches(NO_MDS) && !(ia32_cap & ARCH_CAP_MDS_NO))
+	if (!cpu_matches(NO_MDS) && !(ia32_cap & ARCH_CAP_MDS_NO)) {
 		setup_force_cpu_bug(X86_BUG_MDS);
+		if (cpu_matches(MSBDS_ONLY))
+			setup_force_cpu_bug(X86_BUG_MSBDS_ONLY);
+	}
 
 	if (cpu_matches(NO_MELTDOWN))
 		return;

[patch V6 05/14] MDS basics 5

[Thomas Gleixner]

From: Andi Kleen <ak@linux.intel.com>
Subject: [patch V6 05/14] x86/kvm: Expose X86_FEATURE_MD_CLEAR to guests

X86_FEATURE_MD_CLEAR is a new CPUID bit which is set when microcode
provides the mechanism to invoke a flush of various exploitable CPU buffers
by invoking the VERW instruction.

Hand it through to guests so they can adjust their mitigations.

This also requires corresponding qemu changes, which are available
separately.

[ tglx: Massaged changelog ]

Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 arch/x86/kvm/cpuid.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -410,7 +410,8 @@ static inline int __do_cpuid_ent(struct
 	/* cpuid 7.0.edx*/
 	const u32 kvm_cpuid_7_0_edx_x86_features =
 		F(AVX512_4VNNIW) | F(AVX512_4FMAPS) | F(SPEC_CTRL) |
-		F(SPEC_CTRL_SSBD) | F(ARCH_CAPABILITIES) | F(INTEL_STIBP);
+		F(SPEC_CTRL_SSBD) | F(ARCH_CAPABILITIES) | F(INTEL_STIBP) |
+		F(MD_CLEAR);
 
 	/* all calls to cpuid_count() should be made on the same cpu */
 	get_cpu();

[patch V6 06/14] MDS basics 6

[Thomas Gleixner]

Subject: [patch V6 06/14] x86/speculation/mds: Add mds_clear_cpu_buffers()
From: Thomas Gleixner <tglx@linutronix.de>

The Microarchitectural Data Sampling (MDS) vulernabilities are mitigated by
clearing the affected CPU buffers. The mechanism for clearing the buffers
uses the unused and obsolete VERW instruction in combination with a
microcode update which triggers a CPU buffer clear when VERW is executed.

Provide a inline function with the assembly magic. The argument of the VERW
instruction must be a memory operand as documented:

  "MD_CLEAR enumerates that the memory-operand variant of VERW (for
   example, VERW m16) has been extended to also overwrite buffers affected
   by MDS. This buffer overwriting functionality is not guaranteed for the
   register operand variant of VERW."

Documentation also recommends to use a writable data segment selector:

  "The buffer overwriting occurs regardless of the result of the VERW
   permission check, as well as when the selector is null or causes a
   descriptor load segment violation. However, for lowest latency we
   recommend using a selector that indicates a valid writable data
   segment."

Add x86 specific documentation about MDS and the internal workings of the
mitigation.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
---
v4 --> V5: Fix typos and remove the conditional mode reference.

V3 --> V4: Document the segment selecor choice as well.

V2 --> V3: Add VERW documentation and fix typos/grammar..., dropped 'i(0)'
       	   Add more details fo the documentation file

V1 --> V2: Add "cc" clobber and documentation
---
 Documentation/index.rst              |    1 
 Documentation/x86/conf.py            |   10 +++
 Documentation/x86/index.rst          |    8 ++
 Documentation/x86/mds.rst            |   99 +++++++++++++++++++++++++++++++++++
 arch/x86/include/asm/nospec-branch.h |   25 ++++++++
 5 files changed, 143 insertions(+)

--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -101,6 +101,7 @@ implementation.
    :maxdepth: 2
 
    sh/index
+   x86/index
 
 Filesystem Documentation
 ------------------------
--- /dev/null
+++ b/Documentation/x86/conf.py
@@ -0,0 +1,10 @@
+# -*- coding: utf-8; mode: python -*-
+
+project = "X86 architecture specific documentation"
+
+tags.add("subproject")
+
+latex_documents = [
+    ('index', 'x86.tex', project,
+     'The kernel development community', 'manual'),
+]
--- /dev/null
+++ b/Documentation/x86/index.rst
@@ -0,0 +1,8 @@
+==========================
+x86 architecture specifics
+==========================
+
+.. toctree::
+   :maxdepth: 1
+
+   mds
--- /dev/null
+++ b/Documentation/x86/mds.rst
@@ -0,0 +1,99 @@
+Microarchitectural Data Sampling (MDS) mitigation
+=================================================
+
+.. _mds:
+
+Overview
+--------
+
+Microarchitectural Data Sampling (MDS) is a family of side channel attacks
+on internal buffers in Intel CPUs. The variants are:
+
+ - Microarchitectural Store Buffer Data Sampling (MSBDS) (CVE-2018-12126)
+ - Microarchitectural Fill Buffer Data Sampling (MFBDS) (CVE-2018-12130)
+ - Microarchitectural Load Port Data Sampling (MLPDS) (CVE-2018-12127)
+
+MSBDS leaks Store Buffer Entries which can be speculatively forwarded to a
+dependent load (store-to-load forwarding) as an optimization. The forward
+can also happen to a faulting or assisting load operation for a different
+memory address, which can be exploited under certain conditions. Store
+buffers are partitioned between Hyper-Threads so cross thread forwarding is
+not possible. But if a thread enters or exits a sleep state the store
+buffer is repartitioned which can expose data from one thread to the other.
+
+MFBDS leaks Fill Buffer Entries. Fill buffers are used internally to manage
+L1 miss situations and to hold data which is returned or sent in response
+to a memory or I/O operation. Fill buffers can forward data to a load
+operation and also write data to the cache. When the fill buffer is
+deallocated it can retain the stale data of the preceding operations which
+can then be forwarded to a faulting or assisting load operation, which can
+be exploited under certain conditions. Fill buffers are shared between
+Hyper-Threads so cross thread leakage is possible.
+
+MLPDS leaks Load Port Data. Load ports are used to perform load operations
+from memory or I/O. The received data is then forwarded to the register
+file or a subsequent operation. In some implementations the Load Port can
+contain stale data from a previous operation which can be forwarded to
+faulting or assisting loads under certain conditions, which again can be
+exploited eventually. Load ports are shared between Hyper-Threads so cross
+thread leakage is possible.
+
+
+Exposure assumptions
+--------------------
+
+It is assumed that attack code resides in user space or in a guest with one
+exception. The rationale behind this assumption is that the code construct
+needed for exploiting MDS requires:
+
+ - to control the load to trigger a fault or assist
+
+ - to have a disclosure gadget which exposes the speculatively accessed
+   data for consumption through a side channel.
+
+ - to control the pointer through which the disclosure gadget exposes the
+   data
+
+The existence of such a construct in the kernel cannot be excluded with
+100% certainty, but the complexity involved makes it extremly unlikely.
+
+There is one exception, which is untrusted BPF. The functionality of
+untrusted BPF is limited, but it needs to be thoroughly investigated
+whether it can be used to create such a construct.
+
+
+Mitigation strategy
+-------------------
+
+All variants have the same mitigation strategy at least for the single CPU
+thread case (SMT off): Force the CPU to clear the affected buffers.
+
+This is achieved by using the otherwise unused and obsolete VERW
+instruction in combination with a microcode update. The microcode clears
+the affected CPU buffers when the VERW instruction is executed.
+
+For virtualization there are two ways to achieve CPU buffer
+clearing. Either the modified VERW instruction or via the L1D Flush
+command. The latter is issued when L1TF mitigation is enabled so the extra
+VERW can be avoided. If the CPU is not affected by L1TF then VERW needs to
+be issued.
+
+If the VERW instruction with the supplied segment selector argument is
+executed on a CPU without the microcode update there is no side effect
+other than a small number of pointlessly wasted CPU cycles.
+
+This does not protect against cross Hyper-Thread attacks except for MSBDS
+which is only exploitable cross Hyper-thread when one of the Hyper-Threads
+enters a C-state.
+
+The kernel provides a function to invoke the buffer clearing:
+
+    mds_clear_cpu_buffers()
+
+The mitigation is invoked on kernel/userspace, hypervisor/guest and C-state
+(idle) transitions.
+
+According to current knowledge additional mitigations inside the kernel
+itself are not required because the necessary gadgets to expose the leaked
+data cannot be controlled in a way which allows exploitation from malicious
+user space or VM guests.
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -318,6 +318,31 @@ DECLARE_STATIC_KEY_FALSE(switch_to_cond_
 DECLARE_STATIC_KEY_FALSE(switch_mm_cond_ibpb);
 DECLARE_STATIC_KEY_FALSE(switch_mm_always_ibpb);
 
+#include <asm/segment.h>
+
+/**
+ * mds_clear_cpu_buffers - Mitigation for MDS vulnerability
+ *
+ * This uses the otherwise unused and obsolete VERW instruction in
+ * combination with microcode which triggers a CPU buffer flush when the
+ * instruction is executed.
+ */
+static inline void mds_clear_cpu_buffers(void)
+{
+	static const u16 ds = __KERNEL_DS;
+
+	/*
+	 * Has to be the memory-operand variant because only that
+	 * guarantees the CPU buffer flush functionality according to
+	 * documentation. The register-operand variant does not.
+	 * Works with any segment selector, but a valid writable
+	 * data segment is the fastest variant.
+	 *
+	 * "cc" clobber is required because VERW modifies ZF.
+	 */
+	asm volatile("verw %[ds]" : : [ds] "m" (ds) : "cc");
+}
+
 #endif /* __ASSEMBLY__ */
 
 /*

[patch V6 07/14] MDS basics 7

[Thomas Gleixner]

Subject: [patch V6 07/14] x86/speculation/mds: Clear CPU buffers on exit to user
From: Thomas Gleixner <tglx@linutronix.de>

Add a static key which controls the invocation of the CPU buffer clear
mechanism on exit to user space and add the call into
prepare_exit_to_usermode() and do_nmi() right before actually returning.

Add documentation which kernel to user space transition this covers and
explain why some corner cases are not mitigated.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
V4 --> v5: Use an inline helper instead of open coding it.
	   Rework the documentation paragraph about exceptions.

V3 --> V4: Add #DS mitigation and document that the #MC corner case
       	   is really not interesting.

V3: Add NMI conditional on user regs and update documentation accordingly.
    Use the static branch scheme suggested by Peter. Fix typos ...
---
 Documentation/x86/mds.rst            |   52 +++++++++++++++++++++++++++++++++++
 arch/x86/entry/common.c              |    3 ++
 arch/x86/include/asm/nospec-branch.h |   13 ++++++++
 arch/x86/kernel/cpu/bugs.c           |    3 ++
 arch/x86/kernel/nmi.c                |    4 ++
 arch/x86/kernel/traps.c              |    7 ++++
 6 files changed, 82 insertions(+)

--- a/Documentation/x86/mds.rst
+++ b/Documentation/x86/mds.rst
@@ -97,3 +97,55 @@ According to current knowledge additiona
 itself are not required because the necessary gadgets to expose the leaked
 data cannot be controlled in a way which allows exploitation from malicious
 user space or VM guests.
+
+Mitigation points
+-----------------
+
+1. Return to user space
+^^^^^^^^^^^^^^^^^^^^^^^
+
+   When transitioning from kernel to user space the CPU buffers are flushed
+   on affected CPUs when the mitigation is not disabled on the kernel
+   command line. The migitation is enabled through the static key
+   mds_user_clear.
+
+   The mitigation is invoked in prepare_exit_to_usermode() which covers
+   most of the kernel to user space transitions. There are a few exceptions
+   which are not invoking prepare_exit_to_usermode() on return to user
+   space. These exceptions use the paranoid exit code.
+
+   - Non Maskable Interrupt (NMI):
+
+     Access to sensible data like keys, credentials in the NMI context is
+     mostly theoretical: The CPU can do prefetching or execute a
+     misspeculated code path and thereby fetching data which might end up
+     leaking through a buffer.
+
+     But for mounting other attacks the kernel stack address of the task is
+     already valuable information. So in full mitigation mode, the NMI is
+     mitigated on the return from do_nmi() to provide almost complete
+     coverage.
+
+   - Double fault (#DF):
+
+     A double fault is usually fatal, but the ESPFIX workaround, which can
+     be triggered from user space through modify_ldt(2) is a recoverable
+     double fault. #DF uses the paranoid exit path, so explicit mitigation
+     in the double fault handler is required.
+
+   - Machine Check Exception (#MC):
+
+     Another corner case is a #MC which hits between the CPU buffer clear
+     invocation and the actual return to user. As this still is in kernel
+     space it takes the paranoid exit path which does not clear the CPU
+     buffers. So the #MC handler repopulates the buffers to some
+     extent. Machine checks are not reliably controllable and the window is
+     extremly small so mitigation would just tick a checkbox that this
+     theoretical corner case is covered. To keep the amount of special
+     cases small, ignore #MC.
+
+   - Debug Exception (#DB):
+
+     This takes the paranoid exit path only when the INT1 breakpoint is in
+     kernel space. #DB on a user space address takes the regular exit path,
+     so no extra mitigation required.
--- a/arch/x86/entry/common.c
+++ b/arch/x86/entry/common.c
@@ -31,6 +31,7 @@
 #include <asm/vdso.h>
 #include <linux/uaccess.h>
 #include <asm/cpufeature.h>
+#include <asm/nospec-branch.h>
 
 #define CREATE_TRACE_POINTS
 #include <trace/events/syscalls.h>
@@ -212,6 +213,8 @@ static void exit_to_usermode_loop(struct
 #endif
 
 	user_enter_irqoff();
+
+	mds_user_clear_cpu_buffers();
 }
 
 #define SYSCALL_EXIT_WORK_FLAGS				\
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -318,6 +318,8 @@ DECLARE_STATIC_KEY_FALSE(switch_to_cond_
 DECLARE_STATIC_KEY_FALSE(switch_mm_cond_ibpb);
 DECLARE_STATIC_KEY_FALSE(switch_mm_always_ibpb);
 
+DECLARE_STATIC_KEY_FALSE(mds_user_clear);
+
 #include <asm/segment.h>
 
 /**
@@ -343,6 +345,17 @@ static inline void mds_clear_cpu_buffers
 	asm volatile("verw %[ds]" : : [ds] "m" (ds) : "cc");
 }
 
+/**
+ * mds_user_clear_cpu_buffers - Mitigation for MDS vulnerability
+ *
+ * Clear CPU buffers if the corresponding static key is enabled
+ */
+static inline void mds_user_clear_cpu_buffers(void)
+{
+	if (static_branch_likely(&mds_user_clear))
+		mds_clear_cpu_buffers();
+}
+
 #endif /* __ASSEMBLY__ */
 
 /*
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -63,6 +63,9 @@ DEFINE_STATIC_KEY_FALSE(switch_mm_cond_i
 /* Control unconditional IBPB in switch_mm() */
 DEFINE_STATIC_KEY_FALSE(switch_mm_always_ibpb);
 
+/* Control MDS CPU buffer clear before returning to user space */
+DEFINE_STATIC_KEY_FALSE(mds_user_clear);
+
 void __init check_bugs(void)
 {
 	identify_boot_cpu();
--- a/arch/x86/kernel/nmi.c
+++ b/arch/x86/kernel/nmi.c
@@ -34,6 +34,7 @@
 #include <asm/x86_init.h>
 #include <asm/reboot.h>
 #include <asm/cache.h>
+#include <asm/nospec-branch.h>
 
 #define CREATE_TRACE_POINTS
 #include <trace/events/nmi.h>
@@ -533,6 +534,9 @@ do_nmi(struct pt_regs *regs, long error_
 		write_cr2(this_cpu_read(nmi_cr2));
 	if (this_cpu_dec_return(nmi_state))
 		goto nmi_restart;
+
+	if (user_mode(regs))
+		mds_user_clear_cpu_buffers();
 }
 NOKPROBE_SYMBOL(do_nmi);
 
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -366,6 +366,13 @@ dotraplinkage void do_double_fault(struc
 		regs->ip = (unsigned long)general_protection;
 		regs->sp = (unsigned long)&gpregs->orig_ax;
 
+		/*
+		 * This situation can be triggered by userspace via
+		 * modify_ldt(2) and the return does not take the regular
+		 * user space exit, so a CPU buffer clear is required when
+		 * MDS mitigation is enabled.
+		 */
+		mds_user_clear_cpu_buffers();
 		return;
 	}
 #endif

[patch V6 08/14] MDS basics 8

[Thomas Gleixner]

CPUs which are affected by L1TF and MDS mitigate MDS with the L1D Flush on
VMENTER when updated microcode is installed.

If a CPU is not affected by L1TF or if the L1D Flush is not in use, then
MDS mitigation needs to be invoked explicit.

For these cases, follow the host mitigation state and invoke the MDS
mitigation before VMENTER.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
V4 --> V5: Fix changelog
---
 arch/x86/kernel/cpu/bugs.c |    1 +
 arch/x86/kvm/vmx/vmx.c     |    2 ++
 2 files changed, 3 insertions(+)

--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -65,6 +65,7 @@ DEFINE_STATIC_KEY_FALSE(switch_mm_always
 
 /* Control MDS CPU buffer clear before returning to user space */
 DEFINE_STATIC_KEY_FALSE(mds_user_clear);
+EXPORT_SYMBOL_GPL(mds_user_clear);
 
 void __init check_bugs(void)
 {
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -6371,6 +6371,8 @@ static void __vmx_vcpu_run(struct kvm_vc
 
 	if (static_branch_unlikely(&vmx_l1d_should_flush))
 		vmx_l1d_flush(vcpu);
+	else if (static_branch_unlikely(&mds_user_clear))
+		mds_clear_cpu_buffers();
 
 	asm(
 		/* Store host registers */

[patch V6 09/14] MDS basics 9

[Thomas Gleixner]

Subject: [patch V6 09/14] x86/speculation/mds: Conditionally clear CPU buffers on idle entry
From: Thomas Gleixner <tglx@linutronix.de>

Add a static key which controls the invocation of the CPU buffer clear
mechanism on idle entry. This is independent of other MDS mitigations
because the idle entry invocation to mitigate the potential leakage due to
store buffer repartitioning is only necessary on SMT systems.

Add the actual invocations to the different halt/mwait variants which
covers all usage sites. mwaitx is not patched as it's not available on
Intel CPUs.

The buffer clear is only invoked before entering the C-State to prevent
that stale data from the idling CPU is spilled to the Hyper-Thread sibling
after the Store buffer got repartitioned and all entries are available to
the non idle sibling.

When coming out of idle the store buffer is partitioned again so each
sibling has half of it available. Now CPU which returned from idle could be
speculatively exposed to contents of the sibling, but the buffers are
flushed either on exit to user space or on VMENTER.

When later on conditional buffer clearing is implemented on top of this,
then there is no action required either because before returning to user
space the context switch will set the condition flag which causes a flush
on the return to user path.

Note, that the buffer clearing on idle is only sensible on CPUs which are
solely affected by MSBDS and not any other variant of MDS because the other
MDS variants cannot be mitigated when SMT is enabled, so the buffer
clearing on idle would be a window dressing exercise.

This intentionally does not handle the case in the acpi/processor_idle
driver which uses the legacy IO port interface for C-State transitions for
two reasons:

 - The acpi/processor_idle driver was replaced by the intel_idle driver
   almost a decade ago. Anything Nehalem upwards supports it and defaults
   to that new driver.

 - The legacy IO port interface is likely to be used on older and therefore
   unaffected CPUs or on systems which do not receive microcode updates
   anymore, so there is no point in adding that.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
V4: Export mds_idle_clear
V3: Adjust document wording
---
 Documentation/x86/mds.rst            |   42 +++++++++++++++++++++++++++++++++++
 arch/x86/include/asm/irqflags.h      |    4 +++
 arch/x86/include/asm/mwait.h         |    7 +++++
 arch/x86/include/asm/nospec-branch.h |   12 ++++++++++
 arch/x86/kernel/cpu/bugs.c           |    3 ++
 5 files changed, 68 insertions(+)

--- a/Documentation/x86/mds.rst
+++ b/Documentation/x86/mds.rst
@@ -149,3 +149,45 @@ Mitigation points
      This takes the paranoid exit path only when the INT1 breakpoint is in
      kernel space. #DB on a user space address takes the regular exit path,
      so no extra mitigation required.
+
+
+2. C-State transition
+^^^^^^^^^^^^^^^^^^^^^
+
+   When a CPU goes idle and enters a C-State the CPU buffers need to be
+   cleared on affected CPUs when SMT is active. This addresses the
+   repartitioning of the store buffer when one of the Hyper-Threads enters
+   a C-State.
+
+   When SMT is inactive, i.e. either the CPU does not support it or all
+   sibling threads are offline CPU buffer clearing is not required.
+
+   The idle clearing is enabled on CPUs which are only affected by MSBDS
+   and not by any other MDS variant. The other MDS variants cannot be
+   protected against cross Hyper-Thread attacks because the Fill Buffer and
+   the Load Ports are shared. So on CPUs affected by other variants, the
+   idle clearing would be a window dressing exercise and is therefore not
+   activated.
+
+   The invocation is controlled by the static key mds_idle_clear which is
+   switched depending on the chosen mitigation mode and the SMT state of
+   the system.
+
+   The buffer clear is only invoked before entering the C-State to prevent
+   that stale data from the idling CPU from spilling to the Hyper-Thread
+   sibling after the store buffer got repartitioned and all entries are
+   available to the non idle sibling.
+
+   When coming out of idle the store buffer is partitioned again so each
+   sibling has half of it available. The back from idle CPU could be then
+   speculatively exposed to contents of the sibling. The buffers are
+   flushed either on exit to user space or on VMENTER so malicious code
+   in user space or the guest cannot speculatively access them.
+
+   The mitigation is hooked into all variants of halt()/mwait(), but does
+   not cover the legacy ACPI IO-Port mechanism because the ACPI idle driver
+   has been superseded by the intel_idle driver around 2010 and is
+   preferred on all affected CPUs which are expected to gain the MD_CLEAR
+   functionality in microcode. Aside of that the IO-Port mechanism is a
+   legacy interface which is only used on older systems which are either
+   not affected or do not receive microcode updates anymore.
--- a/arch/x86/include/asm/irqflags.h
+++ b/arch/x86/include/asm/irqflags.h
@@ -6,6 +6,8 @@
 
 #ifndef __ASSEMBLY__
 
+#include <asm/nospec-branch.h>
+
 /* Provide __cpuidle; we can't safely include <linux/cpu.h> */
 #define __cpuidle __attribute__((__section__(".cpuidle.text")))
 
@@ -54,11 +56,13 @@ static inline void native_irq_enable(voi
 
 static inline __cpuidle void native_safe_halt(void)
 {
+	mds_idle_clear_cpu_buffers();
 	asm volatile("sti; hlt": : :"memory");
 }
 
 static inline __cpuidle void native_halt(void)
 {
+	mds_idle_clear_cpu_buffers();
 	asm volatile("hlt": : :"memory");
 }
 
--- a/arch/x86/include/asm/mwait.h
+++ b/arch/x86/include/asm/mwait.h
@@ -6,6 +6,7 @@
 #include <linux/sched/idle.h>
 
 #include <asm/cpufeature.h>
+#include <asm/nospec-branch.h>
 
 #define MWAIT_SUBSTATE_MASK		0xf
 #define MWAIT_CSTATE_MASK		0xf
@@ -40,6 +41,8 @@ static inline void __monitorx(const void
 
 static inline void __mwait(unsigned long eax, unsigned long ecx)
 {
+	mds_idle_clear_cpu_buffers();
+
 	/* "mwait %eax, %ecx;" */
 	asm volatile(".byte 0x0f, 0x01, 0xc9;"
 		     :: "a" (eax), "c" (ecx));
@@ -74,6 +77,8 @@ static inline void __mwait(unsigned long
 static inline void __mwaitx(unsigned long eax, unsigned long ebx,
 			    unsigned long ecx)
 {
+	/* No MDS buffer clear as this is AMD/HYGON only */
+
 	/* "mwaitx %eax, %ebx, %ecx;" */
 	asm volatile(".byte 0x0f, 0x01, 0xfb;"
 		     :: "a" (eax), "b" (ebx), "c" (ecx));
@@ -81,6 +86,8 @@ static inline void __mwaitx(unsigned lon
 
 static inline void __sti_mwait(unsigned long eax, unsigned long ecx)
 {
+	mds_idle_clear_cpu_buffers();
+
 	trace_hardirqs_on();
 	/* "mwait %eax, %ecx;" */
 	asm volatile("sti; .byte 0x0f, 0x01, 0xc9;"
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -319,6 +319,7 @@ DECLARE_STATIC_KEY_FALSE(switch_mm_cond_
 DECLARE_STATIC_KEY_FALSE(switch_mm_always_ibpb);
 
 DECLARE_STATIC_KEY_FALSE(mds_user_clear);
+DECLARE_STATIC_KEY_FALSE(mds_idle_clear);
 
 #include <asm/segment.h>
 
@@ -356,6 +357,17 @@ static inline void mds_user_clear_cpu_bu
 		mds_clear_cpu_buffers();
 }
 
+/**
+ * mds_idle_clear_cpu_buffers - Mitigation for MDS vulnerability
+ *
+ * Clear CPU buffers if the corresponding static key is enabled
+ */
+static inline void mds_idle_clear_cpu_buffers(void)
+{
+	if (static_branch_likely(&mds_idle_clear))
+		mds_clear_cpu_buffers();
+}
+
 #endif /* __ASSEMBLY__ */
 
 /*
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -66,6 +66,9 @@ DEFINE_STATIC_KEY_FALSE(switch_mm_always
 /* Control MDS CPU buffer clear before returning to user space */
 DEFINE_STATIC_KEY_FALSE(mds_user_clear);
 EXPORT_SYMBOL_GPL(mds_user_clear);
+/* Control MDS CPU buffer clear before idling (halt, mwait) */
+DEFINE_STATIC_KEY_FALSE(mds_idle_clear);
+EXPORT_SYMBOL_GPL(mds_idle_clear);
 
 void __init check_bugs(void)
 {

[patch V6 10/14] MDS basics 10

[Thomas Gleixner]

Subject: [patch V6 10/14] x86/speculation/mds: Add mitigation control for MDS
From: Thomas Gleixner <tglx@linutronix.de>

Now that the mitigations are in place, add a command line parameter to
control the mitigation, a mitigation selector function and a SMT update
mechanism.

This is the minimal straight forward initial implementation which just
provides an always on/off mode. The command line parameter is:

  mds=[full|off]

This is consistent with the existing mitigations for other speculative
hardware vulnerabilities.

The idle invocation is dynamically updated according to the SMT state of
the system similar to the dynamic update of the STIBP mitigation. The idle
mitigation is limited to CPUs which are only affected by MSBDS and not any
other variant, because the other variants cannot be mitigated on SMT
enabled systems.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
V5 --> V6: Make idle clearing depend on BUG_MSBDS_ONLY
V4 --> V5: Remove 'auto'
---
 Documentation/admin-guide/kernel-parameters.txt |   22 +++++++
 arch/x86/include/asm/processor.h                |    5 +
 arch/x86/kernel/cpu/bugs.c                      |   68 ++++++++++++++++++++++++
 3 files changed, 95 insertions(+)

--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2356,6 +2356,28 @@
 			Format: <first>,<last>
 			Specifies range of consoles to be captured by the MDA.
 
+	mds=		[X86,INTEL]
+			Control mitigation for the Micro-architectural Data
+			Sampling (MDS) vulnerability.
+
+			Certain CPUs are vulnerable to an exploit against CPU
+			internal buffers which can forward information to a
+			disclosure gadget under certain conditions.
+
+			In vulnerable processors, the speculatively
+			forwarded data can be used in a cache side channel
+			attack, to access data to which the attacker does
+			not have direct access.
+
+			This parameter controls the MDS mitigation. The
+			options are:
+
+			full    - Enable MDS mitigation on vulnerable CPUs
+			off     - Unconditionally disable MDS mitigation
+
+			Not specifying this option is equivalent to
+			mds=full.
+
 	mem=nn[KMG]	[KNL,BOOT] Force usage of a specific amount of memory
 			Amount of memory to be used when the kernel is not able
 			to see the whole system memory or for test.
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -992,4 +992,9 @@ enum l1tf_mitigations {
 
 extern enum l1tf_mitigations l1tf_mitigation;
 
+enum mds_mitigations {
+	MDS_MITIGATION_OFF,
+	MDS_MITIGATION_FULL,
+};
+
 #endif /* _ASM_X86_PROCESSOR_H */
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -37,6 +37,7 @@
 static void __init spectre_v2_select_mitigation(void);
 static void __init ssb_select_mitigation(void);
 static void __init l1tf_select_mitigation(void);
+static void __init mds_select_mitigation(void);
 
 /* The base value of the SPEC_CTRL MSR that always has to be preserved. */
 u64 x86_spec_ctrl_base;
@@ -108,6 +109,8 @@ void __init check_bugs(void)
 
 	l1tf_select_mitigation();
 
+	mds_select_mitigation();
+
 #ifdef CONFIG_X86_32
 	/*
 	 * Check whether we are able to run this kernel safely on SMP.
@@ -214,6 +217,50 @@ static void x86_amd_ssb_disable(void)
 }
 
 #undef pr_fmt
+#define pr_fmt(fmt)	"MDS: " fmt
+
+/* Default mitigation for L1TF-affected CPUs */
+static enum mds_mitigations mds_mitigation __ro_after_init = MDS_MITIGATION_FULL;
+
+static const char * const mds_strings[] = {
+	[MDS_MITIGATION_OFF]	= "Vulnerable",
+	[MDS_MITIGATION_FULL]	= "Mitigation: Clear CPU buffers"
+};
+
+static void mds_select_mitigation(void)
+{
+	if (!boot_cpu_has_bug(X86_BUG_MDS)) {
+		mds_mitigation = MDS_MITIGATION_OFF;
+		return;
+	}
+
+	if (mds_mitigation == MDS_MITIGATION_FULL) {
+		if (boot_cpu_has(X86_FEATURE_MD_CLEAR))
+			static_branch_enable(&mds_user_clear);
+		else
+			mds_mitigation = MDS_MITIGATION_OFF;
+	}
+	pr_info("%s\n", mds_strings[mds_mitigation]);
+}
+
+static int __init mds_cmdline(char *str)
+{
+	if (!boot_cpu_has_bug(X86_BUG_MDS))
+		return 0;
+
+	if (!str)
+		return -EINVAL;
+
+	if (!strcmp(str, "off"))
+		mds_mitigation = MDS_MITIGATION_OFF;
+	else if (!strcmp(str, "full"))
+		mds_mitigation = MDS_MITIGATION_FULL;
+
+	return 0;
+}
+early_param("mds", mds_cmdline);
+
+#undef pr_fmt
 #define pr_fmt(fmt)     "Spectre V2 : " fmt
 
 static enum spectre_v2_mitigation spectre_v2_enabled __ro_after_init =
@@ -617,6 +664,24 @@ static void update_indir_branch_cond(voi
 		static_branch_disable(&switch_to_cond_stibp);
 }
 
+/* Update the static key controlling the MDS CPU buffer clear in idle */
+static void update_mds_branch_idle(void)
+{
+	/*
+	 * Enable the idle clearing on CPUs which are affected only by
+	 * MDBDS and not any other MDS variant. The other variants cannot
+	 * be mitigated when SMT is enabled, so clearing the buffers on
+	 * idle would be a window dressing exercise.
+	 */
+	if (!boot_cpu_has(X86_BUG_MSBDS_ONLY))
+		return;
+
+	if (sched_smt_active())
+		static_branch_enable(&mds_idle_clear);
+	else
+		static_branch_disable(&mds_idle_clear);
+}
+
 void arch_smt_update(void)
 {
 	/* Enhanced IBRS implies STIBP. No update required. */
@@ -638,6 +703,9 @@ void arch_smt_update(void)
 		break;
 	}
 
+	if (mds_mitigation == MDS_MITIGATION_FULL)
+		update_mds_branch_idle();
+
 	mutex_unlock(&spec_ctrl_mutex);
 }
 

[patch V6 11/14] MDS basics 11

[Thomas Gleixner]

Subject: [patch V6 11/14] x86/speculation/mds: Add sysfs reporting for MDS
From: Thomas Gleixner <tglx@linutronix.de>

Add the sysfs reporting file for MDS. It exposes the vulnerability and
mitigation state similar to the existing files for the other speculative
hardware vulnerabilities.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Borislav Petkov <bp@suse.de>
---
V3: Copy & Paste done right :(
---
 Documentation/ABI/testing/sysfs-devices-system-cpu |    1 
 arch/x86/kernel/cpu/bugs.c                         |   25 +++++++++++++++++++++
 drivers/base/cpu.c                                 |    8 ++++++
 include/linux/cpu.h                                |    2 +
 4 files changed, 36 insertions(+)

--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -484,6 +484,7 @@ What:		/sys/devices/system/cpu/vulnerabi
 		/sys/devices/system/cpu/vulnerabilities/spectre_v2
 		/sys/devices/system/cpu/vulnerabilities/spec_store_bypass
 		/sys/devices/system/cpu/vulnerabilities/l1tf
+		/sys/devices/system/cpu/vulnerabilities/mds
 Date:		January 2018
 Contact:	Linux kernel mailing list <linux-kernel@vger.kernel.org>
 Description:	Information about CPU vulnerabilities
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -1170,6 +1170,22 @@ static ssize_t l1tf_show_state(char *buf
 }
 #endif
 
+static ssize_t mds_show_state(char *buf)
+{
+	if (!hypervisor_is_type(X86_HYPER_NATIVE)) {
+		return sprintf(buf, "%s; SMT Host state unknown\n",
+			       mds_strings[mds_mitigation]);
+	}
+
+	if (boot_cpu_has(X86_BUG_MSBDS_ONLY)) {
+		return sprintf(buf, "%s; SMT %s\n", mds_strings[mds_mitigation],
+			       sched_smt_active() ? "mitigated" : "disabled");
+	}
+
+	return sprintf(buf, "%s; SMT %s\n", mds_strings[mds_mitigation],
+		       sched_smt_active() ? "vulnerable" : "disabled");
+}
+
 static char *stibp_state(void)
 {
 	if (spectre_v2_enabled == SPECTRE_V2_IBRS_ENHANCED)
@@ -1236,6 +1252,10 @@ static ssize_t cpu_show_common(struct de
 		if (boot_cpu_has(X86_FEATURE_L1TF_PTEINV))
 			return l1tf_show_state(buf);
 		break;
+
+	case X86_BUG_MDS:
+		return mds_show_state(buf);
+
 	default:
 		break;
 	}
@@ -1267,4 +1287,9 @@ ssize_t cpu_show_l1tf(struct device *dev
 {
 	return cpu_show_common(dev, attr, buf, X86_BUG_L1TF);
 }
+
+ssize_t cpu_show_mds(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	return cpu_show_common(dev, attr, buf, X86_BUG_MDS);
+}
 #endif
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -546,11 +546,18 @@ ssize_t __weak cpu_show_l1tf(struct devi
 	return sprintf(buf, "Not affected\n");
 }
 
+ssize_t __weak cpu_show_mds(struct device *dev,
+			    struct device_attribute *attr, char *buf)
+{
+	return sprintf(buf, "Not affected\n");
+}
+
 static DEVICE_ATTR(meltdown, 0444, cpu_show_meltdown, NULL);
 static DEVICE_ATTR(spectre_v1, 0444, cpu_show_spectre_v1, NULL);
 static DEVICE_ATTR(spectre_v2, 0444, cpu_show_spectre_v2, NULL);
 static DEVICE_ATTR(spec_store_bypass, 0444, cpu_show_spec_store_bypass, NULL);
 static DEVICE_ATTR(l1tf, 0444, cpu_show_l1tf, NULL);
+static DEVICE_ATTR(mds, 0444, cpu_show_mds, NULL);
 
 static struct attribute *cpu_root_vulnerabilities_attrs[] = {
 	&dev_attr_meltdown.attr,
@@ -558,6 +565,7 @@ static struct attribute *cpu_root_vulner
 	&dev_attr_spectre_v2.attr,
 	&dev_attr_spec_store_bypass.attr,
 	&dev_attr_l1tf.attr,
+	&dev_attr_mds.attr,
 	NULL
 };
 
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -57,6 +57,8 @@ extern ssize_t cpu_show_spec_store_bypas
 					  struct device_attribute *attr, char *buf);
 extern ssize_t cpu_show_l1tf(struct device *dev,
 			     struct device_attribute *attr, char *buf);
+extern ssize_t cpu_show_mds(struct device *dev,
+			    struct device_attribute *attr, char *buf);
 
 extern __printf(4, 5)
 struct device *cpu_device_create(struct device *parent, void *drvdata,

[patch V6 12/14] MDS basics 12

[Thomas Gleixner]

Subject: [patch V6 12/14] x86/speculation/mds: Add mitigation mode VMWERV
From: Thomas Gleixner <tglx@linutronix.de>

In virtualized environments it can happen that the host has the microcode
update which utilizes the VERW instruction to clear CPU buffers, but the
hypervisor is not yet updated to expose the X86_FEATURE_MD_CLEAR CPUID bit
to guests.

Introduce an internal mitigation mode VWWERV which enables the invocation
of the CPU buffer clearing even if X86_FEATURE_MD_CLEAR is not set. If the
system has no updated microcode this results in a pointless execution of
the VERW instruction wasting a few CPU cycles. If the microcode is updated,
but not exposed to a guest then the CPU buffers will be cleared.

That said: Virtual Machines Will Eventually Receive Vaccine

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
V2 -> V3: Rename mode.
---
 Documentation/x86/mds.rst        |   27 +++++++++++++++++++++++++++
 arch/x86/include/asm/processor.h |    1 +
 arch/x86/kernel/cpu/bugs.c       |   18 ++++++++++++------
 3 files changed, 40 insertions(+), 6 deletions(-)

--- a/Documentation/x86/mds.rst
+++ b/Documentation/x86/mds.rst
@@ -93,11 +93,38 @@ enters a C-state.
 The mitigation is invoked on kernel/userspace, hypervisor/guest and C-state
 (idle) transitions.
 
+As a special quirk to address virtualization scenarios where the host has
+the microcode updated, but the hypervisor does not (yet) expose the
+MD_CLEAR CPUID bit to guests, the kernel issues the VERW instruction in the
+hope that it might actually clear the buffers. The state is reflected
+accordingly.
+
 According to current knowledge additional mitigations inside the kernel
 itself are not required because the necessary gadgets to expose the leaked
 data cannot be controlled in a way which allows exploitation from malicious
 user space or VM guests.
 
+Kernel internal mitigation modes
+--------------------------------
+
+ ======= ============================================================
+ off      Mitigation is disabled. Either the CPU is not affected or
+          mds=off is supplied on the kernel command line
+
+ full     Mitigation is eanbled. CPU is affected and MD_CLEAR is
+          advertised in CPUID.
+
+ vmwerv	  Mitigation is enabled. CPU is affected and MD_CLEAR is not
+	  advertised in CPUID. That is mainly for virtualization
+	  scenarios where the host has the updated microcode but the
+	  hypervisor does not expose MD_CLEAR in CPUID. It's a best
+	  effort approach without guarantee.
+ ======= ============================================================
+
+If the CPU is affected and mds=off is not supplied on the kernel command
+line then the kernel selects the appropriate mitigation mode depending on
+the availability of the MD_CLEAR CPUID bit.
+
 Mitigation points
 -----------------
 
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -995,6 +995,7 @@ extern enum l1tf_mitigations l1tf_mitiga
 enum mds_mitigations {
 	MDS_MITIGATION_OFF,
 	MDS_MITIGATION_FULL,
+	MDS_MITIGATION_VMWERV,
 };
 
 #endif /* _ASM_X86_PROCESSOR_H */
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -224,7 +224,8 @@ static enum mds_mitigations mds_mitigati
 
 static const char * const mds_strings[] = {
 	[MDS_MITIGATION_OFF]	= "Vulnerable",
-	[MDS_MITIGATION_FULL]	= "Mitigation: Clear CPU buffers"
+	[MDS_MITIGATION_FULL]	= "Mitigation: Clear CPU buffers",
+	[MDS_MITIGATION_VMWERV]	= "Vulnerable: Clear CPU buffers attempted, no microcode",
 };
 
 static void mds_select_mitigation(void)
@@ -235,10 +236,9 @@ static void mds_select_mitigation(void)
 	}
 
 	if (mds_mitigation == MDS_MITIGATION_FULL) {
-		if (boot_cpu_has(X86_FEATURE_MD_CLEAR))
-			static_branch_enable(&mds_user_clear);
-		else
-			mds_mitigation = MDS_MITIGATION_OFF;
+		if (!boot_cpu_has(X86_FEATURE_MD_CLEAR))
+			mds_mitigation = MDS_MITIGATION_VMWERV;
+		static_branch_enable(&mds_user_clear);
 	}
 	pr_info("%s\n", mds_strings[mds_mitigation]);
 }
@@ -703,8 +703,14 @@ void arch_smt_update(void)
 		break;
 	}
 
-	if (mds_mitigation == MDS_MITIGATION_FULL)
+	switch(mds_mitigation) {
+	case MDS_MITIGATION_FULL:
+	case MDS_MITIGATION_VMWERV:
 		update_mds_branch_idle();
+		break;
+	case MDS_MITIGATION_OFF:
+		break;
+	}
 
 	mutex_unlock(&spec_ctrl_mutex);
 }

[patch V6 13/14] MDS basics 13

[Thomas Gleixner]

Subject: [patch V6 13/14] Documentation: Move L1TF to separate directory
From: Thomas Gleixner <tglx@linutronix.de>

Move L!TF to a separate directory so the MDS stuff can be added at the
side. Otherwise the all hardware vulnerabilites have their own top level
entry. Should have done that right away.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 Documentation/admin-guide/hw-vuln/index.rst |   12 
 Documentation/admin-guide/hw-vuln/l1tf.rst  |  614 ++++++++++++++++++++++++++++
 Documentation/admin-guide/index.rst         |    6 
 Documentation/admin-guide/l1tf.rst          |  614 ----------------------------
 4 files changed, 628 insertions(+), 618 deletions(-)

--- /dev/null
+++ b/Documentation/admin-guide/hw-vuln/index.rst
@@ -0,0 +1,12 @@
+========================
+Hardware vulnerabilities
+========================
+
+This section describes CPU vulnerabilities and provides an overview of the
+possible mitigations along with guidance for selecting mitigations if they
+are configurable at compile, boot or run time.
+
+.. toctree::
+   :maxdepth: 1
+
+   l1tf
--- /dev/null
+++ b/Documentation/admin-guide/hw-vuln/l1tf.rst
@@ -0,0 +1,614 @@
+L1TF - L1 Terminal Fault
+========================
+
+L1 Terminal Fault is a hardware vulnerability which allows unprivileged
+speculative access to data which is available in the Level 1 Data Cache
+when the page table entry controlling the virtual address, which is used
+for the access, has the Present bit cleared or other reserved bits set.
+
+Affected processors
+-------------------
+
+This vulnerability affects a wide range of Intel processors. The
+vulnerability is not present on:
+
+   - Processors from AMD, Centaur and other non Intel vendors
+
+   - Older processor models, where the CPU family is < 6
+
+   - A range of Intel ATOM processors (Cedarview, Cloverview, Lincroft,
+     Penwell, Pineview, Silvermont, Airmont, Merrifield)
+
+   - The Intel XEON PHI family
+
+   - Intel processors which have the ARCH_CAP_RDCL_NO bit set in the
+     IA32_ARCH_CAPABILITIES MSR. If the bit is set the CPU is not affected
+     by the Meltdown vulnerability either. These CPUs should become
+     available by end of 2018.
+
+Whether a processor is affected or not can be read out from the L1TF
+vulnerability file in sysfs. See :ref:`l1tf_sys_info`.
+
+Related CVEs
+------------
+
+The following CVE entries are related to the L1TF vulnerability:
+
+   =============  =================  ==============================
+   CVE-2018-3615  L1 Terminal Fault  SGX related aspects
+   CVE-2018-3620  L1 Terminal Fault  OS, SMM related aspects
+   CVE-2018-3646  L1 Terminal Fault  Virtualization related aspects
+   =============  =================  ==============================
+
+Problem
+-------
+
+If an instruction accesses a virtual address for which the relevant page
+table entry (PTE) has the Present bit cleared or other reserved bits set,
+then speculative execution ignores the invalid PTE and loads the referenced
+data if it is present in the Level 1 Data Cache, as if the page referenced
+by the address bits in the PTE was still present and accessible.
+
+While this is a purely speculative mechanism and the instruction will raise
+a page fault when it is retired eventually, the pure act of loading the
+data and making it available to other speculative instructions opens up the
+opportunity for side channel attacks to unprivileged malicious code,
+similar to the Meltdown attack.
+
+While Meltdown breaks the user space to kernel space protection, L1TF
+allows to attack any physical memory address in the system and the attack
+works across all protection domains. It allows an attack of SGX and also
+works from inside virtual machines because the speculation bypasses the
+extended page table (EPT) protection mechanism.
+
+
+Attack scenarios
+----------------
+
+1. Malicious user space
+^^^^^^^^^^^^^^^^^^^^^^^
+
+   Operating Systems store arbitrary information in the address bits of a
+   PTE which is marked non present. This allows a malicious user space
+   application to attack the physical memory to which these PTEs resolve.
+   In some cases user-space can maliciously influence the information
+   encoded in the address bits of the PTE, thus making attacks more
+   deterministic and more practical.
+
+   The Linux kernel contains a mitigation for this attack vector, PTE
+   inversion, which is permanently enabled and has no performance
+   impact. The kernel ensures that the address bits of PTEs, which are not
+   marked present, never point to cacheable physical memory space.
+
+   A system with an up to date kernel is protected against attacks from
+   malicious user space applications.
+
+2. Malicious guest in a virtual machine
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+   The fact that L1TF breaks all domain protections allows malicious guest
+   OSes, which can control the PTEs directly, and malicious guest user
+   space applications, which run on an unprotected guest kernel lacking the
+   PTE inversion mitigation for L1TF, to attack physical host memory.
+
+   A special aspect of L1TF in the context of virtualization is symmetric
+   multi threading (SMT). The Intel implementation of SMT is called
+   HyperThreading. The fact that Hyperthreads on the affected processors
+   share the L1 Data Cache (L1D) is important for this. As the flaw allows
+   only to attack data which is present in L1D, a malicious guest running
+   on one Hyperthread can attack the data which is brought into the L1D by
+   the context which runs on the sibling Hyperthread of the same physical
+   core. This context can be host OS, host user space or a different guest.
+
+   If the processor does not support Extended Page Tables, the attack is
+   only possible, when the hypervisor does not sanitize the content of the
+   effective (shadow) page tables.
+
+   While solutions exist to mitigate these attack vectors fully, these
+   mitigations are not enabled by default in the Linux kernel because they
+   can affect performance significantly. The kernel provides several
+   mechanisms which can be utilized to address the problem depending on the
+   deployment scenario. The mitigations, their protection scope and impact
+   are described in the next sections.
+
+   The default mitigations and the rationale for choosing them are explained
+   at the end of this document. See :ref:`default_mitigations`.
+
+.. _l1tf_sys_info:
+
+L1TF system information
+-----------------------
+
+The Linux kernel provides a sysfs interface to enumerate the current L1TF
+status of the system: whether the system is vulnerable, and which
+mitigations are active. The relevant sysfs file is:
+
+/sys/devices/system/cpu/vulnerabilities/l1tf
+
+The possible values in this file are:
+
+  ===========================   ===============================
+  'Not affected'		The processor is not vulnerable
+  'Mitigation: PTE Inversion'	The host protection is active
+  ===========================   ===============================
+
+If KVM/VMX is enabled and the processor is vulnerable then the following
+information is appended to the 'Mitigation: PTE Inversion' part:
+
+  - SMT status:
+
+    =====================  ================
+    'VMX: SMT vulnerable'  SMT is enabled
+    'VMX: SMT disabled'    SMT is disabled
+    =====================  ================
+
+  - L1D Flush mode:
+
+    ================================  ====================================
+    'L1D vulnerable'		      L1D flushing is disabled
+
+    'L1D conditional cache flushes'   L1D flush is conditionally enabled
+
+    'L1D cache flushes'		      L1D flush is unconditionally enabled
+    ================================  ====================================
+
+The resulting grade of protection is discussed in the following sections.
+
+
+Host mitigation mechanism
+-------------------------
+
+The kernel is unconditionally protected against L1TF attacks from malicious
+user space running on the host.
+
+
+Guest mitigation mechanisms
+---------------------------
+
+.. _l1d_flush:
+
+1. L1D flush on VMENTER
+^^^^^^^^^^^^^^^^^^^^^^^
+
+   To make sure that a guest cannot attack data which is present in the L1D
+   the hypervisor flushes the L1D before entering the guest.
+
+   Flushing the L1D evicts not only the data which should not be accessed
+   by a potentially malicious guest, it also flushes the guest
+   data. Flushing the L1D has a performance impact as the processor has to
+   bring the flushed guest data back into the L1D. Depending on the
+   frequency of VMEXIT/VMENTER and the type of computations in the guest
+   performance degradation in the range of 1% to 50% has been observed. For
+   scenarios where guest VMEXIT/VMENTER are rare the performance impact is
+   minimal. Virtio and mechanisms like posted interrupts are designed to
+   confine the VMEXITs to a bare minimum, but specific configurations and
+   application scenarios might still suffer from a high VMEXIT rate.
+
+   The kernel provides two L1D flush modes:
+    - conditional ('cond')
+    - unconditional ('always')
+
+   The conditional mode avoids L1D flushing after VMEXITs which execute
+   only audited code paths before the corresponding VMENTER. These code
+   paths have been verified that they cannot expose secrets or other
+   interesting data to an attacker, but they can leak information about the
+   address space layout of the hypervisor.
+
+   Unconditional mode flushes L1D on all VMENTER invocations and provides
+   maximum protection. It has a higher overhead than the conditional
+   mode. The overhead cannot be quantified correctly as it depends on the
+   workload scenario and the resulting number of VMEXITs.
+
+   The general recommendation is to enable L1D flush on VMENTER. The kernel
+   defaults to conditional mode on affected processors.
+
+   **Note**, that L1D flush does not prevent the SMT problem because the
+   sibling thread will also bring back its data into the L1D which makes it
+   attackable again.
+
+   L1D flush can be controlled by the administrator via the kernel command
+   line and sysfs control files. See :ref:`mitigation_control_command_line`
+   and :ref:`mitigation_control_kvm`.
+
+.. _guest_confinement:
+
+2. Guest VCPU confinement to dedicated physical cores
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+   To address the SMT problem, it is possible to make a guest or a group of
+   guests affine to one or more physical cores. The proper mechanism for
+   that is to utilize exclusive cpusets to ensure that no other guest or
+   host tasks can run on these cores.
+
+   If only a single guest or related guests run on sibling SMT threads on
+   the same physical core then they can only attack their own memory and
+   restricted parts of the host memory.
+
+   Host memory is attackable, when one of the sibling SMT threads runs in
+   host OS (hypervisor) context and the other in guest context. The amount
+   of valuable information from the host OS context depends on the context
+   which the host OS executes, i.e. interrupts, soft interrupts and kernel
+   threads. The amount of valuable data from these contexts cannot be
+   declared as non-interesting for an attacker without deep inspection of
+   the code.
+
+   **Note**, that assigning guests to a fixed set of physical cores affects
+   the ability of the scheduler to do load balancing and might have
+   negative effects on CPU utilization depending on the hosting
+   scenario. Disabling SMT might be a viable alternative for particular
+   scenarios.
+
+   For further information about confining guests to a single or to a group
+   of cores consult the cpusets documentation:
+
+   https://www.kernel.org/doc/Documentation/cgroup-v1/cpusets.txt
+
+.. _interrupt_isolation:
+
+3. Interrupt affinity
+^^^^^^^^^^^^^^^^^^^^^
+
+   Interrupts can be made affine to logical CPUs. This is not universally
+   true because there are types of interrupts which are truly per CPU
+   interrupts, e.g. the local timer interrupt. Aside of that multi queue
+   devices affine their interrupts to single CPUs or groups of CPUs per
+   queue without allowing the administrator to control the affinities.
+
+   Moving the interrupts, which can be affinity controlled, away from CPUs
+   which run untrusted guests, reduces the attack vector space.
+
+   Whether the interrupts with are affine to CPUs, which run untrusted
+   guests, provide interesting data for an attacker depends on the system
+   configuration and the scenarios which run on the system. While for some
+   of the interrupts it can be assumed that they won't expose interesting
+   information beyond exposing hints about the host OS memory layout, there
+   is no way to make general assumptions.
+
+   Interrupt affinity can be controlled by the administrator via the
+   /proc/irq/$NR/smp_affinity[_list] files. Limited documentation is
+   available at:
+
+   https://www.kernel.org/doc/Documentation/IRQ-affinity.txt
+
+.. _smt_control:
+
+4. SMT control
+^^^^^^^^^^^^^^
+
+   To prevent the SMT issues of L1TF it might be necessary to disable SMT
+   completely. Disabling SMT can have a significant performance impact, but
+   the impact depends on the hosting scenario and the type of workloads.
+   The impact of disabling SMT needs also to be weighted against the impact
+   of other mitigation solutions like confining guests to dedicated cores.
+
+   The kernel provides a sysfs interface to retrieve the status of SMT and
+   to control it. It also provides a kernel command line interface to
+   control SMT.
+
+   The kernel command line interface consists of the following options:
+
+     =========== ==========================================================
+     nosmt	 Affects the bring up of the secondary CPUs during boot. The
+		 kernel tries to bring all present CPUs online during the
+		 boot process. "nosmt" makes sure that from each physical
+		 core only one - the so called primary (hyper) thread is
+		 activated. Due to a design flaw of Intel processors related
+		 to Machine Check Exceptions the non primary siblings have
+		 to be brought up at least partially and are then shut down
+		 again.  "nosmt" can be undone via the sysfs interface.
+
+     nosmt=force Has the same effect as "nosmt" but it does not allow to
+		 undo the SMT disable via the sysfs interface.
+     =========== ==========================================================
+
+   The sysfs interface provides two files:
+
+   - /sys/devices/system/cpu/smt/control
+   - /sys/devices/system/cpu/smt/active
+
+   /sys/devices/system/cpu/smt/control:
+
+     This file allows to read out the SMT control state and provides the
+     ability to disable or (re)enable SMT. The possible states are:
+
+	==============  ===================================================
+	on		SMT is supported by the CPU and enabled. All
+			logical CPUs can be onlined and offlined without
+			restrictions.
+
+	off		SMT is supported by the CPU and disabled. Only
+			the so called primary SMT threads can be onlined
+			and offlined without restrictions. An attempt to
+			online a non-primary sibling is rejected
+
+	forceoff	Same as 'off' but the state cannot be controlled.
+			Attempts to write to the control file are rejected.
+
+	notsupported	The processor does not support SMT. It's therefore
+			not affected by the SMT implications of L1TF.
+			Attempts to write to the control file are rejected.
+	==============  ===================================================
+
+     The possible states which can be written into this file to control SMT
+     state are:
+
+     - on
+     - off
+     - forceoff
+
+   /sys/devices/system/cpu/smt/active:
+
+     This file reports whether SMT is enabled and active, i.e. if on any
+     physical core two or more sibling threads are online.
+
+   SMT control is also possible at boot time via the l1tf kernel command
+   line parameter in combination with L1D flush control. See
+   :ref:`mitigation_control_command_line`.
+
+5. Disabling EPT
+^^^^^^^^^^^^^^^^
+
+  Disabling EPT for virtual machines provides full mitigation for L1TF even
+  with SMT enabled, because the effective page tables for guests are
+  managed and sanitized by the hypervisor. Though disabling EPT has a
+  significant performance impact especially when the Meltdown mitigation
+  KPTI is enabled.
+
+  EPT can be disabled in the hypervisor via the 'kvm-intel.ept' parameter.
+
+There is ongoing research and development for new mitigation mechanisms to
+address the performance impact of disabling SMT or EPT.
+
+.. _mitigation_control_command_line:
+
+Mitigation control on the kernel command line
+---------------------------------------------
+
+The kernel command line allows to control the L1TF mitigations at boot
+time with the option "l1tf=". The valid arguments for this option are:
+
+  ============  =============================================================
+  full		Provides all available mitigations for the L1TF
+		vulnerability. Disables SMT and enables all mitigations in
+		the hypervisors, i.e. unconditional L1D flushing
+
+		SMT control and L1D flush control via the sysfs interface
+		is still possible after boot.  Hypervisors will issue a
+		warning when the first VM is started in a potentially
+		insecure configuration, i.e. SMT enabled or L1D flush
+		disabled.
+
+  full,force	Same as 'full', but disables SMT and L1D flush runtime
+		control. Implies the 'nosmt=force' command line option.
+		(i.e. sysfs control of SMT is disabled.)
+
+  flush		Leaves SMT enabled and enables the default hypervisor
+		mitigation, i.e. conditional L1D flushing
+
+		SMT control and L1D flush control via the sysfs interface
+		is still possible after boot.  Hypervisors will issue a
+		warning when the first VM is started in a potentially
+		insecure configuration, i.e. SMT enabled or L1D flush
+		disabled.
+
+  flush,nosmt	Disables SMT and enables the default hypervisor mitigation,
+		i.e. conditional L1D flushing.
+
+		SMT control and L1D flush control via the sysfs interface
+		is still possible after boot.  Hypervisors will issue a
+		warning when the first VM is started in a potentially
+		insecure configuration, i.e. SMT enabled or L1D flush
+		disabled.
+
+  flush,nowarn	Same as 'flush', but hypervisors will not warn when a VM is
+		started in a potentially insecure configuration.
+
+  off		Disables hypervisor mitigations and doesn't emit any
+		warnings.
+		It also drops the swap size and available RAM limit restrictions
+		on both hypervisor and bare metal.
+
+  ============  =============================================================
+
+The default is 'flush'. For details about L1D flushing see :ref:`l1d_flush`.
+
+
+.. _mitigation_control_kvm:
+
+Mitigation control for KVM - module parameter
+-------------------------------------------------------------
+
+The KVM hypervisor mitigation mechanism, flushing the L1D cache when
+entering a guest, can be controlled with a module parameter.
+
+The option/parameter is "kvm-intel.vmentry_l1d_flush=". It takes the
+following arguments:
+
+  ============  ==============================================================
+  always	L1D cache flush on every VMENTER.
+
+  cond		Flush L1D on VMENTER only when the code between VMEXIT and
+		VMENTER can leak host memory which is considered
+		interesting for an attacker. This still can leak host memory
+		which allows e.g. to determine the hosts address space layout.
+
+  never		Disables the mitigation
+  ============  ==============================================================
+
+The parameter can be provided on the kernel command line, as a module
+parameter when loading the modules and at runtime modified via the sysfs
+file:
+
+/sys/module/kvm_intel/parameters/vmentry_l1d_flush
+
+The default is 'cond'. If 'l1tf=full,force' is given on the kernel command
+line, then 'always' is enforced and the kvm-intel.vmentry_l1d_flush
+module parameter is ignored and writes to the sysfs file are rejected.
+
+
+Mitigation selection guide
+--------------------------
+
+1. No virtualization in use
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+   The system is protected by the kernel unconditionally and no further
+   action is required.
+
+2. Virtualization with trusted guests
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+   If the guest comes from a trusted source and the guest OS kernel is
+   guaranteed to have the L1TF mitigations in place the system is fully
+   protected against L1TF and no further action is required.
+
+   To avoid the overhead of the default L1D flushing on VMENTER the
+   administrator can disable the flushing via the kernel command line and
+   sysfs control files. See :ref:`mitigation_control_command_line` and
+   :ref:`mitigation_control_kvm`.
+
+
+3. Virtualization with untrusted guests
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+3.1. SMT not supported or disabled
+""""""""""""""""""""""""""""""""""
+
+  If SMT is not supported by the processor or disabled in the BIOS or by
+  the kernel, it's only required to enforce L1D flushing on VMENTER.
+
+  Conditional L1D flushing is the default behaviour and can be tuned. See
+  :ref:`mitigation_control_command_line` and :ref:`mitigation_control_kvm`.
+
+3.2. EPT not supported or disabled
+""""""""""""""""""""""""""""""""""
+
+  If EPT is not supported by the processor or disabled in the hypervisor,
+  the system is fully protected. SMT can stay enabled and L1D flushing on
+  VMENTER is not required.
+
+  EPT can be disabled in the hypervisor via the 'kvm-intel.ept' parameter.
+
+3.3. SMT and EPT supported and active
+"""""""""""""""""""""""""""""""""""""
+
+  If SMT and EPT are supported and active then various degrees of
+  mitigations can be employed:
+
+  - L1D flushing on VMENTER:
+
+    L1D flushing on VMENTER is the minimal protection requirement, but it
+    is only potent in combination with other mitigation methods.
+
+    Conditional L1D flushing is the default behaviour and can be tuned. See
+    :ref:`mitigation_control_command_line` and :ref:`mitigation_control_kvm`.
+
+  - Guest confinement:
+
+    Confinement of guests to a single or a group of physical cores which
+    are not running any other processes, can reduce the attack surface
+    significantly, but interrupts, soft interrupts and kernel threads can
+    still expose valuable data to a potential attacker. See
+    :ref:`guest_confinement`.
+
+  - Interrupt isolation:
+
+    Isolating the guest CPUs from interrupts can reduce the attack surface
+    further, but still allows a malicious guest to explore a limited amount
+    of host physical memory. This can at least be used to gain knowledge
+    about the host address space layout. The interrupts which have a fixed
+    affinity to the CPUs which run the untrusted guests can depending on
+    the scenario still trigger soft interrupts and schedule kernel threads
+    which might expose valuable information. See
+    :ref:`interrupt_isolation`.
+
+The above three mitigation methods combined can provide protection to a
+certain degree, but the risk of the remaining attack surface has to be
+carefully analyzed. For full protection the following methods are
+available:
+
+  - Disabling SMT:
+
+    Disabling SMT and enforcing the L1D flushing provides the maximum
+    amount of protection. This mitigation is not depending on any of the
+    above mitigation methods.
+
+    SMT control and L1D flushing can be tuned by the command line
+    parameters 'nosmt', 'l1tf', 'kvm-intel.vmentry_l1d_flush' and at run
+    time with the matching sysfs control files. See :ref:`smt_control`,
+    :ref:`mitigation_control_command_line` and
+    :ref:`mitigation_control_kvm`.
+
+  - Disabling EPT:
+
+    Disabling EPT provides the maximum amount of protection as well. It is
+    not depending on any of the above mitigation methods. SMT can stay
+    enabled and L1D flushing is not required, but the performance impact is
+    significant.
+
+    EPT can be disabled in the hypervisor via the 'kvm-intel.ept'
+    parameter.
+
+3.4. Nested virtual machines
+""""""""""""""""""""""""""""
+
+When nested virtualization is in use, three operating systems are involved:
+the bare metal hypervisor, the nested hypervisor and the nested virtual
+machine.  VMENTER operations from the nested hypervisor into the nested
+guest will always be processed by the bare metal hypervisor. If KVM is the
+bare metal hypervisor it will:
+
+ - Flush the L1D cache on every switch from the nested hypervisor to the
+   nested virtual machine, so that the nested hypervisor's secrets are not
+   exposed to the nested virtual machine;
+
+ - Flush the L1D cache on every switch from the nested virtual machine to
+   the nested hypervisor; this is a complex operation, and flushing the L1D
+   cache avoids that the bare metal hypervisor's secrets are exposed to the
+   nested virtual machine;
+
+ - Instruct the nested hypervisor to not perform any L1D cache flush. This
+   is an optimization to avoid double L1D flushing.
+
+
+.. _default_mitigations:
+
+Default mitigations
+-------------------
+
+  The kernel default mitigations for vulnerable processors are:
+
+  - PTE inversion to protect against malicious user space. This is done
+    unconditionally and cannot be controlled. The swap storage is limited
+    to ~16TB.
+
+  - L1D conditional flushing on VMENTER when EPT is enabled for
+    a guest.
+
+  The kernel does not by default enforce the disabling of SMT, which leaves
+  SMT systems vulnerable when running untrusted guests with EPT enabled.
+
+  The rationale for this choice is:
+
+  - Force disabling SMT can break existing setups, especially with
+    unattended updates.
+
+  - If regular users run untrusted guests on their machine, then L1TF is
+    just an add on to other malware which might be embedded in an untrusted
+    guest, e.g. spam-bots or attacks on the local network.
+
+    There is no technical way to prevent a user from running untrusted code
+    on their machines blindly.
+
+  - It's technically extremely unlikely and from today's knowledge even
+    impossible that L1TF can be exploited via the most popular attack
+    mechanisms like JavaScript because these mechanisms have no way to
+    control PTEs. If this would be possible and not other mitigation would
+    be possible, then the default might be different.
+
+  - The administrators of cloud and hosting setups have to carefully
+    analyze the risk for their scenarios and make the appropriate
+    mitigation choices, which might even vary across their deployed
+    machines and also result in other changes of their overall setup.
+    There is no way for the kernel to provide a sensible default for this
+    kind of scenarios.
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -17,14 +17,12 @@ etc.
    kernel-parameters
    devices
 
-This section describes CPU vulnerabilities and provides an overview of the
-possible mitigations along with guidance for selecting mitigations if they
-are configurable at compile, boot or run time.
+This section describes CPU vulnerabilities and their mitigations.
 
 .. toctree::
    :maxdepth: 1
 
-   l1tf
+   hw-vuln/index
 
 Here is a set of documents aimed at users who are trying to track down
 problems and bugs in particular.
--- a/Documentation/admin-guide/l1tf.rst
+++ /dev/null
@@ -1,614 +0,0 @@
-L1TF - L1 Terminal Fault
-========================
-
-L1 Terminal Fault is a hardware vulnerability which allows unprivileged
-speculative access to data which is available in the Level 1 Data Cache
-when the page table entry controlling the virtual address, which is used
-for the access, has the Present bit cleared or other reserved bits set.
-
-Affected processors
--------------------
-
-This vulnerability affects a wide range of Intel processors. The
-vulnerability is not present on:
-
-   - Processors from AMD, Centaur and other non Intel vendors
-
-   - Older processor models, where the CPU family is < 6
-
-   - A range of Intel ATOM processors (Cedarview, Cloverview, Lincroft,
-     Penwell, Pineview, Silvermont, Airmont, Merrifield)
-
-   - The Intel XEON PHI family
-
-   - Intel processors which have the ARCH_CAP_RDCL_NO bit set in the
-     IA32_ARCH_CAPABILITIES MSR. If the bit is set the CPU is not affected
-     by the Meltdown vulnerability either. These CPUs should become
-     available by end of 2018.
-
-Whether a processor is affected or not can be read out from the L1TF
-vulnerability file in sysfs. See :ref:`l1tf_sys_info`.
-
-Related CVEs
-------------
-
-The following CVE entries are related to the L1TF vulnerability:
-
-   =============  =================  ==============================
-   CVE-2018-3615  L1 Terminal Fault  SGX related aspects
-   CVE-2018-3620  L1 Terminal Fault  OS, SMM related aspects
-   CVE-2018-3646  L1 Terminal Fault  Virtualization related aspects
-   =============  =================  ==============================
-
-Problem
--------
-
-If an instruction accesses a virtual address for which the relevant page
-table entry (PTE) has the Present bit cleared or other reserved bits set,
-then speculative execution ignores the invalid PTE and loads the referenced
-data if it is present in the Level 1 Data Cache, as if the page referenced
-by the address bits in the PTE was still present and accessible.
-
-While this is a purely speculative mechanism and the instruction will raise
-a page fault when it is retired eventually, the pure act of loading the
-data and making it available to other speculative instructions opens up the
-opportunity for side channel attacks to unprivileged malicious code,
-similar to the Meltdown attack.
-
-While Meltdown breaks the user space to kernel space protection, L1TF
-allows to attack any physical memory address in the system and the attack
-works across all protection domains. It allows an attack of SGX and also
-works from inside virtual machines because the speculation bypasses the
-extended page table (EPT) protection mechanism.
-
-
-Attack scenarios
-----------------
-
-1. Malicious user space
-^^^^^^^^^^^^^^^^^^^^^^^
-
-   Operating Systems store arbitrary information in the address bits of a
-   PTE which is marked non present. This allows a malicious user space
-   application to attack the physical memory to which these PTEs resolve.
-   In some cases user-space can maliciously influence the information
-   encoded in the address bits of the PTE, thus making attacks more
-   deterministic and more practical.
-
-   The Linux kernel contains a mitigation for this attack vector, PTE
-   inversion, which is permanently enabled and has no performance
-   impact. The kernel ensures that the address bits of PTEs, which are not
-   marked present, never point to cacheable physical memory space.
-
-   A system with an up to date kernel is protected against attacks from
-   malicious user space applications.
-
-2. Malicious guest in a virtual machine
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-   The fact that L1TF breaks all domain protections allows malicious guest
-   OSes, which can control the PTEs directly, and malicious guest user
-   space applications, which run on an unprotected guest kernel lacking the
-   PTE inversion mitigation for L1TF, to attack physical host memory.
-
-   A special aspect of L1TF in the context of virtualization is symmetric
-   multi threading (SMT). The Intel implementation of SMT is called
-   HyperThreading. The fact that Hyperthreads on the affected processors
-   share the L1 Data Cache (L1D) is important for this. As the flaw allows
-   only to attack data which is present in L1D, a malicious guest running
-   on one Hyperthread can attack the data which is brought into the L1D by
-   the context which runs on the sibling Hyperthread of the same physical
-   core. This context can be host OS, host user space or a different guest.
-
-   If the processor does not support Extended Page Tables, the attack is
-   only possible, when the hypervisor does not sanitize the content of the
-   effective (shadow) page tables.
-
-   While solutions exist to mitigate these attack vectors fully, these
-   mitigations are not enabled by default in the Linux kernel because they
-   can affect performance significantly. The kernel provides several
-   mechanisms which can be utilized to address the problem depending on the
-   deployment scenario. The mitigations, their protection scope and impact
-   are described in the next sections.
-
-   The default mitigations and the rationale for choosing them are explained
-   at the end of this document. See :ref:`default_mitigations`.
-
-.. _l1tf_sys_info:
-
-L1TF system information
------------------------
-
-The Linux kernel provides a sysfs interface to enumerate the current L1TF
-status of the system: whether the system is vulnerable, and which
-mitigations are active. The relevant sysfs file is:
-
-/sys/devices/system/cpu/vulnerabilities/l1tf
-
-The possible values in this file are:
-
-  ===========================   ===============================
-  'Not affected'		The processor is not vulnerable
-  'Mitigation: PTE Inversion'	The host protection is active
-  ===========================   ===============================
-
-If KVM/VMX is enabled and the processor is vulnerable then the following
-information is appended to the 'Mitigation: PTE Inversion' part:
-
-  - SMT status:
-
-    =====================  ================
-    'VMX: SMT vulnerable'  SMT is enabled
-    'VMX: SMT disabled'    SMT is disabled
-    =====================  ================
-
-  - L1D Flush mode:
-
-    ================================  ====================================
-    'L1D vulnerable'		      L1D flushing is disabled
-
-    'L1D conditional cache flushes'   L1D flush is conditionally enabled
-
-    'L1D cache flushes'		      L1D flush is unconditionally enabled
-    ================================  ====================================
-
-The resulting grade of protection is discussed in the following sections.
-
-
-Host mitigation mechanism
--------------------------
-
-The kernel is unconditionally protected against L1TF attacks from malicious
-user space running on the host.
-
-
-Guest mitigation mechanisms
----------------------------
-
-.. _l1d_flush:
-
-1. L1D flush on VMENTER
-^^^^^^^^^^^^^^^^^^^^^^^
-
-   To make sure that a guest cannot attack data which is present in the L1D
-   the hypervisor flushes the L1D before entering the guest.
-
-   Flushing the L1D evicts not only the data which should not be accessed
-   by a potentially malicious guest, it also flushes the guest
-   data. Flushing the L1D has a performance impact as the processor has to
-   bring the flushed guest data back into the L1D. Depending on the
-   frequency of VMEXIT/VMENTER and the type of computations in the guest
-   performance degradation in the range of 1% to 50% has been observed. For
-   scenarios where guest VMEXIT/VMENTER are rare the performance impact is
-   minimal. Virtio and mechanisms like posted interrupts are designed to
-   confine the VMEXITs to a bare minimum, but specific configurations and
-   application scenarios might still suffer from a high VMEXIT rate.
-
-   The kernel provides two L1D flush modes:
-    - conditional ('cond')
-    - unconditional ('always')
-
-   The conditional mode avoids L1D flushing after VMEXITs which execute
-   only audited code paths before the corresponding VMENTER. These code
-   paths have been verified that they cannot expose secrets or other
-   interesting data to an attacker, but they can leak information about the
-   address space layout of the hypervisor.
-
-   Unconditional mode flushes L1D on all VMENTER invocations and provides
-   maximum protection. It has a higher overhead than the conditional
-   mode. The overhead cannot be quantified correctly as it depends on the
-   workload scenario and the resulting number of VMEXITs.
-
-   The general recommendation is to enable L1D flush on VMENTER. The kernel
-   defaults to conditional mode on affected processors.
-
-   **Note**, that L1D flush does not prevent the SMT problem because the
-   sibling thread will also bring back its data into the L1D which makes it
-   attackable again.
-
-   L1D flush can be controlled by the administrator via the kernel command
-   line and sysfs control files. See :ref:`mitigation_control_command_line`
-   and :ref:`mitigation_control_kvm`.
-
-.. _guest_confinement:
-
-2. Guest VCPU confinement to dedicated physical cores
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-   To address the SMT problem, it is possible to make a guest or a group of
-   guests affine to one or more physical cores. The proper mechanism for
-   that is to utilize exclusive cpusets to ensure that no other guest or
-   host tasks can run on these cores.
-
-   If only a single guest or related guests run on sibling SMT threads on
-   the same physical core then they can only attack their own memory and
-   restricted parts of the host memory.
-
-   Host memory is attackable, when one of the sibling SMT threads runs in
-   host OS (hypervisor) context and the other in guest context. The amount
-   of valuable information from the host OS context depends on the context
-   which the host OS executes, i.e. interrupts, soft interrupts and kernel
-   threads. The amount of valuable data from these contexts cannot be
-   declared as non-interesting for an attacker without deep inspection of
-   the code.
-
-   **Note**, that assigning guests to a fixed set of physical cores affects
-   the ability of the scheduler to do load balancing and might have
-   negative effects on CPU utilization depending on the hosting
-   scenario. Disabling SMT might be a viable alternative for particular
-   scenarios.
-
-   For further information about confining guests to a single or to a group
-   of cores consult the cpusets documentation:
-
-   https://www.kernel.org/doc/Documentation/cgroup-v1/cpusets.txt
-
-.. _interrupt_isolation:
-
-3. Interrupt affinity
-^^^^^^^^^^^^^^^^^^^^^
-
-   Interrupts can be made affine to logical CPUs. This is not universally
-   true because there are types of interrupts which are truly per CPU
-   interrupts, e.g. the local timer interrupt. Aside of that multi queue
-   devices affine their interrupts to single CPUs or groups of CPUs per
-   queue without allowing the administrator to control the affinities.
-
-   Moving the interrupts, which can be affinity controlled, away from CPUs
-   which run untrusted guests, reduces the attack vector space.
-
-   Whether the interrupts with are affine to CPUs, which run untrusted
-   guests, provide interesting data for an attacker depends on the system
-   configuration and the scenarios which run on the system. While for some
-   of the interrupts it can be assumed that they won't expose interesting
-   information beyond exposing hints about the host OS memory layout, there
-   is no way to make general assumptions.
-
-   Interrupt affinity can be controlled by the administrator via the
-   /proc/irq/$NR/smp_affinity[_list] files. Limited documentation is
-   available at:
-
-   https://www.kernel.org/doc/Documentation/IRQ-affinity.txt
-
-.. _smt_control:
-
-4. SMT control
-^^^^^^^^^^^^^^
-
-   To prevent the SMT issues of L1TF it might be necessary to disable SMT
-   completely. Disabling SMT can have a significant performance impact, but
-   the impact depends on the hosting scenario and the type of workloads.
-   The impact of disabling SMT needs also to be weighted against the impact
-   of other mitigation solutions like confining guests to dedicated cores.
-
-   The kernel provides a sysfs interface to retrieve the status of SMT and
-   to control it. It also provides a kernel command line interface to
-   control SMT.
-
-   The kernel command line interface consists of the following options:
-
-     =========== ==========================================================
-     nosmt	 Affects the bring up of the secondary CPUs during boot. The
-		 kernel tries to bring all present CPUs online during the
-		 boot process. "nosmt" makes sure that from each physical
-		 core only one - the so called primary (hyper) thread is
-		 activated. Due to a design flaw of Intel processors related
-		 to Machine Check Exceptions the non primary siblings have
-		 to be brought up at least partially and are then shut down
-		 again.  "nosmt" can be undone via the sysfs interface.
-
-     nosmt=force Has the same effect as "nosmt" but it does not allow to
-		 undo the SMT disable via the sysfs interface.
-     =========== ==========================================================
-
-   The sysfs interface provides two files:
-
-   - /sys/devices/system/cpu/smt/control
-   - /sys/devices/system/cpu/smt/active
-
-   /sys/devices/system/cpu/smt/control:
-
-     This file allows to read out the SMT control state and provides the
-     ability to disable or (re)enable SMT. The possible states are:
-
-	==============  ===================================================
-	on		SMT is supported by the CPU and enabled. All
-			logical CPUs can be onlined and offlined without
-			restrictions.
-
-	off		SMT is supported by the CPU and disabled. Only
-			the so called primary SMT threads can be onlined
-			and offlined without restrictions. An attempt to
-			online a non-primary sibling is rejected
-
-	forceoff	Same as 'off' but the state cannot be controlled.
-			Attempts to write to the control file are rejected.
-
-	notsupported	The processor does not support SMT. It's therefore
-			not affected by the SMT implications of L1TF.
-			Attempts to write to the control file are rejected.
-	==============  ===================================================
-
-     The possible states which can be written into this file to control SMT
-     state are:
-
-     - on
-     - off
-     - forceoff
-
-   /sys/devices/system/cpu/smt/active:
-
-     This file reports whether SMT is enabled and active, i.e. if on any
-     physical core two or more sibling threads are online.
-
-   SMT control is also possible at boot time via the l1tf kernel command
-   line parameter in combination with L1D flush control. See
-   :ref:`mitigation_control_command_line`.
-
-5. Disabling EPT
-^^^^^^^^^^^^^^^^
-
-  Disabling EPT for virtual machines provides full mitigation for L1TF even
-  with SMT enabled, because the effective page tables for guests are
-  managed and sanitized by the hypervisor. Though disabling EPT has a
-  significant performance impact especially when the Meltdown mitigation
-  KPTI is enabled.
-
-  EPT can be disabled in the hypervisor via the 'kvm-intel.ept' parameter.
-
-There is ongoing research and development for new mitigation mechanisms to
-address the performance impact of disabling SMT or EPT.
-
-.. _mitigation_control_command_line:
-
-Mitigation control on the kernel command line
----------------------------------------------
-
-The kernel command line allows to control the L1TF mitigations at boot
-time with the option "l1tf=". The valid arguments for this option are:
-
-  ============  =============================================================
-  full		Provides all available mitigations for the L1TF
-		vulnerability. Disables SMT and enables all mitigations in
-		the hypervisors, i.e. unconditional L1D flushing
-
-		SMT control and L1D flush control via the sysfs interface
-		is still possible after boot.  Hypervisors will issue a
-		warning when the first VM is started in a potentially
-		insecure configuration, i.e. SMT enabled or L1D flush
-		disabled.
-
-  full,force	Same as 'full', but disables SMT and L1D flush runtime
-		control. Implies the 'nosmt=force' command line option.
-		(i.e. sysfs control of SMT is disabled.)
-
-  flush		Leaves SMT enabled and enables the default hypervisor
-		mitigation, i.e. conditional L1D flushing
-
-		SMT control and L1D flush control via the sysfs interface
-		is still possible after boot.  Hypervisors will issue a
-		warning when the first VM is started in a potentially
-		insecure configuration, i.e. SMT enabled or L1D flush
-		disabled.
-
-  flush,nosmt	Disables SMT and enables the default hypervisor mitigation,
-		i.e. conditional L1D flushing.
-
-		SMT control and L1D flush control via the sysfs interface
-		is still possible after boot.  Hypervisors will issue a
-		warning when the first VM is started in a potentially
-		insecure configuration, i.e. SMT enabled or L1D flush
-		disabled.
-
-  flush,nowarn	Same as 'flush', but hypervisors will not warn when a VM is
-		started in a potentially insecure configuration.
-
-  off		Disables hypervisor mitigations and doesn't emit any
-		warnings.
-		It also drops the swap size and available RAM limit restrictions
-		on both hypervisor and bare metal.
-
-  ============  =============================================================
-
-The default is 'flush'. For details about L1D flushing see :ref:`l1d_flush`.
-
-
-.. _mitigation_control_kvm:
-
-Mitigation control for KVM - module parameter
--------------------------------------------------------------
-
-The KVM hypervisor mitigation mechanism, flushing the L1D cache when
-entering a guest, can be controlled with a module parameter.
-
-The option/parameter is "kvm-intel.vmentry_l1d_flush=". It takes the
-following arguments:
-
-  ============  ==============================================================
-  always	L1D cache flush on every VMENTER.
-
-  cond		Flush L1D on VMENTER only when the code between VMEXIT and
-		VMENTER can leak host memory which is considered
-		interesting for an attacker. This still can leak host memory
-		which allows e.g. to determine the hosts address space layout.
-
-  never		Disables the mitigation
-  ============  ==============================================================
-
-The parameter can be provided on the kernel command line, as a module
-parameter when loading the modules and at runtime modified via the sysfs
-file:
-
-/sys/module/kvm_intel/parameters/vmentry_l1d_flush
-
-The default is 'cond'. If 'l1tf=full,force' is given on the kernel command
-line, then 'always' is enforced and the kvm-intel.vmentry_l1d_flush
-module parameter is ignored and writes to the sysfs file are rejected.
-
-
-Mitigation selection guide
---------------------------
-
-1. No virtualization in use
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-   The system is protected by the kernel unconditionally and no further
-   action is required.
-
-2. Virtualization with trusted guests
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-   If the guest comes from a trusted source and the guest OS kernel is
-   guaranteed to have the L1TF mitigations in place the system is fully
-   protected against L1TF and no further action is required.
-
-   To avoid the overhead of the default L1D flushing on VMENTER the
-   administrator can disable the flushing via the kernel command line and
-   sysfs control files. See :ref:`mitigation_control_command_line` and
-   :ref:`mitigation_control_kvm`.
-
-
-3. Virtualization with untrusted guests
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-3.1. SMT not supported or disabled
-""""""""""""""""""""""""""""""""""
-
-  If SMT is not supported by the processor or disabled in the BIOS or by
-  the kernel, it's only required to enforce L1D flushing on VMENTER.
-
-  Conditional L1D flushing is the default behaviour and can be tuned. See
-  :ref:`mitigation_control_command_line` and :ref:`mitigation_control_kvm`.
-
-3.2. EPT not supported or disabled
-""""""""""""""""""""""""""""""""""
-
-  If EPT is not supported by the processor or disabled in the hypervisor,
-  the system is fully protected. SMT can stay enabled and L1D flushing on
-  VMENTER is not required.
-
-  EPT can be disabled in the hypervisor via the 'kvm-intel.ept' parameter.
-
-3.3. SMT and EPT supported and active
-"""""""""""""""""""""""""""""""""""""
-
-  If SMT and EPT are supported and active then various degrees of
-  mitigations can be employed:
-
-  - L1D flushing on VMENTER:
-
-    L1D flushing on VMENTER is the minimal protection requirement, but it
-    is only potent in combination with other mitigation methods.
-
-    Conditional L1D flushing is the default behaviour and can be tuned. See
-    :ref:`mitigation_control_command_line` and :ref:`mitigation_control_kvm`.
-
-  - Guest confinement:
-
-    Confinement of guests to a single or a group of physical cores which
-    are not running any other processes, can reduce the attack surface
-    significantly, but interrupts, soft interrupts and kernel threads can
-    still expose valuable data to a potential attacker. See
-    :ref:`guest_confinement`.
-
-  - Interrupt isolation:
-
-    Isolating the guest CPUs from interrupts can reduce the attack surface
-    further, but still allows a malicious guest to explore a limited amount
-    of host physical memory. This can at least be used to gain knowledge
-    about the host address space layout. The interrupts which have a fixed
-    affinity to the CPUs which run the untrusted guests can depending on
-    the scenario still trigger soft interrupts and schedule kernel threads
-    which might expose valuable information. See
-    :ref:`interrupt_isolation`.
-
-The above three mitigation methods combined can provide protection to a
-certain degree, but the risk of the remaining attack surface has to be
-carefully analyzed. For full protection the following methods are
-available:
-
-  - Disabling SMT:
-
-    Disabling SMT and enforcing the L1D flushing provides the maximum
-    amount of protection. This mitigation is not depending on any of the
-    above mitigation methods.
-
-    SMT control and L1D flushing can be tuned by the command line
-    parameters 'nosmt', 'l1tf', 'kvm-intel.vmentry_l1d_flush' and at run
-    time with the matching sysfs control files. See :ref:`smt_control`,
-    :ref:`mitigation_control_command_line` and
-    :ref:`mitigation_control_kvm`.
-
-  - Disabling EPT:
-
-    Disabling EPT provides the maximum amount of protection as well. It is
-    not depending on any of the above mitigation methods. SMT can stay
-    enabled and L1D flushing is not required, but the performance impact is
-    significant.
-
-    EPT can be disabled in the hypervisor via the 'kvm-intel.ept'
-    parameter.
-
-3.4. Nested virtual machines
-""""""""""""""""""""""""""""
-
-When nested virtualization is in use, three operating systems are involved:
-the bare metal hypervisor, the nested hypervisor and the nested virtual
-machine.  VMENTER operations from the nested hypervisor into the nested
-guest will always be processed by the bare metal hypervisor. If KVM is the
-bare metal hypervisor it will:
-
- - Flush the L1D cache on every switch from the nested hypervisor to the
-   nested virtual machine, so that the nested hypervisor's secrets are not
-   exposed to the nested virtual machine;
-
- - Flush the L1D cache on every switch from the nested virtual machine to
-   the nested hypervisor; this is a complex operation, and flushing the L1D
-   cache avoids that the bare metal hypervisor's secrets are exposed to the
-   nested virtual machine;
-
- - Instruct the nested hypervisor to not perform any L1D cache flush. This
-   is an optimization to avoid double L1D flushing.
-
-
-.. _default_mitigations:
-
-Default mitigations
--------------------
-
-  The kernel default mitigations for vulnerable processors are:
-
-  - PTE inversion to protect against malicious user space. This is done
-    unconditionally and cannot be controlled. The swap storage is limited
-    to ~16TB.
-
-  - L1D conditional flushing on VMENTER when EPT is enabled for
-    a guest.
-
-  The kernel does not by default enforce the disabling of SMT, which leaves
-  SMT systems vulnerable when running untrusted guests with EPT enabled.
-
-  The rationale for this choice is:
-
-  - Force disabling SMT can break existing setups, especially with
-    unattended updates.
-
-  - If regular users run untrusted guests on their machine, then L1TF is
-    just an add on to other malware which might be embedded in an untrusted
-    guest, e.g. spam-bots or attacks on the local network.
-
-    There is no technical way to prevent a user from running untrusted code
-    on their machines blindly.
-
-  - It's technically extremely unlikely and from today's knowledge even
-    impossible that L1TF can be exploited via the most popular attack
-    mechanisms like JavaScript because these mechanisms have no way to
-    control PTEs. If this would be possible and not other mitigation would
-    be possible, then the default might be different.
-
-  - The administrators of cloud and hosting setups have to carefully
-    analyze the risk for their scenarios and make the appropriate
-    mitigation choices, which might even vary across their deployed
-    machines and also result in other changes of their overall setup.
-    There is no way for the kernel to provide a sensible default for this
-    kind of scenarios.

[patch V6 14/14] MDS basics 14

[Thomas Gleixner]

Subject: [patch V6 14/14] Documentation: Add MDS vulnerability documentation
From: Thomas Gleixner <tglx@linutronix.de>

Add the initial MDS vulnerability documentation.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
V5 --> V6: Fix the protection matrix, minor tweaks vs. idle mitigation
           and MSBDS only systems.
V4 --> V5: Remove 'auto' option. Adjust virt mitigation info.
V1 --> V4: Added the missing pieces
---
 Documentation/admin-guide/hw-vuln/index.rst |    1 
 Documentation/admin-guide/hw-vuln/l1tf.rst  |    1 
 Documentation/admin-guide/hw-vuln/mds.rst   |  307 ++++++++++++++++++++++++++++
 3 files changed, 309 insertions(+)

--- a/Documentation/admin-guide/hw-vuln/index.rst
+++ b/Documentation/admin-guide/hw-vuln/index.rst
@@ -10,3 +10,4 @@ are configurable at compile, boot or run
    :maxdepth: 1
 
    l1tf
+   mds
--- a/Documentation/admin-guide/hw-vuln/l1tf.rst
+++ b/Documentation/admin-guide/hw-vuln/l1tf.rst
@@ -445,6 +445,7 @@ The default is 'cond'. If 'l1tf=full,for
 line, then 'always' is enforced and the kvm-intel.vmentry_l1d_flush
 module parameter is ignored and writes to the sysfs file are rejected.
 
+.. _mitigation_selection:
 
 Mitigation selection guide
 --------------------------
--- /dev/null
+++ b/Documentation/admin-guide/hw-vuln/mds.rst
@@ -0,0 +1,307 @@
+MDS - Microarchitectural Data Sampling
+======================================
+
+Microarchitectural Data Sampling is a hardware vulnerability which allows
+unprivileged speculative access to data which is available in various CPU
+internal buffers.
+
+Affected processors
+-------------------
+
+This vulnerability affects a wide range of Intel processors. The
+vulnerability is not present on:
+
+   - Processors from AMD, Centaur and other non Intel vendors
+
+   - Older processor models, where the CPU family is < 6
+
+   - Some Atoms (Bonnell, Saltwell, Goldmont, GoldmontPlus)
+
+   - Intel processors which have the ARCH_CAP_MDS_NO bit set in the
+     IA32_ARCH_CAPABILITIES MSR.
+
+Whether a processor is affected or not can be read out from the MDS
+vulnerability file in sysfs. See :ref:`mds_sys_info`.
+
+Not all processors are affected by all variants of MDS, but the mitigation
+is identical for all of them so the kernel treats them as a single
+vulnerability.
+
+Related CVEs
+------------
+
+The following CVE entries are related to the MDS vulnerability:
+
+   ==============  =====  ==============================================
+   CVE-2018-12126  MSBDS  Microarchitectural Store Buffer Data Sampling
+   CVE-2018-12130  MFBDS  Microarchitectural Fill Buffer Data Sampling
+   CVE-2018-12127  MLPDS  Microarchitectural Load Port Data Sampling
+   ==============  =====  ==============================================
+
+Problem
+-------
+
+When performing store, load, L1 refill operations, processors write data
+into temporary microarchitectural structures (buffers). The data in the
+buffer can be forwarded to load operations as an optimization.
+
+Under certain conditions, usually a fault/assist caused by a load
+operation, data unrelated to the load memory address can be speculatively
+forwarded from the buffers. Because the load operation causes a fault or
+assist and its result will be discarded, the forwarded data will not cause
+incorrect program execution or state changes. But a malicious operation
+may be able to forward this speculative data to a disclosure gadget which
+allows in turn to infer the value via a cache side channel attack.
+
+Because the buffers are potentially shared between Hyper-Threads cross
+Hyper-Thread attacks are possible.
+
+Deeper technical information is available in the MDS specific x86
+architecture section: :ref:`Documentation/x86/mds.rst <mds>`.
+
+
+Attack scenarios
+----------------
+
+Attacks against the MDS vulnerabilities can be mounted from malicious non
+priviledged user space applications running on hosts or guest. Malicious
+guest OSes can obviously mount attacks as well.
+
+Contrary to other speculation based vulnerabilities the MDS vulnerability
+does not allow the attacker to control the memory target address. As a
+consequence the attacks are purely sampling based, but as demonstrated with
+the TLBleed attack samples can be postprocessed successfully.
+
+Web-Browsers
+^^^^^^^^^^^^
+
+  It's unclear whether attacks through Web-Browsers are possible at
+  all. The exploitation through Java-Script is considered very unlikely,
+  but other widely used web technologies like Webassembly could possibly be
+  abused.
+
+
+.. _mds_sys_info:
+
+MDS system information
+-----------------------
+
+The Linux kernel provides a sysfs interface to enumerate the current MDS
+status of the system: whether the system is vulnerable, and which
+mitigations are active. The relevant sysfs file is:
+
+/sys/devices/system/cpu/vulnerabilities/mds
+
+The possible values in this file are:
+
+  =========================================   =================================
+  'Not affected'				The processor is not vulnerable
+
+  'Vulnerable'					The processor is vulnerable,
+						but no mitigation enabled
+
+  'Vulnerable: Clear CPU buffers attempted'	The processor is vulnerable but
+						microcode is not updated.
+						The mitigation is enabled on a
+						best effort basis.
+						See :ref:`vmwerv`
+
+  'Mitigation: CPU buffer clear'		The processor is vulnerable and the
+						CPU buffer clearing mitigation is
+						enabled.
+  =========================================   =================================
+
+If the processor is vulnerable then the following information is appended
+to the above information:
+
+    ========================  ============================================
+    'SMT vulnerable'          SMT is enabled
+    'SMT mitigated'           SMT is enabled and mitigated
+    'SMT disabled'            SMT is disabled
+    'SMT Host state unknown'  Kernel runs in a VM, Host SMT state unknown
+    ========================  ============================================
+
+.. _vmwerv:
+
+Best effort mitigation mode
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+  If the processor is vulnerable, but the availability of the microcode based
+  mitigation mechanism is not advertised via CPUID the kernel selects a best
+  effort mitigation mode.  This mode invokes the mitigation instructions
+  without a guarantee that they clear the CPU buffers.
+
+  This is done to address virtualization scenarios where the host has the
+  microcode update applied, but the hypervisor is not yet updated to expose
+  the CPUID to the guest. If the host has updated microcode the protection
+  takes effect otherwise a few cpu cycles are wasted pointlessly.
+
+  The state in the mds sysfs file reflects this situation accordingly.
+
+
+Mitigation mechanism
+-------------------------
+
+The kernel detects the affected CPUs and the presence of the microcode
+which is required.
+
+If a CPU is affected and the microcode is available, then the kernel
+enables the mitigation by default. The mitigation can be controlled at boot
+time via a kernel command line option. See
+:ref:`mds_mitigation_control_command_line`.
+
+.. _cpu_buffer_clear:
+
+CPU buffer clearing
+^^^^^^^^^^^^^^^^^^^
+
+  The mitigation for MDS clears the affected CPU buffers on return to user
+  space and when entering a guest.
+
+  If SMT is enabled it also clears the buffers on idle entry when the CPU
+  is only affected by MSBDS and not any other MDS variant, because the
+  other variants cannot be protected against cross Hyper-Thread attacks.
+
+  For CPUs which are only affected by MSBDS the user space, guest and idle
+  transition mitigations are sufficient and SMT is not affected.
+
+.. _virt_mechanism:
+
+Virtualization mitigation
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+  The protection for host to guest transition depends on the L1TF
+  vulnerability of the CPU:
+
+  - CPU is affected by L1TF:
+
+    If the L1D flush mitigation is enabled and up to date microcode is
+    available, the L1D flush mitigation is automatically protecting the
+    guest transition.
+
+    If the L1D flush mitigation is disabled then the MDS mitigation is
+    invoked explicit when the host MDS mitigation is enabled.
+
+    For details on L1TF and virtualization see:
+    :ref:`Documentation/admin-guide/hw-vuln//l1tf.rst <mitigation_control_kvm>`.
+
+  - CPU is not affected by L1TF:
+
+    CPU buffers are flushed before entering the guest when the host MDS
+    mitigation is enabled.
+
+  The resulting MDS protection matrix for the host to guest transition:
+
+  ============ ===== ============= ============ =================
+   L1TF         MDS   VMX-L1FLUSH   Host MDS     MDS-State
+
+   Don't care   No    Don't care    N/A          Not affected
+
+   Yes          Yes   Disabled      Off          Vulnerable
+
+   Yes          Yes   Disabled      Full         Mitigated
+
+   Yes          Yes   Enabled       Don't care   Mitigated
+
+   No           Yes   N/A           Off          Vulnerable
+
+   No           Yes   N/A           Full         Mitigated
+  ============ ===== ============= ============ =================
+
+  This only covers the host to guest transition, i.e. prevents leakage from
+  host to guest, but does not protect the guest internally. Guests need to
+  have their own protections.
+
+.. _xeon_phi:
+
+XEON PHI specific considerations
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+  The XEON PHI processor family is affected by MSBDS which can be exploited
+  cross Hyper-Threads when entering idle states. Some XEON PHI variants allow
+  to use MWAIT in user space (Ring 3) which opens an potential attack vector
+  for malicious user space. The exposure can be disabled on the kernel
+  command line with the 'ring3mwait=disable' command line option.
+
+  XEON PHI is not affected by the other MDS variants and MSBDS is mitigated
+  before the CPU enters a idle state. As XEON PHI is not affected by L1TF
+  either disabling SMT is not required for full protection.
+
+.. _mds_smt_control:
+
+SMT control
+^^^^^^^^^^^
+
+  All MDS variants except MSBDS can be attacked cross Hyper-Threads. That
+  means on CPUs which are affected by MFBDS or MLPDS it is necessary to
+  disable SMT for full protection. These are most of the affected CPUs; the
+  exception is XEON PHI, see :ref:`xeon_phi`.
+
+  Disabling SMT can have a significant performance impact, but the impact
+  depends on the type of workloads.
+
+  See the relevant chapter in the L1TF mitigation documentation for details:
+  :ref:`Documentation/admin-guide/hw-vuln/l1tf.rst <smt_control>`.
+
+
+.. _mds_mitigation_control_command_line:
+
+Mitigation control on the kernel command line
+---------------------------------------------
+
+The kernel command line allows to control the MDS mitigations at boot
+time with the option "mds=". The valid arguments for this option are:
+
+  ============  =============================================================
+  full		If the CPU is vulnerable, enable all available mitigations
+		for the MDS vulnerability, CPU buffer clearing on exit to
+		userspace and when entering a VM. Idle transitions are
+		protected as well if SMT is enabled.
+
+		It does not automatically disable SMT.
+
+  off		Disables MDS mitigations completely.
+
+  ============  =============================================================
+
+Not specifying this option is equivalent to "mds=full".
+
+
+Mitigation selection guide
+--------------------------
+
+1. Trusted userspace
+^^^^^^^^^^^^^^^^^^^^
+
+   If all userspace applications are from a trusted source and do not
+   execute untrusted code which is supplied externally, then the mitigation
+   can be disabled.
+
+
+2. Virtualization with trusted guests
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+   The same considerations as above versus trusted user space apply.
+
+3. Virtualization with untrusted guests
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+   The protection depends on the state of the L1TF mitigations.
+   See :ref:`virt_mechanism`.
+
+   If the MDS mitigation is enabled and SMT is disabled, guest to host and
+   guest to guest attacks are prevented.
+
+.. _mds_default_mitigations:
+
+Default mitigations
+-------------------
+
+  The kernel default mitigations for vulnerable processors are:
+
+  - Enable CPU buffer clearing
+
+  The kernel does not by default enforce the disabling of SMT, which leaves
+  SMT systems vulnerable when running untrusted code. The same rationale as
+  for L1TF applies.
+  See :ref:`Documentation/admin-guide/hw-vuln//l1tf.rst <default_mitigations>`.

Re: [patch V6 00/14] MDS basics 0

[Thomas Gleixner]

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

On Fri, 1 Mar 2019, speck for Thomas Gleixner wrote:
> 
> I'll send git bundles of the pile as well.

Attached.

Thanks,

	tglx

[-- Attachment #2: Type: application/octet-stream, Size: 36555 bytes --]

[-- Attachment #3: Type: application/octet-stream, Size: 37958 bytes --]

[-- Attachment #4: Type: application/octet-stream, Size: 44988 bytes --]

[-- Attachment #5: Type: application/octet-stream, Size: 47246 bytes --]

[MODERATED] Re: [patch V6 01/14] MDS basics 1

[Frederic Weisbecker]

On Fri, Mar 01, 2019 at 10:47:39PM +0100, speck for Thomas Gleixner wrote:
> Subject: [patch V6 01/14] x86/msr-index: Cleanup bit defines
> From: Thomas Gleixner <tglx@linutronix.de>
> 
> Greg pointed out that speculation related bit defines are using (1 << N)
> format instead of BIT(N). Aside of that (1 << N) is wrong as it should use
> 1UL at least.
> 
> Clean it up.
> 
> [ Josh Poimboeuf: Fix tools build ]
> 
> Reported-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Reviewed-by: Borislav Petkov <bp@suse.de>
> ---
> V5 -> V6: Fix tools build (Josh)

Reviewed-by: Frederic Weisbecker <frederic@kernel.org>

[MODERATED] Re: [patch V6 02/14] MDS basics 2

[Frederic Weisbecker]

On Fri, Mar 01, 2019 at 10:47:40PM +0100, speck for Thomas Gleixner wrote:
>  static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)
>  {
>  	u64 ia32_cap = 0;
>  
> -	if (x86_match_cpu(cpu_no_speculation))
> +	if (cpu_matches(NO_SPECULATION))
>  		return;
>  
>  	setup_force_cpu_bug(X86_BUG_SPECTRE_V1);
> @@ -1011,15 +1022,14 @@ static void __init cpu_set_bug_bits(stru
>  	if (cpu_has(c, X86_FEATURE_ARCH_CAPABILITIES))
>  		rdmsrl(MSR_IA32_ARCH_CAPABILITIES, ia32_cap);
>  
> -	if (!x86_match_cpu(cpu_no_spec_store_bypass) &&
> -	   !(ia32_cap & ARCH_CAP_SSB_NO) &&
> +	if (!cpu_matches(NO_SSB) && !(ia32_cap & ARCH_CAP_SSB_NO) &&

Much clearer and well unified.

Reviewed-by: Frederic Weisbecker <frederic@kernel.org>

[MODERATED] Re: [patch V6 03/14] MDS basics 3

[Frederic Weisbecker]

On Fri, Mar 01, 2019 at 10:47:41PM +0100, speck for Thomas Gleixner wrote:
> Subject: [patch V6 03/14] x86/speculation/mds: Add basic bug infrastructure for MDS
> +	/* AMD Family 0xf - 0x12 */
> +	VULNWL_AMD(0x0f,	NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS),
> +	VULNWL_AMD(0x10,	NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS),
> +	VULNWL_AMD(0x11,	NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS),
> +	VULNWL_AMD(0x12,	NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS),

Lucky guys :-)

Reviewed-by: Frederic Weisbecker <frederic@kernel.org>

[MODERATED] Re: [patch V6 04/14] MDS basics 4

[Frederic Weisbecker]

On Fri, Mar 01, 2019 at 10:47:42PM +0100, speck for Thomas Gleixner wrote:
> Subject: [patch V6 04/14] x86/speculation/mds: Add BUG_MSBDS_ONLY
> From: Thomas Gleixner <tglx@linutronix.de>
> 
> This bug bit is set on CPUs which are only affected by Microarchitectural
> Store Buffer Data Sampling (MSBDS) and not by any other MDS variant.
> 
> This is important because the Store Buffers are partitioned between
> Hyper-Threads so cross thread forwarding is not possible. But if a thread
> enters or exits a sleep state the store buffer is repartitioned which can
> expose data from one thread to the other. This transition can be mitigated.
> 
> That means that for CPUs which are only affected by MSBDS SMT can be
> enabled, if the CPU is not affected by other SMT sensitive vulnerabilities,
> e.g. L1TF. The XEON PHI variants fall into that category.
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> ---
>  arch/x86/include/asm/cpufeatures.h |    1 +
>  arch/x86/kernel/cpu/common.c       |   10 +++++++---
>  2 files changed, 8 insertions(+), 3 deletions(-)
> 
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@ -383,5 +383,6 @@
>  #define X86_BUG_SPEC_STORE_BYPASS	X86_BUG(17) /* CPU is affected by speculative store bypass attack */
>  #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 */
>  
>  #endif /* _ASM_X86_CPUFEATURES_H */
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -953,6 +953,7 @@ static void identify_cpu_without_cpuid(s
>  #define NO_SSB		BIT(2)
>  #define NO_L1TF		BIT(3)
>  #define NO_MDS		BIT(4)
> +#define MSBDS_ONLY	BIT(5)
>  
>  #define VULNWL(_vendor, _family, _model, _whitelist)	\
>  	{ X86_VENDOR_##_vendor, _family, _model, X86_FEATURE_ANY, _whitelist }
> @@ -983,8 +984,8 @@ static const __initconst struct x86_cpu_
>  	VULNWL_INTEL(ATOM_SILVERMONT_X,		NO_SSB | NO_L1TF),
>  	VULNWL_INTEL(ATOM_SILVERMONT_MID,	NO_SSB | NO_L1TF),
>  	VULNWL_INTEL(ATOM_AIRMONT,		NO_SSB | NO_L1TF),
> -	VULNWL_INTEL(XEON_PHI_KNL,		NO_SSB | NO_L1TF),
> -	VULNWL_INTEL(XEON_PHI_KNM,		NO_SSB | NO_L1TF),
> +	VULNWL_INTEL(XEON_PHI_KNL,		NO_SSB | NO_L1TF | MSBDS_ONLY),
> +	VULNWL_INTEL(XEON_PHI_KNM,		NO_SSB | NO_L1TF | MSBDS_ONLY),
>  
>  	VULNWL_INTEL(CORE_YONAH,		NO_SSB),
>  
> @@ -1033,8 +1034,11 @@ static void __init cpu_set_bug_bits(stru
>  	if (ia32_cap & ARCH_CAP_IBRS_ALL)
>  		setup_force_cpu_cap(X86_FEATURE_IBRS_ENHANCED);
>  
> -	if (!cpu_matches(NO_MDS) && !(ia32_cap & ARCH_CAP_MDS_NO))
> +	if (!cpu_matches(NO_MDS) && !(ia32_cap & ARCH_CAP_MDS_NO)) {
>  		setup_force_cpu_bug(X86_BUG_MDS);
> +		if (cpu_matches(MSBDS_ONLY))
> +			setup_force_cpu_bug(X86_BUG_MSBDS_ONLY);
> +	}
>  
>  	if (cpu_matches(NO_MELTDOWN))
>  		return;
> 

It looks weird to have it as a separate bug flag and not as a subset of full
MDS such as:

    #define NO_IDLE_SHARED_MDS BIT(4)
    #define NO_SHARED_MDS      BIT(5)
    #define NO_MDS             (NO_IDLE_SHARED_MDS | NO_SHARED_MDS)

Now that would probably make sense only if the mitigation of full MDS required
to also imply a VERW before entering idle (that's the mitigation of MSBDS_ONLY, right?).
Turning off SMT removes the need to do that so the layout seem to make sense as is.

Reviewed-by: Frederic Weisbecker <frederic@kernel.org>

[MODERATED] Re: [patch V6 05/14] MDS basics 5

[Frederic Weisbecker]

On Fri, Mar 01, 2019 at 10:47:43PM +0100, speck for Thomas Gleixner wrote:
> From: Andi Kleen <ak@linux.intel.com>
> Subject: [patch V6 05/14] x86/kvm: Expose X86_FEATURE_MD_CLEAR to guests
> 
> X86_FEATURE_MD_CLEAR is a new CPUID bit which is set when microcode
> provides the mechanism to invoke a flush of various exploitable CPU buffers
> by invoking the VERW instruction.
> 
> Hand it through to guests so they can adjust their mitigations.
> 
> This also requires corresponding qemu changes, which are available
> separately.
> 
> [ tglx: Massaged changelog ]
> 
> Signed-off-by: Andi Kleen <ak@linux.intel.com>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Reviewed-by: Borislav Petkov <bp@suse.de>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Reviewed-by: Frederic Weisbecker <frederic@kernel.org>

[MODERATED] Re: [patch V6 07/14] MDS basics 7

[Frederic Weisbecker]

On Fri, Mar 01, 2019 at 10:47:45PM +0100, speck for Thomas Gleixner wrote:
> +
> +   - Debug Exception (#DB):
> +
> +     This takes the paranoid exit path only when the INT1 breakpoint is in
> +     kernel space. #DB on a user space address takes the regular exit path,
> +     so no extra mitigation required.

I can't find that part in this patch, maybe it's further in the series?

> --- a/arch/x86/kernel/nmi.c
> +++ b/arch/x86/kernel/nmi.c
> @@ -34,6 +34,7 @@
>  #include <asm/x86_init.h>
>  #include <asm/reboot.h>
>  #include <asm/cache.h>
> +#include <asm/nospec-branch.h>
>  
>  #define CREATE_TRACE_POINTS
>  #include <trace/events/nmi.h>
> @@ -533,6 +534,9 @@ do_nmi(struct pt_regs *regs, long error_
>  		write_cr2(this_cpu_read(nmi_cr2));
>  	if (this_cpu_dec_return(nmi_state))
>  		goto nmi_restart;
> +
> +	if (user_mode(regs))
> +		mds_user_clear_cpu_buffers();

What if the NMI fires after a call to prepare_exit_to_usermode()
but before the actual return to usermode, would that be a problem?

Thanks.

[MODERATED] Re: [patch V6 02/14] MDS basics 2

[Greg KH]

On Fri, Mar 01, 2019 at 10:47:40PM +0100, speck for Thomas Gleixner wrote:
> Subject: [patch V6 02/14] x86/speculation: Consolidate CPU whitelists
> From: Thomas Gleixner <tglx@linutronix.de>
> 
> The CPU vulnerability whitelists have some overlap and there are more
> whitelists coming along.
> 
> Use the driver_data field in the x86_cpu_id struct to denote the
> whitelisted vulnerabilities and combine all whitelists into one.
> 
> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

[MODERATED] Re: [patch V6 08/14] MDS basics 8

[Frederic Weisbecker]

On Fri, Mar 01, 2019 at 10:47:46PM +0100, speck for Thomas Gleixner wrote:
> CPUs which are affected by L1TF and MDS mitigate MDS with the L1D Flush on
> VMENTER when updated microcode is installed.
> 
> If a CPU is not affected by L1TF or if the L1D Flush is not in use, then
> MDS mitigation needs to be invoked explicit.
> 
> For these cases, follow the host mitigation state and invoke the MDS
> mitigation before VMENTER.
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> V4 --> V5: Fix changelog
> ---
>  arch/x86/kernel/cpu/bugs.c |    1 +
>  arch/x86/kvm/vmx/vmx.c     |    2 ++
>  2 files changed, 3 insertions(+)
> 
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -65,6 +65,7 @@ DEFINE_STATIC_KEY_FALSE(switch_mm_always
>  
>  /* Control MDS CPU buffer clear before returning to user space */
>  DEFINE_STATIC_KEY_FALSE(mds_user_clear);
> +EXPORT_SYMBOL_GPL(mds_user_clear);
>  
>  void __init check_bugs(void)
>  {
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -6371,6 +6371,8 @@ static void __vmx_vcpu_run(struct kvm_vc

We may want to add a comment below to summarize what's explained
in the changelog. git blame tends to lose prime history after any
future most unsignificant variable rename. Something like:

  +     /* l1tf mitigation, if present, spares us mds mitigation */

>  	if (static_branch_unlikely(&vmx_l1d_should_flush))
>  		vmx_l1d_flush(vcpu);
> +	else if (static_branch_unlikely(&mds_user_clear))
> +		mds_clear_cpu_buffers();

Reviewed-by: Frederic Weisbecker <frederic@kernel.org>

Thanks.

[MODERATED] Re: [patch V6 13/14] MDS basics 13

[Josh Poimboeuf]

On Fri, Mar 01, 2019 at 10:47:51PM +0100, speck for Thomas Gleixner wrote:
> Subject: [patch V6 13/14] Documentation: Move L1TF to separate directory
> From: Thomas Gleixner <tglx@linutronix.de>
> 
> Move L!TF to a separate directory so the MDS stuff can be added at the
> side. Otherwise the all hardware vulnerabilites have their own top level
> entry. Should have done that right away.
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

$ git grep admin-guide |grep l1tf |grep -v hw-vuln
Documentation/ABI/testing/sysfs-devices-system-cpu:		Documentation/admin-guide/l1tf.rst
Documentation/admin-guide/kernel-parameters.txt:			For details see: Documentation/admin-guide/l1tf.rst
arch/x86/kernel/cpu/bugs.c:		pr_info("Reading https://www.kernel.org/doc/html/latest/admin-guide/l1tf.html might help you decide.\n");
arch/x86/kvm/vmx/vmx.c:#define L1TF_MSG_SMT "L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-guide/l1tf.html for details.\n"
arch/x86/kvm/vmx/vmx.c:#define L1TF_MSG_L1D "L1TF CPU bug present and virtualization mitigation disabled, data leak possible. See CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-guide/l1tf.html for details.\n"

-- 
Josh

[MODERATED] Encrypted Message

[Jon Masters]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/rfc822-headers; protected-headers="v1", Size: 130 bytes --]

From: Jon Masters <jcm@redhat.com>
To: speck for Thomas Gleixner <speck@linutronix.de>
Subject: Re: [patch V6 00/14] MDS basics 0

[-- Attachment #2: Type: text/plain, Size: 1408 bytes --]

On 3/1/19 4:47 PM, speck for Thomas Gleixner wrote:
> Changes vs. V5:
> 
>   - Fix tools/ build (Josh)
> 
>   - Dropped the AIRMONT_MID change as it needs confirmation from Intel
> 
>   - Made the consolidated whitelist more readable and correct
> 
>   - Added the MSBDS only quirk for XEON PHI, made the idle flush
>     depend on it and updated the sysfs output accordingly.
> 
>   - Fixed the protection matrix in the admin documentation and clarified
>     the SMT situation vs. MSBDS only.
> 
>   - Updated the KVM/VMX changelog.
> 
> Delta patch against V5 below.
> 
> Available from git:
> 
>    cvs.ou.linutronix.de:linux/speck/linux WIP.mds
> 
> The linux-4.20.y, linux-4.19.y and linux-4.14.y branches are updated as
> well and contain the untested backports of the pile for reference.
> 
> I'll send git bundles of the pile as well.

Tested on Coffeelake with updated ucode successfully:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 158
model name      : Intel(R) Core(TM) i7-8086K CPU @ 4.00GHz
stepping        : 10
microcode       : 0xae

[jcm@stephen ~]$ dmesg|grep MDS
[    1.633165] MDS: Mitigation: Clear CPU buffers

[jcm@stephen ~]$ cat /sys/devices/system/cpu/vulnerabilities/mds
Mitigation: Clear CPU buffers; SMT vulnerable

Jon.

-- 
Computer Architect | Sent with my Fedora powered laptop

[MODERATED] Encrypted Message

[Jon Masters]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/rfc822-headers; protected-headers="v1", Size: 131 bytes --]

From: Jon Masters <jcm@redhat.com>
To: speck for Thomas Gleixner <speck@linutronix.de>
Subject: Re: [patch V6 12/14] MDS basics 12

[-- Attachment #2: Type: text/plain, Size: 1553 bytes --]

On 3/1/19 4:47 PM, speck for Thomas Gleixner wrote:

> Subject: [patch V6 12/14] x86/speculation/mds: Add mitigation mode VMWERV
> From: Thomas Gleixner <tglx@linutronix.de>
> 
> In virtualized environments it can happen that the host has the microcode
> update which utilizes the VERW instruction to clear CPU buffers, but the
> hypervisor is not yet updated to expose the X86_FEATURE_MD_CLEAR CPUID bit
> to guests.
> 
> Introduce an internal mitigation mode VWWERV which enables the invocation
> of the CPU buffer clearing even if X86_FEATURE_MD_CLEAR is not set. If the
> system has no updated microcode this results in a pointless execution of
> the VERW instruction wasting a few CPU cycles. If the microcode is updated,
> but not exposed to a guest then the CPU buffers will be cleared.
> 
> That said: Virtual Machines Will Eventually Receive Vaccine

The effect of this patch, currently, is that a (bare metal) machine
without updated ucode will print the following:

[    1.576602] MDS: Vulnerable: Clear CPU buffers attempted, no microcode

The intention of the patch is to say "hey, you might be on a VM, so
we'll try anyway in case we didn't get told you had MD_CLEAR". But the
effect on bare metal might be ambiguous. It's reasonable (for someone
else) to assume we might be using a software sequence to try flushing.

Perhaps the wording should convey something like:

"MDS: Vulnerable: Clear CPU buffers may not work, no microcode"

Jon.

-- 
Computer Architect | Sent with my Fedora powered laptop

[MODERATED] Encrypted Message

[Jon Masters]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/rfc822-headers; protected-headers="v1", Size: 130 bytes --]

From: Jon Masters <jcm@redhat.com>
To: speck for Thomas Gleixner <speck@linutronix.de>
Subject: Re: [patch V6 06/14] MDS basics 6

[-- Attachment #2: Type: text/plain, Size: 1195 bytes --]

On 3/1/19 4:47 PM, speck for Thomas Gleixner wrote:
> Provide a inline function with the assembly magic. The argument of the VERW
> instruction must be a memory operand as documented:
> 
>   "MD_CLEAR enumerates that the memory-operand variant of VERW (for
>    example, VERW m16) has been extended to also overwrite buffers affected
>    by MDS. This buffer overwriting functionality is not guaranteed for the
>    register operand variant of VERW."
> 
> Documentation also recommends to use a writable data segment selector:
> 
>   "The buffer overwriting occurs regardless of the result of the VERW
>    permission check, as well as when the selector is null or causes a
>    descriptor load segment violation. However, for lowest latency we
>    recommend using a selector that indicates a valid writable data
>    segment."

Note that we raised this again with Intel last week amid Andrew's
results and they are going to get back to us if this guidance changes as
a result of further measurements on their end. It's a few cycles
difference in the Coffeelake case, but it could always be higher.

Jon.

-- 
Computer Architect | Sent with my Fedora powered laptop

[MODERATED] Encrypted Message

[Jon Masters]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/rfc822-headers; protected-headers="v1", Size: 131 bytes --]

From: Jon Masters <jcm@redhat.com>
To: speck for Thomas Gleixner <speck@linutronix.de>
Subject: Re: [patch V6 10/14] MDS basics 10

[-- Attachment #2: Type: text/plain, Size: 306 bytes --]

On 3/1/19 4:47 PM, speck for Thomas Gleixner wrote:

> +	/*
> +	 * Enable the idle clearing on CPUs which are affected only by
> +	 * MDBDS and not any other MDS variant. The other variants cannot
           ^^^^^
           MSBDS


-- 
Computer Architect | Sent with my Fedora powered laptop

[MODERATED] Encrypted Message

[Jon Masters]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/rfc822-headers; protected-headers="v1", Size: 130 bytes --]

From: Jon Masters <jcm@redhat.com>
To: speck for Thomas Gleixner <speck@linutronix.de>
Subject: Re: [patch V6 08/14] MDS basics 8

[-- Attachment #2: Type: text/plain, Size: 491 bytes --]

On 3/1/19 4:47 PM, speck for Thomas Gleixner wrote:
>  	if (static_branch_unlikely(&vmx_l1d_should_flush))
>  		vmx_l1d_flush(vcpu);
> +	else if (static_branch_unlikely(&mds_user_clear))
> +		mds_clear_cpu_buffers();

Does this cover the case where we have older ucode installed that does
L1D flush but NOT the MD_CLEAR? I'm about to go check to see if there's
logic handling this but wanted to call it out.

Jon.

-- 
Computer Architect | Sent with my Fedora powered laptop

[MODERATED] Encrypted Message

[Jon Masters]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/rfc822-headers; protected-headers="v1", Size: 126 bytes --]

From: Jon Masters <jcm@redhat.com>
To: speck for Jon Masters <speck@linutronix.de>
Subject: Re: [patch V6 08/14] MDS basics 8

[-- Attachment #2: Type: text/plain, Size: 877 bytes --]

On 3/4/19 1:57 AM, speck for Jon Masters wrote:
> On 3/1/19 4:47 PM, speck for Thomas Gleixner wrote:
>>  	if (static_branch_unlikely(&vmx_l1d_should_flush))
>>  		vmx_l1d_flush(vcpu);
>> +	else if (static_branch_unlikely(&mds_user_clear))
>> +		mds_clear_cpu_buffers();
> 
> Does this cover the case where we have older ucode installed that does
> L1D flush but NOT the MD_CLEAR? I'm about to go check to see if there's
> logic handling this but wanted to call it out.

Aside from the above question, I've reviewed all of the patches
extensively at this point. Feel free to add a Reviewed-by or Tested-by
according to your preference. I've a bunch of further tests running,
including on AMD platforms just so to check nothing broke with those
platforms that are not susceptible to MDS.

Jon.

-- 
Computer Architect | Sent with my Fedora powered laptop

[MODERATED] Encrypted Message

[Jon Masters]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/rfc822-headers; protected-headers="v1", Size: 126 bytes --]

From: Jon Masters <jcm@redhat.com>
To: speck for Jon Masters <speck@linutronix.de>
Subject: Re: [patch V6 08/14] MDS basics 8

[-- Attachment #2: Type: text/plain, Size: 1075 bytes --]

On 3/4/19 2:06 AM, speck for Jon Masters wrote:
> On 3/4/19 1:57 AM, speck for Jon Masters wrote:
>> On 3/1/19 4:47 PM, speck for Thomas Gleixner wrote:
>>>  	if (static_branch_unlikely(&vmx_l1d_should_flush))
>>>  		vmx_l1d_flush(vcpu);
>>> +	else if (static_branch_unlikely(&mds_user_clear))
>>> +		mds_clear_cpu_buffers();
>>
>> Does this cover the case where we have older ucode installed that does
>> L1D flush but NOT the MD_CLEAR? I'm about to go check to see if there's
>> logic handling this but wanted to call it out.
> 
> Aside from the above question, I've reviewed all of the patches
> extensively at this point. Feel free to add a Reviewed-by or Tested-by
> according to your preference. I've a bunch of further tests running,
> including on AMD platforms just so to check nothing broke with those
> platforms that are not susceptible to MDS.

Running fine on AMD platform here and reports correctly:

$ cat /sys/devices/system/cpu/vulnerabilities/mds
Not affected

Jon.

-- 
Computer Architect | Sent with my Fedora powered laptop

Re: [patch V6 04/14] MDS basics 4

[Thomas Gleixner]

On Sat, 2 Mar 2019, speck for Frederic Weisbecker wrote:
> On Fri, Mar 01, 2019 at 10:47:42PM +0100, speck for Thomas Gleixner wrote:
> >  	if (cpu_matches(NO_MELTDOWN))
> >  		return;
> > 
> 
> It looks weird to have it as a separate bug flag and not as a subset of full
> MDS such as:
> 
>     #define NO_IDLE_SHARED_MDS BIT(4)
>     #define NO_SHARED_MDS      BIT(5)
>     #define NO_MDS             (NO_IDLE_SHARED_MDS | NO_SHARED_MDS)
> 
> Now that would probably make sense only if the mitigation of full MDS required
> to also imply a VERW before entering idle (that's the mitigation of MSBDS_ONLY, right?).
> Turning off SMT removes the need to do that so the layout seem to make sense as is.

Yeah, I had several variants of the theme, but all of them sucked in one
way or the other.

Thanks,

	tglx

Re: Encrypted Message

[Thomas Gleixner]

On Mon, 4 Mar 2019, speck for Jon Masters wrote:
> > Documentation also recommends to use a writable data segment selector:
> > 
> >   "The buffer overwriting occurs regardless of the result of the VERW
> >    permission check, as well as when the selector is null or causes a
> >    descriptor load segment violation. However, for lowest latency we
> >    recommend using a selector that indicates a valid writable data
> >    segment."
>
> Note that we raised this again with Intel last week amid Andrew's
> results and they are going to get back to us if this guidance changes as
> a result of further measurements on their end. It's a few cycles
> difference in the Coffeelake case, but it could always be higher.

Ok. We can fix that up on top once we have final answers.

Thanks,

	tglx

Re: [patch V6 07/14] MDS basics 7

[Thomas Gleixner]

On Sat, 2 Mar 2019, speck for Frederic Weisbecker wrote:

> On Fri, Mar 01, 2019 at 10:47:45PM +0100, speck for Thomas Gleixner wrote:
> > +
> > +   - Debug Exception (#DB):
> > +
> > +     This takes the paranoid exit path only when the INT1 breakpoint is in
> > +     kernel space. #DB on a user space address takes the regular exit path,
> > +     so no extra mitigation required.
> 
> I can't find that part in this patch, maybe it's further in the series?

There is no patch. #DB is not interesting as explained above.

> > --- a/arch/x86/kernel/nmi.c
> > +++ b/arch/x86/kernel/nmi.c
> > @@ -34,6 +34,7 @@
> >  #include <asm/x86_init.h>
> >  #include <asm/reboot.h>
> >  #include <asm/cache.h>
> > +#include <asm/nospec-branch.h>
> >  
> >  #define CREATE_TRACE_POINTS
> >  #include <trace/events/nmi.h>
> > @@ -533,6 +534,9 @@ do_nmi(struct pt_regs *regs, long error_
> >  		write_cr2(this_cpu_read(nmi_cr2));
> >  	if (this_cpu_dec_return(nmi_state))
> >  		goto nmi_restart;
> > +
> > +	if (user_mode(regs))
> > +		mds_user_clear_cpu_buffers();
> 
> What if the NMI fires after a call to prepare_exit_to_usermode()
> but before the actual return to usermode, would that be a problem?

Yes, it's a hole in the protection, but you would need to be able to
orchestrate that as user which I doubt you can. So the thought was that we
rather avoid the penalty for perf when it hits kernel space, which requires
root ....

Thanks,

	tglx

Re: Encrypted Message

[Thomas Gleixner]

On Mon, 4 Mar 2019, speck for Jon Masters wrote:

> On 3/1/19 4:47 PM, speck for Thomas Gleixner wrote:
> >       if (static_branch_unlikely(&vmx_l1d_should_flush))
> >               vmx_l1d_flush(vcpu);
> > +     else if (static_branch_unlikely(&mds_user_clear))
> > +             mds_clear_cpu_buffers();
> 
> Does this cover the case where we have older ucode installed that does
> L1D flush but NOT the MD_CLEAR? I'm about to go check to see if there's
> logic handling this but wanted to call it out.

If no updated microcode is available then it's pretty irrelevant which code
path you take. None of them will mitigate MDS.

Thanks,

	tglx

Re: Encrypted Message

[Thomas Gleixner]

On Mon, 4 Mar 2019, speck for Jon Masters wrote:

> > That said: Virtual Machines Will Eventually Receive Vaccine
> 
> The effect of this patch, currently, is that a (bare metal) machine
> without updated ucode will print the following:
> 
> [    1.576602] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
> 
> The intention of the patch is to say "hey, you might be on a VM, so
> we'll try anyway in case we didn't get told you had MD_CLEAR". But the
> effect on bare metal might be ambiguous. It's reasonable (for someone
> else) to assume we might be using a software sequence to try flushing.
> 
> Perhaps the wording should convey something like:
> 
> "MDS: Vulnerable: Clear CPU buffers may not work, no microcode"

Yeah, we also could do something like the delta patch below:

Thanks,

	tglx

8<------------------

--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -228,18 +228,28 @@ static const char * const mds_strings[]
 	[MDS_MITIGATION_VMWERV]	= "Vulnerable: Clear CPU buffers attempted, no microcode",
 };
 
-static void mds_select_mitigation(void)
+static void __init mds_check_md_clear(void)
+{
+	if (!boot_cpu_has(X86_FEATURE_MD_CLEAR)) {
+		if (hypervisor_is_type(X86_HYPER_NATIVE)) {
+			mds_mitigation = MDS_MITIGATION_OFF;
+			return;
+		}
+		mds_mitigation = MDS_MITIGATION_VMWERV;
+	}
+	static_branch_enable(&mds_user_clear);
+}
+
+static void __init mds_select_mitigation(void)
 {
 	if (!boot_cpu_has_bug(X86_BUG_MDS)) {
 		mds_mitigation = MDS_MITIGATION_OFF;
 		return;
 	}
 
-	if (mds_mitigation == MDS_MITIGATION_FULL) {
-		if (!boot_cpu_has(X86_FEATURE_MD_CLEAR))
-			mds_mitigation = MDS_MITIGATION_VMWERV;
-		static_branch_enable(&mds_user_clear);
-	}
+	if (mds_mitigation == MDS_MITIGATION_FULL)
+		mds_check_md_clear();
+
 	pr_info("%s\n", mds_strings[mds_mitigation]);
 }
 

Re: [patch V6 13/14] MDS basics 13

[Thomas Gleixner]

On Sat, 2 Mar 2019, speck for Josh Poimboeuf wrote:

> On Fri, Mar 01, 2019 at 10:47:51PM +0100, speck for Thomas Gleixner wrote:
> > Subject: [patch V6 13/14] Documentation: Move L1TF to separate directory
> > From: Thomas Gleixner <tglx@linutronix.de>
> > 
> > Move L!TF to a separate directory so the MDS stuff can be added at the
> > side. Otherwise the all hardware vulnerabilites have their own top level
> > entry. Should have done that right away.
> > 
> > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> > Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> $ git grep admin-guide |grep l1tf |grep -v hw-vuln
> Documentation/ABI/testing/sysfs-devices-system-cpu:		Documentation/admin-guide/l1tf.rst
> Documentation/admin-guide/kernel-parameters.txt:			For details see: Documentation/admin-guide/l1tf.rst
> arch/x86/kernel/cpu/bugs.c:		pr_info("Reading https://www.kernel.org/doc/html/latest/admin-guide/l1tf.html might help you decide.\n");
> arch/x86/kvm/vmx/vmx.c:#define L1TF_MSG_SMT "L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-guide/l1tf.html for details.\n"
> arch/x86/kvm/vmx/vmx.c:#define L1TF_MSG_L1D "L1TF CPU bug present and virtualization mitigation disabled, data leak possible. See CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-guide/l1tf.html for details.\n"
> 

Ah. Indeed....

[MODERATED] Re: [patch V6 12/14] MDS basics 12

[mark gross]

On Fri, Mar 01, 2019 at 10:47:50PM +0100, speck for Thomas Gleixner wrote:
> Subject: [patch V6 12/14] x86/speculation/mds: Add mitigation mode VMWERV
> From: Thomas Gleixner <tglx@linutronix.de>
> 
> In virtualized environments it can happen that the host has the microcode
> update which utilizes the VERW instruction to clear CPU buffers, but the
> hypervisor is not yet updated to expose the X86_FEATURE_MD_CLEAR CPUID bit
> to guests.
> 
> Introduce an internal mitigation mode VWWERV which enables the invocation
minor type-oh.                 s/VWWERV/VMWERV/

--mark

[MODERATED] Re: [patch V6 13/14] MDS basics 13

[mark gross]

On Fri, Mar 01, 2019 at 10:47:51PM +0100, speck for Thomas Gleixner wrote:
> Subject: [patch V6 13/14] Documentation: Move L1TF to separate directory
> From: Thomas Gleixner <tglx@linutronix.de>
> 
> Move L!TF to a separate directory so the MDS stuff can be added at the
s/L!TF/L1TF

--mark

[MODERATED] Re: [patch V6 02/14] MDS basics 2

[Borislav Petkov]

On Fri, Mar 01, 2019 at 10:47:40PM +0100, speck for Thomas Gleixner wrote:
> Subject: [patch V6 02/14] x86/speculation: Consolidate CPU whitelists
> From: Thomas Gleixner <tglx@linutronix.de>
> 
> The CPU vulnerability whitelists have some overlap and there are more
> whitelists coming along.
> 
> Use the driver_data field in the x86_cpu_id struct to denote the
> whitelisted vulnerabilities and combine all whitelists into one.
> 
> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> ---
> 
> V5 --> V6: Use a helper macro to make it more readable
>            Fix the AMD family 0xf-0x12 vs. ANY ordering
> ---
>  arch/x86/kernel/cpu/common.c |  110 +++++++++++++++++++++++--------------------
>  1 file changed, 60 insertions(+), 50 deletions(-)

Yap, nice and clean.

Reviewed-by: Borislav Petkov <bp@suse.de>

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[MODERATED] Re: [patch V6 10/14] MDS basics 10

[Andrea Arcangeli]

Hi Thomas,

On Fri, Mar 01, 2019 at 10:47:48PM +0100, speck for Thomas Gleixner wrote:
> +/* Update the static key controlling the MDS CPU buffer clear in idle */
> +static void update_mds_branch_idle(void)
> +{
> +	/*
> +	 * Enable the idle clearing on CPUs which are affected only by
> +	 * MDBDS and not any other MDS variant. The other variants cannot
> +	 * be mitigated when SMT is enabled, so clearing the buffers on
> +	 * idle would be a window dressing exercise.
> +	 */
> +	if (!boot_cpu_has(X86_BUG_MSBDS_ONLY))
> +		return;
> +
> +	if (sched_smt_active())
> +		static_branch_enable(&mds_idle_clear);

Do you think it's worth also clearing
MSR_MISC_FEATURES_ENABLES_RING3MWAIT_BIT by setting
ring3mwait_disabled when sched_smt_active() is true above?

I don't expect anybody will pass manually ring3mwait=disable to the
kernel on XEON_PHI_KNL/XEON_PHI_KNM. I'm not aware of any app using
the user mwait, which also makes this not a big deal.. but it goes
both ways, it's also not a big deal for userland to turn it off when
we report SMT is enabled and safe in sysfs.

Thanks,
Andrea

[MODERATED] Re: [patch V6 07/14] MDS basics 7

[Borislav Petkov]

On Fri, Mar 01, 2019 at 10:47:45PM +0100, speck for Thomas Gleixner wrote:
> Subject: [patch V6 07/14] x86/speculation/mds: Clear CPU buffers on exit to user
> From: Thomas Gleixner <tglx@linutronix.de>
> 
> Add a static key which controls the invocation of the CPU buffer clear
> mechanism on exit to user space and add the call into
> prepare_exit_to_usermode() and do_nmi() right before actually returning.
> 
> Add documentation which kernel to user space transition this covers and
> explain why some corner cases are not mitigated.
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> ---
> V4 --> v5: Use an inline helper instead of open coding it.
> 	   Rework the documentation paragraph about exceptions.
> 
> V3 --> V4: Add #DS mitigation and document that the #MC corner case
>        	   is really not interesting.
> 
> V3: Add NMI conditional on user regs and update documentation accordingly.
>     Use the static branch scheme suggested by Peter. Fix typos ...
> ---
>  Documentation/x86/mds.rst            |   52 +++++++++++++++++++++++++++++++++++
>  arch/x86/entry/common.c              |    3 ++
>  arch/x86/include/asm/nospec-branch.h |   13 ++++++++
>  arch/x86/kernel/cpu/bugs.c           |    3 ++
>  arch/x86/kernel/nmi.c                |    4 ++
>  arch/x86/kernel/traps.c              |    7 ++++
>  6 files changed, 82 insertions(+)

...

> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -366,6 +366,13 @@ dotraplinkage void do_double_fault(struc
>  		regs->ip = (unsigned long)general_protection;
>  		regs->sp = (unsigned long)&gpregs->orig_ax;
>  
> +		/*
> +		 * This situation can be triggered by userspace via
> +		 * modify_ldt(2) and the return does not take the regular
> +		 * user space exit, so a CPU buffer clear is required when
> +		 * MDS mitigation is enabled.
> +		 */
> +		mds_user_clear_cpu_buffers();
>  		return;
>  	}
>  #endif

Looks like the traps.c change is missing a hunk, see below. Otherwise:

arch/x86/kernel/traps.c: In function ‘do_double_fault’:
arch/x86/kernel/traps.c:375:3: error: implicit declaration of function ‘mds_user_clear_cpu_buffers’ [-Werror=implicit-function-declaration]
   mds_user_clear_cpu_buffers();
   ^~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:276: arch/x86/kernel/traps.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [scripts/Makefile.build:492: arch/x86/kernel] Error 2
make: *** [Makefile:1043: arch/x86] Error 2
make: *** Waiting for unfinished jobs....

---
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 5942060dba9a..ce33f7f672d6 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -61,6 +61,7 @@
 #include <asm/mpx.h>
 #include <asm/vm86.h>
 #include <asm/umip.h>
+#include <asm/nospec-branch.h>
 
 #ifdef CONFIG_X86_64
 #include <asm/x86_init.h>
---

with that

Reviewed-by: Borislav Petkov <bp@suse.de>

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[MODERATED] Re: [patch V6 08/14] MDS basics 8

[Borislav Petkov]

On Fri, Mar 01, 2019 at 10:47:46PM +0100, speck for Thomas Gleixner wrote:
> CPUs which are affected by L1TF and MDS mitigate MDS with the L1D Flush on
> VMENTER when updated microcode is installed.
> 
> If a CPU is not affected by L1TF or if the L1D Flush is not in use, then
> MDS mitigation needs to be invoked explicit.

				     explicitly.

> 
> For these cases, follow the host mitigation state and invoke the MDS
> mitigation before VMENTER.
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> V4 --> V5: Fix changelog
> ---
>  arch/x86/kernel/cpu/bugs.c |    1 +
>  arch/x86/kvm/vmx/vmx.c     |    2 ++
>  2 files changed, 3 insertions(+)

With that:

Reviewed-by: Borislav Petkov <bp@suse.de>

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[MODERATED] Re: [patch V6 10/14] MDS basics 10

[Borislav Petkov]

On Fri, Mar 01, 2019 at 10:47:48PM +0100, speck for Thomas Gleixner wrote:
> Subject: [patch V6 10/14] x86/speculation/mds: Add mitigation control for MDS
> From: Thomas Gleixner <tglx@linutronix.de>
> 
> Now that the mitigations are in place, add a command line parameter to
> control the mitigation, a mitigation selector function and a SMT update
> mechanism.
> 
> This is the minimal straight forward initial implementation which just
> provides an always on/off mode. The command line parameter is:
> 
>   mds=[full|off]
> 
> This is consistent with the existing mitigations for other speculative
> hardware vulnerabilities.
> 
> The idle invocation is dynamically updated according to the SMT state of
> the system similar to the dynamic update of the STIBP mitigation. The idle
> mitigation is limited to CPUs which are only affected by MSBDS and not any
> other variant, because the other variants cannot be mitigated on SMT
> enabled systems.
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> ---
> V5 --> V6: Make idle clearing depend on BUG_MSBDS_ONLY
> V4 --> V5: Remove 'auto'
> ---

...

> @@ -617,6 +664,24 @@ static void update_indir_branch_cond(voi
>  		static_branch_disable(&switch_to_cond_stibp);
>  }
>  
> +/* Update the static key controlling the MDS CPU buffer clear in idle */
> +static void update_mds_branch_idle(void)
> +{
> +	/*
> +	 * Enable the idle clearing on CPUs which are affected only by
> +	 * MDBDS and not any other MDS variant. The other variants cannot
> +	 * be mitigated when SMT is enabled,

... but we're not enabling the key when SMT on those is disabled,
AFAICT. Or is that coming later?

> so clearing the buffers on
> +	 * idle would be a window dressing exercise.
> +	 */
> +	if (!boot_cpu_has(X86_BUG_MSBDS_ONLY))

	if (!boot_cpu_has_bug

> +		return;
> +
> +	if (sched_smt_active())
> +		static_branch_enable(&mds_idle_clear);
> +	else
> +		static_branch_disable(&mds_idle_clear);
> +}
> +
>  void arch_smt_update(void)
>  {
>  	/* Enhanced IBRS implies STIBP. No update required. */
> @@ -638,6 +703,9 @@ void arch_smt_update(void)
>  		break;
>  	}
>  
> +	if (mds_mitigation == MDS_MITIGATION_FULL)
> +		update_mds_branch_idle();
> +
>  	mutex_unlock(&spec_ctrl_mutex);
>  }
>  
> 

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[MODERATED] Re: [patch V6 12/14] MDS basics 12

[Borislav Petkov]

On Fri, Mar 01, 2019 at 10:47:50PM +0100, speck for Thomas Gleixner wrote:
> Subject: [patch V6 12/14] x86/speculation/mds: Add mitigation mode VMWERV
> From: Thomas Gleixner <tglx@linutronix.de>
> 
> In virtualized environments it can happen that the host has the microcode
> update which utilizes the VERW instruction to clear CPU buffers, but the
> hypervisor is not yet updated to expose the X86_FEATURE_MD_CLEAR CPUID bit
> to guests.
> 
> Introduce an internal mitigation mode VWWERV which enables the invocation
> of the CPU buffer clearing even if X86_FEATURE_MD_CLEAR is not set. If the
> system has no updated microcode this results in a pointless execution of
> the VERW instruction wasting a few CPU cycles. If the microcode is updated,
> but not exposed to a guest then the CPU buffers will be cleared.
> 
> That said: Virtual Machines Will Eventually Receive Vaccine
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> ---
> V2 -> V3: Rename mode.
> ---
>  Documentation/x86/mds.rst        |   27 +++++++++++++++++++++++++++
>  arch/x86/include/asm/processor.h |    1 +
>  arch/x86/kernel/cpu/bugs.c       |   18 ++++++++++++------
>  3 files changed, 40 insertions(+), 6 deletions(-)

...

> @@ -235,10 +236,9 @@ static void mds_select_mitigation(void)
>  	}
>  
>  	if (mds_mitigation == MDS_MITIGATION_FULL) {
> -		if (boot_cpu_has(X86_FEATURE_MD_CLEAR))
> -			static_branch_enable(&mds_user_clear);
> -		else
> -			mds_mitigation = MDS_MITIGATION_OFF;
> +		if (!boot_cpu_has(X86_FEATURE_MD_CLEAR))
> +			mds_mitigation = MDS_MITIGATION_VMWERV;
> +		static_branch_enable(&mds_user_clear);
>  	}
>  	pr_info("%s\n", mds_strings[mds_mitigation]);
>  }
> @@ -703,8 +703,14 @@ void arch_smt_update(void)
>  		break;
>  	}
>  
> -	if (mds_mitigation == MDS_MITIGATION_FULL)
> +	switch(mds_mitigation) {

ERROR: space required before the open parenthesis '('
#119: FILE: arch/x86/kernel/cpu/bugs.c:706:
+       switch(mds_mitigation) {


with that addressed:

Reviewed-by: Borislav Petkov <bp@suse.de>

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

Re: [patch V6 10/14] MDS basics 10

[Thomas Gleixner]

On Wed, 6 Mar 2019, speck for Borislav Petkov wrote:
> On Fri, Mar 01, 2019 at 10:47:48PM +0100, speck for Thomas Gleixner wrote:
> > +/* Update the static key controlling the MDS CPU buffer clear in idle */
> > +static void update_mds_branch_idle(void)
> > +{
> > +	/*
> > +	 * Enable the idle clearing on CPUs which are affected only by
> > +	 * MDBDS and not any other MDS variant. The other variants cannot
> > +	 * be mitigated when SMT is enabled,
> 
> ... but we're not enabling the key when SMT on those is disabled,
> AFAICT. Or is that coming later?

Five lines down ....
 
> > so clearing the buffers on
> > +	 * idle would be a window dressing exercise.
> > +	 */
> > +	if (!boot_cpu_has(X86_BUG_MSBDS_ONLY))
> 
> 	if (!boot_cpu_has_bug

Fixed.

> > +		return;
> > +
> > +	if (sched_smt_active())


... here is the decision whether to enable or disable.

> > +		static_branch_enable(&mds_idle_clear);
> > +	else
> > +		static_branch_disable(&mds_idle_clear);
> > +}

Thanks,

	tglx

[MODERATED] Re: [patch V6 07/14] MDS basics 7

[Frederic Weisbecker]

On Tue, Mar 05, 2019 at 04:30:38PM +0100, speck for Thomas Gleixner wrote:
> On Sat, 2 Mar 2019, speck for Frederic Weisbecker wrote:
> 
> > On Fri, Mar 01, 2019 at 10:47:45PM +0100, speck for Thomas Gleixner wrote:
> > > +
> > > +   - Debug Exception (#DB):
> > > +
> > > +     This takes the paranoid exit path only when the INT1 breakpoint is in
> > > +     kernel space. #DB on a user space address takes the regular exit path,
> > > +     so no extra mitigation required.
> > 
> > I can't find that part in this patch, maybe it's further in the series?
> 
> There is no patch. #DB is not interesting as explained above.

Oh right, my brainfart...

> 
> > > --- a/arch/x86/kernel/nmi.c
> > > +++ b/arch/x86/kernel/nmi.c
> > > @@ -34,6 +34,7 @@
> > >  #include <asm/x86_init.h>
> > >  #include <asm/reboot.h>
> > >  #include <asm/cache.h>
> > > +#include <asm/nospec-branch.h>
> > >  
> > >  #define CREATE_TRACE_POINTS
> > >  #include <trace/events/nmi.h>
> > > @@ -533,6 +534,9 @@ do_nmi(struct pt_regs *regs, long error_
> > >  		write_cr2(this_cpu_read(nmi_cr2));
> > >  	if (this_cpu_dec_return(nmi_state))
> > >  		goto nmi_restart;
> > > +
> > > +	if (user_mode(regs))
> > > +		mds_user_clear_cpu_buffers();
> > 
> > What if the NMI fires after a call to prepare_exit_to_usermode()
> > but before the actual return to usermode, would that be a problem?
> 
> Yes, it's a hole in the protection, but you would need to be able to
> orchestrate that as user which I doubt you can. So the thought was that we
> rather avoid the penalty for perf when it hits kernel space, which requires
> root ....

Fair enough.

Reviewed-by: Frederic Weisbecker <frederic@kernel.org>

[MODERATED] Re: [patch V6 09/14] MDS basics 9

[Frederic Weisbecker]

On Fri, Mar 01, 2019 at 10:47:47PM +0100, speck for Thomas Gleixner wrote:
> Subject: [patch V6 09/14] x86/speculation/mds: Conditionally clear CPU buffers on idle entry
> From: Thomas Gleixner <tglx@linutronix.de>
> 
> Add a static key which controls the invocation of the CPU buffer clear
> mechanism on idle entry. This is independent of other MDS mitigations
> because the idle entry invocation to mitigate the potential leakage due to
> store buffer repartitioning is only necessary on SMT systems.
> 
> Add the actual invocations to the different halt/mwait variants which
> covers all usage sites. mwaitx is not patched as it's not available on
> Intel CPUs.
> 
> The buffer clear is only invoked before entering the C-State to prevent
> that stale data from the idling CPU is spilled to the Hyper-Thread sibling
> after the Store buffer got repartitioned and all entries are available to
> the non idle sibling.
> 
> When coming out of idle the store buffer is partitioned again so each
> sibling has half of it available. Now CPU which returned from idle could be
> speculatively exposed to contents of the sibling, but the buffers are
> flushed either on exit to user space or on VMENTER.
> 
> When later on conditional buffer clearing is implemented on top of this,
> then there is no action required either because before returning to user
> space the context switch will set the condition flag which causes a flush
> on the return to user path.
> 
> Note, that the buffer clearing on idle is only sensible on CPUs which are
> solely affected by MSBDS and not any other variant of MDS because the other
> MDS variants cannot be mitigated when SMT is enabled, so the buffer
> clearing on idle would be a window dressing exercise.
> 
> This intentionally does not handle the case in the acpi/processor_idle
> driver which uses the legacy IO port interface for C-State transitions for
> two reasons:
> 
>  - The acpi/processor_idle driver was replaced by the intel_idle driver
>    almost a decade ago. Anything Nehalem upwards supports it and defaults
>    to that new driver.
> 
>  - The legacy IO port interface is likely to be used on older and therefore
>    unaffected CPUs or on systems which do not receive microcode updates
>    anymore, so there is no point in adding that.
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Reviewed-by: Borislav Petkov <bp@suse.de>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Reviewed-by: Frederic Weisbecker <frederic@kernel.org>

[MODERATED] Encrypted Message

[Jon Masters]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/rfc822-headers; protected-headers="v1", Size: 118 bytes --]

From: Jon Masters <jcm@redhat.com>
To: speck for Thomas Gleixner <speck@linutronix.de>
Subject: Re: Encrypted Message

[-- Attachment #2: Type: text/plain, Size: 990 bytes --]

On 3/5/19 10:34 AM, speck for Thomas Gleixner wrote:
> On Mon, 4 Mar 2019, speck for Jon Masters wrote:
> 
>> On 3/1/19 4:47 PM, speck for Thomas Gleixner wrote:
>>>       if (static_branch_unlikely(&vmx_l1d_should_flush))
>>>               vmx_l1d_flush(vcpu);
>>> +     else if (static_branch_unlikely(&mds_user_clear))
>>> +             mds_clear_cpu_buffers();
>>
>> Does this cover the case where we have older ucode installed that does
>> L1D flush but NOT the MD_CLEAR? I'm about to go check to see if there's
>> logic handling this but wanted to call it out.
> 
> If no updated microcode is available then it's pretty irrelevant which code
> path you take. None of them will mitigate MDS.

You're right. My fear was we'd have some microcode that mitigated L1D
without implied MD clear but also did MDS. I was incorrect - all ucode
that will be publicly released will have both properties.

Jon.

-- 
Computer Architect | Sent with my Fedora powered laptop

Re: [patch V6 10/14] MDS basics 10

[Thomas Gleixner]

On Wed, 6 Mar 2019, speck for Thomas Gleixner wrote:

> On Wed, 6 Mar 2019, speck for Borislav Petkov wrote:
> > On Fri, Mar 01, 2019 at 10:47:48PM +0100, speck for Thomas Gleixner wrote:
> > > +/* Update the static key controlling the MDS CPU buffer clear in idle */
> > > +static void update_mds_branch_idle(void)
> > > +{
> > > +	/*
> > > +	 * Enable the idle clearing on CPUs which are affected only by
> > > +	 * MDBDS and not any other MDS variant. The other variants cannot
> > > +	 * be mitigated when SMT is enabled,
> > 
> > ... but we're not enabling the key when SMT on those is disabled,
> > AFAICT. Or is that coming later?
> 
> Five lines down ....

Following up on our conversation on IRC, I've reworded the comment:

 	/*
	 * Enable the idle clearing if SMT is active on CPUs which are
	 * affected only by MSBDS and not any other MDS variant.
	 *
	 * The other variants cannot be mitigated when SMT is enabled, so
	 * clearing the buffers on idle just to prevent the Store Buffer
	 * repartitioning leak would be a window dressing exercise.
 	 */
 	if (!boot_cpu_has_bug(X86_BUG_MSBDS_ONLY))
 		return;

Thanks,

	tglx

Re: [patch V6 10/14] MDS basics 10

[Thomas Gleixner]

Andrea,

On Tue, 5 Mar 2019, speck for Andrea Arcangeli wrote:

> Hi Thomas,
> 
> On Fri, Mar 01, 2019 at 10:47:48PM +0100, speck for Thomas Gleixner wrote:
> > +/* Update the static key controlling the MDS CPU buffer clear in idle */
> > +static void update_mds_branch_idle(void)
> > +{
> > +	/*
> > +	 * Enable the idle clearing on CPUs which are affected only by
> > +	 * MDBDS and not any other MDS variant. The other variants cannot
> > +	 * be mitigated when SMT is enabled, so clearing the buffers on
> > +	 * idle would be a window dressing exercise.
> > +	 */
> > +	if (!boot_cpu_has(X86_BUG_MSBDS_ONLY))
> > +		return;
> > +
> > +	if (sched_smt_active())
> > +		static_branch_enable(&mds_idle_clear);
> 
> Do you think it's worth also clearing
> MSR_MISC_FEATURES_ENABLES_RING3MWAIT_BIT by setting
> ring3mwait_disabled when sched_smt_active() is true above?

Not sure.

> I don't expect anybody will pass manually ring3mwait=disable to the
> kernel on XEON_PHI_KNL/XEON_PHI_KNM. I'm not aware of any app using
> the user mwait, which also makes this not a big deal.. but it goes
> both ways, it's also not a big deal for userland to turn it off when
> we report SMT is enabled and safe in sysfs.

True and as usual we don't really know what people are doing and wreckaging
existing applications which rely on that would be not nice.

Thanks,

	tglx

[MODERATED] Re: Re: [patch V6 10/14] MDS basics 10

[Borislav Petkov]

On Wed, Mar 06, 2019 at 07:35:26PM +0100, speck for Thomas Gleixner wrote:
> Following up on our conversation on IRC, I've reworded the comment:
> 
>  	/*
> 	 * Enable the idle clearing if SMT is active on CPUs which are
> 	 * affected only by MSBDS and not any other MDS variant.
> 	 *
> 	 * The other variants cannot be mitigated when SMT is enabled, so
> 	 * clearing the buffers on idle just to prevent the Store Buffer
> 	 * repartitioning leak would be a window dressing exercise.
>  	 */
>  	if (!boot_cpu_has_bug(X86_BUG_MSBDS_ONLY))
>  		return;

Yap, looks good.

With that addressed:

Reviewed-by: Borislav Petkov <bp@suse.de>

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[MODERATED] Re: [patch V6 04/14] MDS basics 4

[Andrew Cooper]

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

On 01/03/2019 21:47, speck for Thomas Gleixner wrote:
> Subject: [patch V6 04/14] x86/speculation/mds: Add BUG_MSBDS_ONLY
> From: Thomas Gleixner <tglx@linutronix.de>
>
> This bug bit is set on CPUs which are only affected by Microarchitectural
> Store Buffer Data Sampling (MSBDS) and not by any other MDS variant.
>
> This is important because the Store Buffers are partitioned between
> Hyper-Threads so cross thread forwarding is not possible. But if a thread
> enters or exits a sleep state the store buffer is repartitioned which can
> expose data from one thread to the other. This transition can be mitigated.
>
> That means that for CPUs which are only affected by MSBDS SMT can be
> enabled, if the CPU is not affected by other SMT sensitive vulnerabilities,
> e.g. L1TF. The XEON PHI variants fall into that category.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> ---
>  arch/x86/include/asm/cpufeatures.h |    1 +
>  arch/x86/kernel/cpu/common.c       |   10 +++++++---
>  2 files changed, 8 insertions(+), 3 deletions(-)
>
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@ -383,5 +383,6 @@
>  #define X86_BUG_SPEC_STORE_BYPASS	X86_BUG(17) /* CPU is affected by speculative store bypass attack */
>  #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 */
>  
>  #endif /* _ASM_X86_CPUFEATURES_H */
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -953,6 +953,7 @@ static void identify_cpu_without_cpuid(s
>  #define NO_SSB		BIT(2)
>  #define NO_L1TF		BIT(3)
>  #define NO_MDS		BIT(4)
> +#define MSBDS_ONLY	BIT(5)
>  
>  #define VULNWL(_vendor, _family, _model, _whitelist)	\
>  	{ X86_VENDOR_##_vendor, _family, _model, X86_FEATURE_ANY, _whitelist }
> @@ -983,8 +984,8 @@ static const __initconst struct x86_cpu_
>  	VULNWL_INTEL(ATOM_SILVERMONT_X,		NO_SSB | NO_L1TF),
>  	VULNWL_INTEL(ATOM_SILVERMONT_MID,	NO_SSB | NO_L1TF),
>  	VULNWL_INTEL(ATOM_AIRMONT,		NO_SSB | NO_L1TF),
> -	VULNWL_INTEL(XEON_PHI_KNL,		NO_SSB | NO_L1TF),
> -	VULNWL_INTEL(XEON_PHI_KNM,		NO_SSB | NO_L1TF),
> +	VULNWL_INTEL(XEON_PHI_KNL,		NO_SSB | NO_L1TF | MSBDS_ONLY),
> +	VULNWL_INTEL(XEON_PHI_KNM,		NO_SSB | NO_L1TF | MSBDS_ONLY),

Looking at the table in the magic PDF, Silvermont/Airmont are MDBDS_ONLY
as well.

The model numbers listed in the Silvermont/Airmont category are 37, 4a,
4c, 4d, 5a, 5d, 6e, 65, 75.

The first 5 of those models match up with Linux's Silvermont/Airmont
names, while the last 4 are unknown.  I can't locate them anywhere and
have requested clarification.

~Andrew

Re: [patch V6 04/14] MDS basics 4

[Thomas Gleixner]

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

On Wed, 6 Mar 2019, speck for Andrew Cooper wrote:
> On 01/03/2019 21:47, speck for Thomas Gleixner wrote:
> >  #define VULNWL(_vendor, _family, _model, _whitelist)	\
> >  	{ X86_VENDOR_##_vendor, _family, _model, X86_FEATURE_ANY, _whitelist }
> > @@ -983,8 +984,8 @@ static const __initconst struct x86_cpu_
> >  	VULNWL_INTEL(ATOM_SILVERMONT_X,		NO_SSB | NO_L1TF),
> >  	VULNWL_INTEL(ATOM_SILVERMONT_MID,	NO_SSB | NO_L1TF),
> >  	VULNWL_INTEL(ATOM_AIRMONT,		NO_SSB | NO_L1TF),
> > -	VULNWL_INTEL(XEON_PHI_KNL,		NO_SSB | NO_L1TF),
> > -	VULNWL_INTEL(XEON_PHI_KNM,		NO_SSB | NO_L1TF),
> > +	VULNWL_INTEL(XEON_PHI_KNL,		NO_SSB | NO_L1TF | MSBDS_ONLY),
> > +	VULNWL_INTEL(XEON_PHI_KNM,		NO_SSB | NO_L1TF | MSBDS_ONLY),
> 
> Looking at the table in the magic PDF, Silvermont/Airmont are MDBDS_ONLY
> as well.
> 
> The model numbers listed in the Silvermont/Airmont category are 37, 4a,
> 4c, 4d, 5a, 5d, 6e, 65, 75.
> 
> The first 5 of those models match up with Linux's Silvermont/Airmont
> names, while the last 4 are unknown.  I can't locate them anywhere and
> have requested clarification.

Yeah, forgot about the Silvermonts. Though the SMT problem does not exist
there as these beasts do not have HT AFAICT.

Thanks,

	tglx

[MODERATED] Re: [patch V6 04/14] MDS basics 4

[Andi Kleen]

On Fri, Mar 01, 2019 at 10:47:42PM +0100, speck for Thomas Gleixner wrote:
> Subject: [patch V6 04/14] x86/speculation/mds: Add BUG_MSBDS_ONLY
> From: Thomas Gleixner <tglx@linutronix.de>
> 
> This bug bit is set on CPUs which are only affected by Microarchitectural
> Store Buffer Data Sampling (MSBDS) and not by any other MDS variant.

This patch is pointless. It won't have VERW support and we don't have mitigation
for Xeon Phi because Linus rejected software sequences.

Xeon Phi will simply not be mitigated. However Xeon PHIs are not widely
used, and those that are deployed can be handled in different ways.

-Andi

[MODERATED] Re: [patch V6 05/14] MDS basics 5

[Andi Kleen]

On Fri, Mar 01, 2019 at 10:47:43PM +0100, speck for Thomas Gleixner wrote:
> From: Andi Kleen <ak@linux.intel.com>
> Subject: [patch V6 05/14] x86/kvm: Expose X86_FEATURE_MD_CLEAR to guests
> 
> X86_FEATURE_MD_CLEAR is a new CPUID bit which is set when microcode
> provides the mechanism to invoke a flush of various exploitable CPU buffers
> by invoking the VERW instruction.
> 
> Hand it through to guests so they can adjust their mitigations.
> 
> This also requires corresponding qemu changes, which are available
> separately.

This patch is not complete. You also need some variant of 

x86/speculation/mds: Handle VMENTRY clear for CPUs without l1tf

in my patch kit.

-Andi

[MODERATED] Re: [patch V6 04/14] MDS basics 4

[Linus Torvalds]

On Thu, Mar 7, 2019 at 3:56 PM speck for Andi Kleen <speck@linutronix.de> wrote:
>
> Xeon Phi will simply not be mitigated. However Xeon PHIs are not widely
> used,

Heh. Understatement of the year.

>  and those that are deployed can be handled in different ways.

I don't think anybody uses them in situations that would care.

The main target was HPC, I think.

So I think the "handled in different ways" ends up being "ignored", I suspect.

                     Linus

Re: [patch V6 05/14] MDS basics 5

[Thomas Gleixner]

On Thu, 7 Mar 2019, speck for Andi Kleen wrote:
> On Fri, Mar 01, 2019 at 10:47:43PM +0100, speck for Thomas Gleixner wrote:
> > From: Andi Kleen <ak@linux.intel.com>
> > Subject: [patch V6 05/14] x86/kvm: Expose X86_FEATURE_MD_CLEAR to guests
> > 
> > X86_FEATURE_MD_CLEAR is a new CPUID bit which is set when microcode
> > provides the mechanism to invoke a flush of various exploitable CPU buffers
> > by invoking the VERW instruction.
> > 
> > Hand it through to guests so they can adjust their mitigations.
> > 
> > This also requires corresponding qemu changes, which are available
> > separately.
> 
> This patch is not complete. You also need some variant of 
> 
> x86/speculation/mds: Handle VMENTRY clear for CPUs without l1tf

650b68a0622f ("x86/kvm/vmx: Add MDS protection when L1D Flush is not active")

Thanks,

	tglx

Re: Encrypted Message

[Thomas Gleixner]

On Fri, 22 Feb 2019, speck for Linus Torvalds wrote:
> On Thu, Feb 21, 2019 at 11:46 PM speck for Jon Masters
> <speck@linutronix.de> wrote:
> >
> > Dunno if it's worth documenting that using a specifically valid segment
> > is faster than a zero selector according to Intel.
> 
> It probably is worth documenting, because it's so non-intuitive.
> 
> In a sane world, Intel would have realized that
> 
>  (a) nobody uses verw for anything else
> 
>  (b) a zero selector doesn't need any LDT/GDT loads
> 
> and optimized for that case. Preferably allowing a register operand too.
> 
> So the fact that the verw has to have a memory op and is faster for a
> non-zero segment descriptor is all kinds of crazy.

Will add one.

> And being crazy, a comment about it is worth it, since otherwise it
> looks like _we_ are the crazy ones.

Some time ago you stated at the kernel summit, that everyone in the room is
crazy: https://quotes.yourdictionary.com/author/linus-torvalds/190350

Thanks,

	tglx

Re: Encrypted Message

[Thomas Gleixner]

Tim,

On Thu, 21 Feb 2019, speck for Tim Chen wrote:

> On 2/20/19 9:10 AM, speck for mark gross wrote:

> > However; if I'm being pedantic, the attacker not having controlability aspect
> > of your argument can apply to most aspects of the MDS vulnerability.  I think
> > that's why its name uses "data sampling".  Also, I need to ask the chip heads
> > about if this list of NMI's is complete and can be expected to stay that way
> > across processor and platfrom generations.

> I don't think any of the code paths listed touches any user data.  So
> even if an attacker have some means to control NMI, he won't get any
> useful data.

Can you please stop to tout this 'user data' mantra?

It's a completely unspecified term. Several people have asked what it
means, the answer until today is deafening silence.

Same applies for 'useful data'. What's useful data? That largely depends on
what the attacker is after.

Engineering 101:

   Correctness first

   Definititons first

not

   Performance first

   Unspecified assumptions and buzzwords first

The whole mess we are forced to deal with originates from the latter two.

Thanks,

	tglx

Encrypted Message

[zzoru]

[-- Attachment #1: PGP/MIME version identification --]
[-- Type: application/pgp-encrypted, Size: 11 bytes --]

[-- Attachment #2: OpenPGP encrypted message --]
[-- Type: application/octet-stream, Size: 30628 bytes --]

-----BEGIN PGP MESSAGE-----

hQIMAysDYYUGZ9ybAQ/9Ggr+B3HyynNW9DSvVnwrKEZ/dTrfiZw2ip9B0DvaxjbT
mi0HoTxCoB/Pmkwavh3cn2kii6YwYvmG/pbMuld8dNa/MjbR9R54QTBoImgxdIxC
fU0EbqOPfDjFLJSnDJI1ZU+UswH0Zc9cN5zazPui9i8H3oLGQlZ1/Mu9HpyB7aCu
mEUaE+wf8XjRd8kr4ROW6MzvZY4mHrs3C5WTtp98h4CrTAI5aOGHrS9ltuCOWqE/
HvV/lodvzNBsw5X5/PzoDFvJjxySA8cTL0HFrbN5eSUOE6F+D9kBGt6IqwdulZeF
bztiEGroyv/jGfy6QcLOnGXoOhtGI2aGQL6ObpDMuTfTsuVsQdfcFLewk1FQC9Lx
uzBdU+cHo7SeQKXcp1007+9dIxBPOafiOjAVWxnrpirVkyKp1CIkH15ftDPf1eS/
fKk+S/85xmrkA+1luriGukQFmsOljRy+UTtEVBDqdfu44pYejjwa0uK/vZfdlVlt
zfgKq82lYgixHwy6IkoxGaQboRTk3ktU3xU+udVCP9rUIovnytSDTuNbAFztt05Y
b18GTABAnPUIaCSelytV8Lbi5MyRrVyQdPRcoREmmDb4s7pKG/KaUkPtri9eMzCS
21UoE+nesFGZ3/J3IgRBx08QTrzhszEmghgS6lq+I525+npwvedolDg5t/BGvEqF
AQwDL4BE2AK0I9kBB/0eKoxX4zrjrFcn+G1c3OYOqEwK+aaZf8OafeIXSSZr0UYe
plQ5dncjuCsES8veaOhKBVda/oXdfvUx3chJWYU9hJkDV5xZpEWJT+B+aaHbyQNY
uMpN0lVuGPfRwfagLv3MZtA8vzGqnVtWOZnzMyMnEcLHO7Zs7spLzB64NEmpTR+g
oA2Ay9g8ZwaSXRLtWvkMZIHBvmSNDdxvSghnh4/rWLDgmX1QH659ihJd/GXAdtn3
LBNnTQbIyJ0mNDS59GAkk+IJKzJjywIop9U7h7QD3SVlsag4ewNEyT6wx2+ua/UF
4+5JlrL1hA0axYgPRnFkQCBFZIj0B4u04Jgy3/m40u0BOOt2+RmdifO552c1J+F0
W+gUULN4dvgfP5nYFNYwhZn050mQCBQ6MF8qGkt7xDCQsfj7zP4w0MnA3T/yNzwo
/y8MrC7NVY9K6XzWpIs2VgAbMZJj7e9OQPmbv1XgbR0wkd5pwICvS1PX8pikCddb
oMjf/9OAHt6fOy7UvzhYviaRi+3SfCydBDkSdoNyOrRhwAPQ2M5hAKhOBn3q4k6m
kEIsMHpH0lsmep6tyKrmhf1zWFQUKwtpGOMdAsaIkQXMSHBWSdVtWfaknWbcIVuC
ptLok81q6W3xkad85PHi2KphJMpqXCSGgWex49NP2vcLdrDZUkrhq+3TcN8tRIY/
5zOGXqYE3T7uqcHTyIOQobT+Ik+xqEYtUFL6Sxgam0jR8T8eD/ntLPre/OFOKD7p
iyhSx245vOxMKnv3KbkAtVW/i44ZAlIzq5AfbISgvFYMvyNeCrVu1ItIliHZTqkv
8OBT/h2XW/w3DdMU4/AlrhMKD55PniolOlrZtfkdm4q5MryygrIh+d5AQHn+g9gc
hlb9/2/+nnHIVP2AcokmYPkWNfaKIHUUvTUDqsofEtwUok2vklK5uOqVgInJX77f
U/hXw4st315QvcsZuf4Cb4cqYGG4ljld6V/GRaUJ+8hpCaSe25IzEJBhr33wNJZA
bb/32i1yES7eb6QrLkahvsU2vik9SFQ0V1ILHiYfhVlmWqumcA5rPlywB0OLkjXD
Nf7oQPLI3kk/s0g8UQDz9uA8ls9wg+/quNBaNcXO4nyWXiSe+wjnBoHMy0hs4SMB
1KqTMEGoqSuCpfXNWiztGEj7gl46s8RGih/FwPdyqjVV/bm/qzi4cpHefx+liuUa
dmjgh/og8+xOfJkEE7TD17S6RYW1bPQEekTb+mPUmYQpi4fW1F3oVmQ4PAeAz1x7
3JAsWGcVeF7YaofgATvHeXGsP5ZUHvWBWbBC3wJxgztmO+ibO9qdJRvMJRuqTSvA
t7SSyXvHDcI/mcDjNJmVCSBsnJEPR8uffC2L47rHeFUHGIKjYUdWAeGVvZs4supo
jtEo4n1ZbtQ96VSGdqqN56+qLPWvBDInbkeSu+6we7WLjK5H1EOqR7AZh5SLktyR
0wVT6B6jN0JsNLbBT3C8NNoqz7vIjT27+LG8YBo/18IBS5V7egR57p463hNF0Qbx
vgj7plLgtwvsRTcCsgJWqrNzdbsk10BkpwujYtz4kuRkNXhMDIETLxqAk2s9QcRZ
Qmgo0j+YDBtfs70bsWP5YcEEpy1ekJyWSTMTw9lG704xJ9tySTtJHblLRxAH6Nd8
O41kPDFXCLFgLeetkhtYagVW/wFekRNVAIgJRA+MtAqIb4BWdmcDvM5jXPbEumsR
WNPCEQxUfQwAwwJJ7OkOV+6gjCOovCQoWwB/JbQNn25M6fyNVHBEiC/VokftPRF6
MuY5asb0ubMY+8bDkqjsUxkxF/VGmIiXldjX5VmBtnQeaTFyLI7JosO9lEkFaIN1
GiDPjdg1rvmdFuWS5qRq/oS7E4UbZ7jaeXzDjkPpM2iC+9CNDZJQ7LOAna9aJ/KT
LLTT0Qi4xaNGi8SCjX78PGu4uYUJImPbxRsHC6xRRHRZGrdDY/egG/i3/9v47opz
IGC/AyIlFXpFAMm/qaqvyiawP/o921BgUHBc4tRvH9Ut2SGHyCPEPoCauwHNLDUD
2XJTLoizaxesl/ZaOznOO+UeWX2syjQxIP+p4zKX2RIgkGmul3CeQZCmLlhB2tGb
BlEjHhPj5CqjF89wNn0raMQYd2Vae4jjkwynv2dILyuTTe6UgjEZBPgmObW8idWT
Ye3mbTUFruePFyZStQqomhnmNhVrIy9yytreTcraOYwt4UZ2FbbhERcwJtfBZ6xL
vBO00otqCnSVb5RT+a7juwHKHYlghs01n1OVqY0dN79NTxRJSbZUsW0bBJgHtTB0
e+N/ZPvFbUMeO4IIHw/EAY/uueHdex2zEhsPhDJZyLETGEVD9ak0ELsXU+DxuOH1
UNXKv1+oqUPJy/dHG3gX8bnOMzw8YBfYocxDByZnxkorQbA9iTzF9VC66kGvv6Ae
YsyQkfnXTP9R6zrK3SaULQJrfOVh0Q1yHv63XjDr4p8VqnYByLundElJOOUp0hhD
nzfwVz7V7sTSuqp3Dfob5/JGKw58o6bscWAGfmC6P33pmf4PrBhnmd6kHPgJ7Hro
jX5FF4kOgwDwXJLVjaQ6dg9yg7JGJdIkW92nT90+1ysCDimShC9dQovykSYQJS4f
guA2nEpnHqQWjTAcCDt+h0XwJMU6rT15BU0tG5UIvhzsqrRa9l/Yh4VahIt63/vw
RsC+oWr34PJ74MhhLAAYtjkpTBJ4qzoypCEdXKDdj8B6vg1A2oZsX0CvC4wI77Fc
+To5RwDCHx012Y4GJRRQaZarPXUkJaruee28pzR0JTMO5aYo2jTqqOHpnPmGcTXC
m8ImiFa3nnQNIWS43bepNmC441Q679cGU1s1l0s3MLMiC8odtjpguVR/gthJ7GI5
diEFl4f8t/7YiYmfLzipQKBZHAjuEtfY+SQNKRj+mZb9FAY84K1e3J6sV3ZAwzeU
vZxQ8yALrz2PURodGxFf7WQ3TJxWS01+hkwztCu3yeEhtviWppj88ex86qQeNF2B
WAVS1qb6GljyFvwROnLUPhC2yAQjYcgfGNMO2/eslISlSYZ2P0ti5I5pz1W3aFU6
MU4r7lqOejacBp0/L8W8TZUasYpg9F6fh9yiNQKrBv8BZCeUKLmwqS/i4+VX2oEz
Yx2pNqvbozKyz8t0tF1gPMsSBJANsLjt7aH47BOOk86qmUqY9w8NyY3O2qnYzGZ4
1X8z4CiEn9BEFXouVmmKUea1w7QD6TOyP7Gp2IZJlD98fdJ1qlNLnWT8DEvciF6V
pW//jbGvMcyAZQjqHD8gdDaqJtMaPQAo6sN1jC5l7NNppeZBWZt92EQk0ooZ2+ts
AQrAyL5BJRe+xUgo2g037g9PxWPeb782KE9gs+rdt+Al5gyA3+L7zUlXQBvrJ+MV
FwldoapzpjGk3KtDlzBBeNP1IU0RYZJKgnWIVLdv3Mx/CkZJbFvUVFE6x5RDBgvh
oAIw9f0ujfIpWZwh0Q+noY/HoxJvme/g+RStgaYxI7Fx4fFZW1L7/wZw23+bFr4h
W0n+EV6LtQkGo7GFkzOXgSOpXAAbpQSIKAcrr9Dtzc3SPlpqaTZ9P4L/7wexdAPz
sVcfhfORR4WwL9i+C6IWCcbvYTglhoTQzqDOHyNtmsWdX5RrYEGDmfd6u3l2yopR
RWFe+dmyhzMHcDUI+ckJHZo/rGXtDA5ctnAi7N1hIrJLGiVBiscrrBg4PFNjbxNR
udAF612X6PAWsQAbmF3PGlmdVD+S8jOh4yoGmqLdNaKg4PpzcibrCmZBJE051VHp
LwnQIget1aW16sHHFLw0pr7gjyqic26foBCKivl8iw13zHjNQHRum6MAo51t1G3q
7ZL0uY6sF5sxyXmXUv0xYGhObV9E+4oZOcvyVnrZMU23o6yM4ys1gA2kNXXHH7RN
8Frn3RqBaO3HApvgLjv3leB9clIHQz3kPd+KJN5AxniSv4jryPRzsYRyICTKjngi
rTDC5GXqwxTr2GTibupRWSa+hM9B3MHuXKv9stEjZ2mwqDjsATVu0Itt8k7nN+1g
UgoK+JmhxYUo9c4gNzxJwdU6MwfqhQKBTNkWsNH9biBmMa/ctJuQt1BPYx6IuBvk
cCWJ18XAU904sVrkafL629ETyOHTw4x4Si06hMYcFweTv9VnjETbQuKF97pU5/hr
D8bSEmTaIUfd03jJiTq+noTBMTKYzVI16jDdvcksXp+0it4bG6gZuyHCcjCHKfuS
EArG08Gyoz9lsOzRyiqZCSkmhL1Hv8EvbOHeVlWAYjr+jXBIv/Kf3LeCxC218IQ5
n8vKEGPcO1bpP+lp67DfxFjKsNm5pUn8t/vJzqU/tHPVJGjneA7TkjotELMQKPMF
b/29WJyeqAoJGUn7JzXWxorKlqCoEcjqLDFbq+aFZkCRwQ2/eKdqN4TMvKqYDD0z
4m9j0cLsKy1cG+7C58N9To1wa0k42815uAo5eU7OSzU4AxNUlVQiO8mjjXnezGps
sAnEm3RsDmQOMzE5SBLSGQCzC8mRlfe+FRWmsV7bD0EXP284Vrh8pUEnuu9t3Hd9
/YcTM7HpAeZly06CTyniVldPo+qdLSY3zQjLb/zoWyzPetEmiyUtqAvax4rRS8uw
W3/Ebe5J87BT6GklyUgMGgL6SIdoW3i7w4vFmx0J92B2fwfjgaN1HpD6nYYXI/o6
FeUVKKxpo3XwoSUKctpINiq4Aey9vJObCD/f/gV5amlfwS0ZdKEEp93VTaiX0/aP
VG4OnzA9HFrfguYrZC9no1Uvq/wDsutvMkfI0Lmh2XCMp4NgxYOFBg+kqK02se9G
zIIs4PzJihXPGIqe3gC/ItVB6gWzS7/sPy46BDgkwLiArh2U5uQzMLnhJqZyTt84
QWnlSBKSMbc+n5aua/Zts6ssEg47zAykdUX3W0q2Ud9brT3Bb5dXgHSvI42xLu6G
QSvYKJWMe2OeAHEW6kv6NKCukOEEI6izw7SivKJcKg6km2alY5XUqrKgDBHVW2+6
vq3+adsflESNJ9CQnUlmsEeuI2EumYwo62Hcgy4uZinaOjkMrn9IPHekrpgX139u
wBpg7zPKBsTB/A7hlZ+a243GPxsmRzl2s3HLbJ+TPLe2y8XupgACIK6oYTqUgT1h
NLatKVHWWSOwmezrFwG3vxgq8q5VNGPoRkV4zWVyphqPi1OBmn/RK1Lw8fCN1/Tj
mBfJOugUypezGax+2V2Jwn6aWJKQgVuFiNe+Kxs9XtPLBlVodN//ZZBORGBk/3ye
pZVTjb6hItOWJmntD6tUlHsMOEyZ/D5VvBmPdfYRdCnG6N3J87EezQTt+Qa7ZjhQ
DHZn8YNXPBp2SY4ZI/yNbPe5RWWClU+gT9+wO4F0F8ZctazLDVf6EIsWpZHRSfhJ
wOuAnmo/RHKzsUJdgjdlWPvrRyRwsUvdDrfvpGcZivm/4ETgN7S52Nr1gdqzbQc0
gLahASIj/N/inj7iu0JsZcQ1xN2wNdjc/dLae1XZ1ldZx7LZkOfL3+CvU8naHJ5S
pu3L3m5GdTiK1OfSKOBWYuRDkNl/nuKfSrMAi3MXR1eenSWnwc9QgdEOKyNrhWa+
LQ1faQu0SgNlQnYEejzESBzPbT4B+lrx3w14O1zQ5I2f/ruKhZnu/uGIof911szR
G1BOsjMOwD9F3Q12uqHYiKYh5VXZhon93nmLo7UWaNI31VE6Wl8PS0zGVKSi4yaN
+8WhxZB2u6SBUyQMd025vjc/+bumBp+g/fgmFrWzWXx97GlH762wZZuVEv5u9mrS
scf3zHYC+mOgMZNOiE/KG42PEpJ6ZKC8H9IyojCGobufLt2lhCbQB4RTqOTYcn/8
apKWWHNGxHYtuHfGc9lGRMFDK/Hw+GaNlQpRAv85ZSK8uWHI0KaSOZIqx5gjOfiJ
5mxPJYkxoMOaB+nHb1eUOBWJt9XPVg8q5MbZgQVTKRFMgsH3aDtwEpM406fVNatQ
sKLEJ4EKbD/Mwwl6XX299uMXya9LZA/UhT1CE+NgFwG0qbwQam+Zr+hzHQuGng78
6sf3+hh7Ey9O1hfuXOQXaCclDedFNpkTHMk0tZYoPA63w4lH4nSHa9NXAW8QuZIL
9ISUt5sT59S325fjByaBnuPLZn0Hc6t8UtAae9upaCI9TqljXdzgyqQBWrLAYbaj
RoHDUM050ldhFpYjHAnPUuo5D0tT8XtrJyHVI59N4NyiaUkDpfEOkVSEIyhp7SMn
Rd4zh2LfGd7VaoSJS1aQ5V2ZfVN8GDvg48yn6q9XgaJOgSU/HDUKtsw+ye6LPUUx
8rmuFfmIggZqwauPFphRjR4QFM9//YLCBtnkz8yLsxe9e8TUq37844jWQJykzfqY
mY2eroR5iOYSsGW8z5k3z+tmqQpeEXLTHy4Nul49igEJswOGaT1M8826I/2rxOHs
fYEG6p12nUBhrsiyEVVIgJK+zQmEWpTIsovMQEBZQGfRuJefurfxu9VRzUFu0tEY
FjyZWzWvKtX3zOaviMeXsZR3ED9zYsQya+MVVcnqZb4CFKpUCIYHedrATUOM/gOG
VINHKTDJwJ3awn6RUJAKgQvFD+Lp8PxIlfX8dDy7/ZIVEtMGt6AUMc+q8LRbdqgU
7UMk2D7+p1EwYPyOWWWKVRx0aSWYjFPxPg/QJDE0fwDUEwly2xROjpfFa+KoJBnz
b3ezivQqrRoBQY6qBVdCw3v0WQ9zz/qwkZh3XLx5UeHMUQKFq8IMHE0snNOpcJPC
aUKVt9owO8PRbLYvhylUKxBz0BZq7BFAh9bjr+XJEzYK6TCyRL2Z6wOi1AklMv+1
+BlCn1PyTrBWVeDn9ERyRg+Wuqa+zcY6OPf2pfItQ9axHIYWYHW02TmNZyRa6Otr
+J93g1HW/je9mwxLPKiCA2HrNGJBqsnpdOWHggw+MYqVwkS8YWDymajnwsLvvxQU
2yqdzIJgPfACTM80a8lkR1bhV0yk00GZxL8d43p0ZgCJdfVd6y3gAxLAX5Ha/58P
qqT+qkXh62noCXAD5IhO07GVRfLg3tTYC6ivhmkMeJSKxx9GHCcwrsxayQi2ThRD
iELP/lrz2llplNMsiMkSjPsniW3BCmxbtmtrIRV1c5jm1p7lljdmqgakQbzkt7Mq
j63a70SuomhhLPWOwg6K7otOfWkW3NTcEhrTUWQmBR36JZmkQa4CD95dN9wWzguW
eU86Sl4j5wJNHc/RxAQu5I0BbIsgCTYa7M2KCOfkLTNFjZ8msefzcCZTsapV415H
Iq1f+bNOOoXKVrztSXqifUTbrGRA5K81HemhfHkx+PGncBbEYxktfka/dT6jHeFd
Olh2gLemaXgjSNidWKzK7G4QTWlTtcFqJntkjNWkv1POj5FJ09qjXUp2Yx8zNbRC
ffp8OD/7WmuN3jSsz2/vcrbcvM+so19wrV5OMhBGdMT8Qhvj+hN90Nh2O1fNO6rp
K391BZyoBsMqFoXXbCLJUK5Z85gC5xRfTY+2k15U+gX0Rpk9XTfxG5GuDqIMgimR
P0vkKTd61120wF+jd46BTjWO4p7BsZFwVj5SFS/vv1TG+ZOIAi1wg5F21DvoZOT+
T6Qy6iTCmS3KsbFfx9A0yywhsSsOGso4tWHUrAQLrtSAQKLbWAfcnoW3KTQ6ealj
q5Lq5t+AYYT2wM7bsUVgHflYlcLUDrS+F/qMdf0wrHJ9zAb3OZuXnR+lXtBYbYYV
P/pj4DC4GvNUj95nxMifNAqFUg41QwJxDWzZVFqe2vuZpOAmvMFGaWNeO/9j5RNY
qmvEf9WcW/Y6aPu0727F+gW51rxIL9QgOA6dYjORZqMwpwV/n0B7V9/ITfG3HyMS
PqQSTNT4uX+7Zg0x27okTWE5xtIUVA4bM/S1Mb3IkID3bmfoD1Wek9hFUp+Yzjon
Iksv2okxWnWwWiHntYhDZ+HGSmLVK6UHH3X0T+UoyFgjuM1nJVp7X76KfkJuNw00
PMOkkSo3D1HexnqcI2aod6gTsV8xzp9m8p4OJnLjW+u6pf4fGeAaodevvYYnd1wz
lHkRIpbM5GbyaZchD/7wEgRAHWV7N3deROJPVCTA3Qr+zmly8M27KEqrgbUgc6Da
hZqeZ3W87EdnVZm+JP/hHyrDOkZLaRuwW3Sy0FQKm3gX8NLSjFxaqlqyJDTWXtJM
8Vt0+5UJleC2VQxf8HpCYLwbZtSqrs8f1LKhy4rYGWksDokxgDGxrCNgGW0ajbB3
aif+mIbmjvQyLLGEXy8Sy3P8GiJ7Uv1tbiF+/1LOQJGQktAafrmg8bA10hfCkey5
9egJhzZroeJKr8qdwWKf84+ZNzd7bTEpxpphi2/KLIeDmz5uPLPoH3Qnl9rkuIX/
9XakzvEzmxYZineI+6mIcAOzgg+T8y1wJtKhggjmOMUAqWqwHZiFYKNKkv7Kp6IW
ovszX/DVolWOazeAvvBDzM2xXuJO/TPS2BdoO1UPUlEsiLxVek0HrX47lsWPA5fB
20dxUqsjCEMS8ROanNHBZJCVRvdeGC4L1a3vmdmwfkn/9LasONKIXXMtADsQHWaS
TTY6lmdXBeAcs+IT6fcge8NNXp1sbcOohwQciduKsfWr9NKjOFg2/U5jQBFT5/V+
KlbJzHk4ZkLvEcq0vCrclEJx0BF6YmeGhRiE+0HKwcsVUmlK1peJ6lX4g1vVOvgR
aTa0cmsGHAWGoijCjaKdiUUfzBtTEA/01tNZhMnqXEYkRDsPwUv3cltbD9QU0N3t
I7ElFOuSKSjeIDb5TemC9qpIuHxaUPJE/+5wwkvk0e17Puem/6CSGC/8pMUVlp5M
TtNXaBhHwc+sOeotwwVDigovzJdmyAIs3nt/PHfoZOIOcb5LD3sFYBm4ygQsXUJq
r0WdZRB7FAUnu7zr8aT5QKn52fJrI/bXLUFTT6gAjIX+95Jhy34IRBo5Db9P/gWx
I1ILDrv2NT/X9lLyORaTkINPnmaR9cW0p7VQATcZv/8kwhOtRToSN00P4UnlS2TT
SxyjVhsm5KeRptrvIS4uFVBpNFyUFaB/VNW4pzkpkBv+Ks6HWPdWGR2eyvJQQZ+l
YGJ6nH/Sccf4bSMdfvPZZktJvQHztEVcPgv/G2Td/ej3DOjNc/MYX7oB2RUxRsut
eCyxh8BKgQyURJr67Z5tmDHsXACpBeGqaDOwAo4z5KEOcRsl+Y9qQTEBVphVZiL+
Z5hubXp1O+kbPLQET4x8dTo5XL4GoY0Wf5IkXZwfTjNA1e18Cvw7Brdbn+mhtuOg
GJIwG50ytwwE4szbgDIIkVsWpiY/K2nil69Vt9/7NcgdVYPzk3i2BHmsclm07U+q
hi8dwXa2nbE4HdUJ5obfVwHDA4Rg8J6E1snKZg7yq7njOV206n0ZVtH/vSu0PfXa
0lnA+/u3O58j77x/N2TWXI6Pes2DyEL+4Mt6RFRd3oz9RHT/QkDyuji0LfpY2UHM
FmYbF4cpWT7SbN/f4Y2JKPjnqg5g9iP+7f9H8aki+QNCADR2a7PPV2NRoXXajjDk
19reaaCgkTrBgxIlzM8+Jj2Q8NLsmatB8E4yFzqiD9reCqgy7qnpIE1Fk2BcJbSC
1EOFtuLO0Dm8R6GKT8A50X4txLD+87VKFReWBowhplsOc2KmKUy3JNqSHn/f3PXC
tjxrYuDDDka6Z5ysb/fF1hfT97ny9N5IPxW5dw8Cg6aDdIxpG5XMBo41VStYaZDK
5JQ2DS7D6E6jbe5pD4Ns0ujxbjRhORTOST2HGevZFMXNpPk09FLtZ5HegvR6UCg1
mZj/of3fzFv9H164TO94AvSxQ2Ef8T4o6IdFYXZ6nu6q74zxknFgY2Zl3p+v5YOz
gcIIM40N3Bu8sDRmJy5+JYbWHvC3/qsSvw7wSf227PfFYr6k0PJSe3C7y3ldpu+j
a6rkHzqfTAIdYulRW9mhnFVV0FYmUOOuGd8sMR+u1Vr4f+XJ9KjR7KVMcGNFTJMr
pRez106FZKM+Xl8xeVFcyukBIQzDnE1a6nDpnfIcqEJmePSMAcLAeXoxu9b3+ehD
fCbsf4IwA0TdkqFYuYI3L5fot9+nxx/ET2SOeWGvulFCmRdtUhqJFXlbIjJ1oQEf
WUQ0zQrpWhOQV9wv46MxHLd1ad3riHP1cUKlyznyvy3Brsz1EXG7goXArBQMLeuq
6U8R1OfqJHgSjNmTyYE8TPLkXjiA4RcJyZfolsJhCJzUC59K6zn4a7VeNEjDRlB0
mRcdYhUVTJkm9wjk/lRiKBbD1CUcWWErgXKfVpyIYWmuxDu3MiyXZpilfNs0UEOd
pEm4LsArX3OVMHrJkEGN0REl4PUeciYCAQI2Rq332LkdZF++USFoNpMVfBem2iBF
aeZ8bzIeKYPokKY19b2TrZ0aN93NrERJwzG9c9XO+6jMtLAuf9VOBf7FiNhLH0kS
XkGtfE3rtJbb5hZzB+lCxmiyfPT1Mgx8vwXODaqs7KyoTlSclvhY9ccR5gwOMgUf
+gLogO0xHJ1+MuVEkm8B9mayEpHXjsWu9Kkk5ER2duU9DirDz71FCBmr6ygPF+lZ
RSsJV69cFNX+A5GVNOGfoVL/LWlNVgTWAru65Q12V4XYs1WOuvqbvY64opeEXTFI
DEE6XMsfyobKSBSBOd5V2ozXdyqRiY1bbcqGRHD4KkcY+KxZ48hG4P1C/IiUYzlp
pOYmyl+x7bUkZiJCPbZ1XjRRKpZtxCvNQKDRarE7WDUm8cVT1lqLBKq1a5UZxmSo
6lEaQzNVPHzrxoaXb7zmhAGQR64FYCWsF7tW2E78C+rO0YDnRBcL3rOuu4lZNa24
/b9rrz8jf0WkUAofRQpwZyBm8BIzNsTSyRnU2HHI3hevSf4Y/FYUecfXp10dWl3x
d/3CHqhap3/xeOUV5Kws+dtv1SJTSgFtVV9v3+U+rZ2/5YbEWnUNau49m/0VdmMj
vnzJzMTAAPkt4310GaRO/t/BfMm/jZVRXvEpGh8W0CYNJrn0+pO7L0oQ1d5IfRcx
1WuePigI6N5IH7zC4MVOuwpEnhulDeVioJCrPS/n/a2vD00HB6GB0Wz46EVunXlN
0GkcYNJpfnn4V89rqKWFBP33YRWGua7II2C3pkqzzGA5NKfVNttTdhzcWGLerGby
1uLgscNij0SbomYvlpmX//ucMnke8qSL7EsSbWfIxEp49rvnl+xiUhj0VDICN2qo
LdYY7tADlZjde5GWsikJrWLUeZV9IJ+erXinhai+lfeG9rg3gycra3Ts4PhBaeuA
As5pTqRdpzCg8dgFRgV7vYk8C/AdgYTO/a/cPWtDydKcR1h0H2YA6RjdNR2rIaOR
xughCZ6Wlff9DK/fNJB5ju1cKAxzpvjBJfOKVb8g1Pn3+dpXLZ1kGBWmmiU9k3cg
0GlurzMwY0xgi/dOyIp8Ll71tBAtS00AUvI9ukkIKkuMSmBpm6Ea5ZNIBCWGwRnF
kx2afS1XYfJIqsRByMj1quNx67E/f36Z/CdbIB0771+p8231zpXBtpC9gv5ztZ0s
6fF2gm2M/q0pnhXbWxs/ETw1J+bp6FhpaB1KHT1lQPTPlpcKBWJaE2K8P559YHq1
SZBec2JFubksuMimsZRoENeMS+mAT7QYPffAh+/W3r2MapsR/cfDLbtyDXjQPG49
0b8NYQ0ewSdkihDtXhYbWGxb0nUVqNJqoXH+pet033wp0UY6a6AKtIqma5KArL0C
jElcX74gJ6U53bS9sXKXOekrLKEDo+md0gh9GUSyyhTZXR8NRnU6Nxl1eoNff3Rh
ZnqyRxLblCojp06FKyjl9nmOcXsLJJDR0d6ZgLfAaspuu+eyE6Eba+e/MrVr8kpB
r8yy54PdDbwsReHnGKyDMhoYZXciiyNE/k9LuaCjBhFS5TuTRwb4ihkt0ZdxNWQ2
cnpBtxstvllrECAdp7hfljzuONUll2UxJoKN+M9kpcuNH08qLqFuPKAH3lk2BSGw
vq9nKpE6yI8+f+pDcUxEaIVzvzKkg1b0VAtL88TReC682BRSx4qNMlznihaJjbSx
WLg3zEBTunubmkOs2gGTISYyV3OAzgB/JiQf9mukzbD9PVlpjQ9iYoFaZn73t/hi
y7N7t6VfKdncD5RpRSc4NAFAhmTR0d4rLGC/adJXRk10nvRocXtxhUqcrXpIjwvf
zGBEKEqWdsuSJLMIQzgI1J4a+VXJo5g/b+eUW8AuAGzf2JAruIq4thGE4k0rB5fT
lCrOJxx1MXyLAXA2H+2DkGSP0AhgEEjZ43eAOiflvpZ/Mh7DZRJYKZY0FjzY0cMU
eXlS77QEyLu8CDQNHEnaecHuqHuPc7jgNTjz3qHhwRPSUwIPAJd/bPzlnEYdOlRH
LEPPodoBvM082E6Yw1xiAXvXrNHKnlot1YRulKEVip8AJlgxguzs0kXGahliHgEi
F9mSnZB9TGInLQLnJRvIBSgl8AqU2B92Pf9jWTsLqKkxsS8wXJ4hSi4bCWavvEiB
gJf/xh/DctmCCJddvMSnk/c3e513qLbBmma96jPgyPmhlgC9WOgZDStDNctwpuTS
M8jdnNUr38uC3Ie3TF3unzJadmiIQxPvtS7YPANjugFZnUuMLfCD082o96MI+MsQ
UbPH9tcU4OJT8yOdnt4Rv9/dou1czv4DnsM0tz5CQkLxbsAjxtii6PLPSIZ9mVMv
jfYQ26tY1PvxUQdmt7cGcsxmYrEYwoJ2l0C8Qs/jElyRKToAqyq45uyUFMhSf8dl
QAMH0hjc+eXyyeWljnUT/exxNhfEfmUPmRNZVgukI5q9srw2GXVRIkFu66+l1knN
Q2v5hcNtb6aEu95QlJH4tmDktXX9MC+RP4xHQ8QCTm9VUmPj40c+vtQ1rqRQcBtI
AggvIdab6kmeGAUm57Xxs9vnTCfq7HK89XSW+EarXeyam0zo5E1AcMmmGX4hOQj3
HBXfdVT62NspBrzkGJDH8ZUHjYN1d9MYqWcx/31Xoa9vcM5wC+k4U4Gz2PCNm8OW
nSWBOyEIfMYZ7iUCFOrEFrELFpjUmYsFqr7b2AMcmk1o3leUZFbe4GL3+lvzk552
pv28MVrYILwIm1ha3IuRmJzQkgrA0+Y2sbaPtZjQm/Kct3qqu0Vegs4Ipgj/NIaA
Zu7mXJQQfC0Ara8BWutHYZNOywWw8GucrnKGwDU5/wfB7SrAkWohzZujZiIS4ka7
IvJ1aP/E+1BDo+vUSKNYox+z4nL+4pPzweGc6GqkJLZHtKlKffN/4k6zxO+eqXfh
pcCHuH+TOdD6GpyCaayElhse4reK+ZweiKRwEt2jvXcdj0bbsm6f8uj7ZWmdowe6
m1JSKT6IA317ps2JAJSOWl8Zb3I4pmIqU4sYlXtFXxyhgjE8f222TDcvx4wkCmTj
roItluSqR5pnyi+Aq1gJhi4L8hsdAN0MaGAa7H5F2I1CCMTGZJ4k1PbF5OXhjxAp
3zUBjNMFOC0ZpV0lz+LfJOpTdJkDGTT0uosaJrJba1PT8QUcOwvB2S7MAqyOTgt9
ahG/zFrHNry6svMPZQcNfYckDyvc+oZYpMwW96ED5ESnCAvML6UhqCODnEIp3ghC
fJ33I586o5Rspp7WEcTDOoV9dYywiqRU3txXyagPqAk8E44GAKSBcMB/qiqlML13
wSJ6gbSwRtTiq9uJQyIhHID7OJdqv4mUrVnmiH+3uPuGpZtZGigmDkdBM8R84kEZ
spk81VXZF2nrn9NXNKsBGUmE0DCD2HTujNnAiAKZTOrFEzJUitKilJaywjd5D9JQ
fB4KoYpCta5YgaS7FpxFJJmakef3c92q9+POKXVzWNZiCXtHvPhrFNzJWrKlrSRs
OUuqE2pH4SbANtUBYrf23cjk6GNB5ZH/obx+qcbEnFbPlG7FCdvCghNv+Z7UcZq5
hMALgHaz+IZUeOW4pSOSuehbCpFMorz4d5b0In8fFYWMbuhSqi8hRIRP+EhLYOiV
58LVpl5eVYlGss952h3pD/vV65w9ES/Sriu/E4VEgR+fW5TG9r9nghGpd5PAQmNf
O1j5z/TvBNGBtWkwpUlKzj2CtNapzUc+oASnmgi/Gb4a+XPzMF7ZRiyIncqpHlkG
1i+fEyUBmYbTTiMevVnte/98IzWkwMQzZZieTMY0fpznAyuc4dqXUAeMjsuvXKPO
q00sR0juYstuqG7LsN8N8SFXSAcKywiaCHPq+Gr1q5q/GOtBGMi/N46rA1v5Razs
HTRu5M0hV/9XAHwu3GdlyCuevhdLHt+nKYFVKcG0bMnUWBVZLLefDfpxsM2QQjfQ
K4ptlVlxNXK2nQtFHqb7omOautJtzz3kWQB1I+pLXvf9nd0j+6Z8xjEmUuI+Hqk7
CtAEdeUQfu60iYfRT/o5hTGgjDcjrRMXBQ/UdDl7k9YkK79wm94yWI+hGQFJRVX6
K8Pf6oEFBYeT75MJDI1cda35ibtYFL28hJS2jValvUNomcJkcdP/6/Mlx9tqmdP/
m3OmXf22KQjttY0N27unyJcCvtrQUxexAouuNYDblXAAbBUXraBfDWPV+7wV20te
vGdMZvPUCKS/DH7vggZMLPOwn+0H9SPeO6TMO9C1qyZ5syiouZFaSHbVLNjJ7wa7
NfaMrUO5zjv02Kw+75cJw4Pt678OKBo/jB/MkQ88q9AAip4T9G6ExU9TkqlFT5Cd
S/oSgTwvvCCGjOtqF1WxSTEbgdch1PGBP8CB52aIAJL1rFyP89FCift82SG2t2Xn
LARmjzO8od4jqKsnQG8bK0olmjxm0A2a2OsfvPUZkPlls9YppGtcW+p8XAZaj7cl
3jXX8I9B1lnmvQ62E7y8Swr3tHSaurBVDsgGSYNSfS0U0LsgxuzM9wWR/f+TR0kG
lx3TkI2BgMoHSSXoOEWxf9TIKBeH7g6FYaCNheWmcLlHhGlvd+bUmQ/a7ykT1sUY
bCQYWMdOvsvVSGGAF2quyTS4WbobG0Cn8ogho7Jng+ROieoCb1A/Nky89z1PTqZS
yu+lTzbPmZevWs1cLNjtkiAX2Dn6wapz+q1JaGzbaD+GCaZD7Z4iC9pc/Dxd6QH6
HESzfvJOgNOgCAkqYBD4fAov2tC5vb2b3SJqfa5/oATDXe3eQqlkqiRWXOy/aRZA
qreAUsfFvrVdahk6FYfqB3KiOkEeB2U9/QpXbDq3Qn4qKeK1xqvDRa7lo/lQkh7Q
t0D3Vq/L1fZyYy6QSSzXGmDBF0orZMSMp9ABLSopYUQ5sUwW9QnSq6H2nvucDDEN
KUz6c+BI3X0IoUrOmoyGM4Zw98fzvEYHmrvTjelitf8HC53r2EkAgLtt9iZngPFW
kXAAfnAliRkyLfsRjOKuXaA9MSluFSzkKhIrzuTCNJDYRQKaAdadwpM0uy37rM1g
TyZAh380vCjFVSl7hQrAyEwPwpyym2M/ZTpiOuM56h/akG7xE1Gqi87NegJBiK9p
q2YzEt0BCB4g/ONeeHPRPJqzVWeLZDMYxRR6u9gOPgKHeQiT1m2OpdIOgomFAwOQ
ovkuCfQYWB1yTA1imM5mqam/WDYrVtAYvrj4wdPuhrU/I35G/FPk465cp2jVteoh
8svrH6elErLRLJAdU72UwrNCSNJhywar6XbF44V8cdYOxKLpOd6G/j2L+EYZq9WG
ZVwXDIVXcCRbJ6xm8cq35HpdWrf7uj/Q6u+SBdFaXtJlkZUR+ZxTZ3K3c1D0S7sD
rQxQ1YdgZZEREAe+2GoW0Hk85uAh0/aa8GIiyeW3C0Q+GKJehG99VHa8X+iRRqe1
2sB2f/9Ab5h8ikPUrd4wgKT4iQdF3MIHkevKKYT8VFI2IcuLuP6HrwR3vKf2GVVH
qf0mxl/KRb19OkymT5lVelsILq572x3cy4Atu9GidMWbUv3fTvCjX6WF4AtsceDN
dzhNSrxiBU0ulSA3j7siNsctbqnJ1XV0CQpVCAyUtQFtaN+VOYhbb41tjr6PrBFr
+IrmqKXet0Ne0fbrAtBh1gZwsAIkq9ePUFi1yN+R0GokDR+2uTPBkY+eIJOqCbKq
hyBlZiGS4y02gZDklZqmOqBY2JL/WEmBsZsxFFcyeq2M2g3hBcMGm1TYi7epi2ES
lN3z5SF7gNRS7ZPLodcZ28ANjFgOgQnjIU2B6gyEj8FynWyu86TRp3Jb0y1+n6G8
5ocK3/BIQ5/IqQ7WTPOqkf26JAMYP66czN6Za0VMVfkz3BdBvkHUI2EZRHKhusY3
maB+n6iPvBAGudJiw+3toi4lVBSsNQbP3x4BoelXOFT8Qs2rXBRL80YAPQ+ozNun
mXDLX+AgeZ5m1dej5tj3i0B7W7KaiqWCb7+vCAlaO0JxEeYxi6b8MCwqpgxgKsmL
zmp+Lde2wDy+hNwF/69XBPynkN3L8hpX37R1yheFsDW6kp6s0RiYWBINd1gCWOTK
UGtuL0vxdFEa+RzoS/jx4vsAivYffXx2xUmNncJiynSsbNWxA+DBQlUXE40QvmsO
4Ekh25otUpLrYA/5OzFZJhr+TCbyiZ/wIwkDsrdNc+Ym/bBHrganQkYU6ybDMyKp
MKx54lmDB434VIFB205HT/dF+vNll9qi6BUFTbmVOWbTTXhPTNh8T0A4M56A6c85
tSfirJ7P6Z1pa5AoXM2XN8x3dFTNusyc+/O0CFgYkwPGLRPUjFYmHPb8r0ok1iD0
1WQIemJnknFH3RmbDuPiecBISyzT1UJaKSvMgnBIMfRN4zjTOgbSRYiVTeBFhvKv
5aBoaJMzab5RBbCxsNKDyOqr+rZsS7iXoQ/B585MNEHvO4wzvgh3tRX8+YIKsn6B
qgOjtspkJpyZ8YE6OZ3dWa+/3NyoFVVmPLaRUb1VzAaKLzVUStJVOYzg488BKARm
b8eww4UAHWXzTZnTMZevLZMgQ9tROdLus7jWc5N/I3d/+o0EtVe1ws/xIv7IlYw9
nODd1pwPM3OcF71WGB1OYQzbhxLNd43rpgDKUatMhRcPYU4/gQU7wHrZuno74cRa
HF/ukMZhcwJP7EHYm3Tsf8JZtj68ylHJgqecWVBP5rwrP/3jt4SyMjPsfnjQil3S
y7jHoD1IBxvEPKP63myfBlSx9H1V4YD4EPVvHhjCYH49L14V/Fu+j3voLvtDJKUV
yh/BALdynYJnSrZlOOiQ2GxBIRL27ksGKhj63/ma9QkKQjT+dy9Q3GBIplO41KFc
Zv1At75mwQ/QfH4UGoj3eGtUGEhiKu0o/9MgmwPMzI2YT+efQPd585feK8L8fdkl
UyqPRg8FQsYQ62+w4bjPIKagg/nDnaMT/W/M5hCUr2BiF6jJMNOeUY2lqq4l+IVh
WMAe6HFUOM8CUc6ehtOSxl2bY20jN56dcm08voWUUke3uGdTh31Cy0dZJV/qtXlS
zfhpoqc7Fsj9m8hatqrDflZ+NVBBz7LwfD//C/vjVzsMg8EoSSYNtucjV0t/kdUD
mPLeV0Ou3eYHBQLc3q+8VS4nJ7zqmlJEOOtvM5ZLJi/DYsldQnynhKPHVS7X9YKy
MgIvZHQlItlILSIBxukuq99iv4E7c0PhFVvxebm6xhyL7Lz3okkS2GLuGFyXfiXL
3xwTUoLD5ZPXnW60ccKi8s8GuB5ifTbreGeItxvExWvu9z0Yv2LVA1NVZ+3nPx5C
fqtVs4REaj9ESVzLvJYZ9wiPzIAWAWDE1zikIUG4cWMRc8Bcb9UKVs/W/dORddHT
OU4MZtIndJVL/j9k3XB6a04BMR8SgFHSqB2VoKZmXhA1N063WEpszb7Sx1lm+hb5
8p73w0wmzSiVGdIGE7NuwsT0pj68THxTp/3lrWbCOqFK95B7DC4j9nB4nTD3uv59
4U4idYwF/s3ZM2gtC2IrDpqMSNZU6VJgoBMbb0JnpWC2eMnU920Pm7ewCKvUBZPf
bWIPXNxVukqe6kLJ2Q0WkcU8Rg1BqZhAl/APgeuQ7ICjsFgkrSKiNxs6a1s4/d7C
zpMyOPH0xwalTJYKz2ZDBkLVjG6sKMwx54PHjoGv13PdO97r5L8RaKvMlP6NwBzq
6uX2Cf0/jsKEAz4suy9Ildoowkb7vdloASVhKwkGPoLP0fpgOVrPpN3aXb8hHTVG
MOSmUrbBPLx8KZL2YwyuI6J7vdcgjsaiYi5LyFQtEfwMDT2QBnCY97EyYfHNxl7Y
x9J1DnHq2x7KqIqcFUrGvU/C7YkygGrczbSB1zihFS/GbAYciJJI2QoZghizsSK+
CZw4SW473cKvJL0mSn/gjF5n5uhdiY8SFl0MEbZdh+tl1rZq9ZoCIH5B9vLdCQHg
2SSYRsvIkfHY0QVI/zwq836X76NYr/aq5/y6CJMyrpbD032rNXsBJxUzbL7RGi1K
bDw3G6VEx6YImfW87skkOunZ4P1yTJXNlw9u8OsSUeQYEAbPcYWyKJO/c6tFd81E
g4RJJiaad2zzWDFc3nNDmcwR6R1uBAdMwf6nbr3KYnDhdtrM2exBKxIwG0XFUzqA
YhXvYC/sf1r6ujOVioispjded2XWQgkCu+yG2J5GYUR8BR808gw9F0TUcEtsZxyG
D0zVnp1rz5TRRgYaMwyMpIN8N9AC8pgcdeWpHPZoMSDtE81kxQ6o0Rd5UYhR6c5R
32kqGwtu+nEuHVqxn1/ACRd0nX2FUu1qRNeVvbbeuAu9VTaS3umBExfL29RSX6q7
JIB3k2Zk55S8nnYJiyOD4rWpwBckqbnDVS2mSSDlQmXRQy2f5IjffqbAvPn2RZy6
yR9XFEZYGnW6AvJ4DklBXpJq3y8xCArFIxnbf/15eLYaWXpyMuFdK5VpJPejBD51
agpLaDBRSsN4ke4ybpTPhjyWbgJwtcDPpPVtrIztao+JNKc4bSWNONf3Xta+eN9K
yUUtvoqz4EULhqUbsYzSLLIomOLopcKtjQrhnIIrVyERs+sSICLU6Hb/qJUg7DTF
CXNJagwM2r/0q4Jtg39QIi6dbEe1yJeI9qLIa/TYJZpebcta2KYpulzQIb1aP2jq
BvhJ1vBkiD5kI4vZrL+TTYsRia4y5WR2liOWVsoC/XqrfQ1+eYXAelU9Qzngu2Z8
57YeQmvLljpTCv2tvGLV1LuA1Wm8LbjJ2byhmj9f/deDZoMtqILUCNvS7D6cW6bw
7ZDrDuIMDRv2+tRNvUSwgG1EOVAl+qna1My9JSg9BbfcRL0UqFxBzb6hwH0JdZow
E6gGEzAO1yu9jJFMzQpYjlfijKVBuNrQOxZpxSVr9TZfzCsW1KfHZB0knBNu+FEr
bZ2CehUbUeynjH+p7KkbmTk3lRzhSyE0Qjxb4On7R6uo0BoAF4aYW7iBs1L3/gBO
71Xnz1RQBaZ0vAuHAUTB3kABFxUZq4v3347Oig7e+V3Ii/vNq/kKs5Ir1N9dMjBW
kWb8E5JyD9FILCLqCWeOo27cxxkFQ2UmtYwEyhNHKGRH8oMXtk5wMIdhurVSMdpR
WvaHXxteVer6Gsvdvfuy+nDuJbiLJpgVn1qKpqyya0pCW7B7eBLbyWJGLousW2kj
aqXkSFNQlJOo+LF7HQmomTmb8EV1GB5fVBL3IoMbw+jHzoi1ZVXn5trhDHR6myfR
YGzn8FZ1JTF3bb+sKjWdwFHSg6AzKVyvoI8YaOvGcXxaIYz2COY5/w3KCg65hxMp
LR6mBXo4jwZKkWILWjYQ2wt7QpRA/SlJM4R7uifOKeQ/ysdVr59flyLrRRHpxk/o
nMAS/U5106/JKC2lbBZt1Mpigt/3oSjv0QV535MNmFyVKHMiHuYvBW8cd2NF/AsG
UsMIbtBXi/G0Mg6NwD/nHlkBIMthLNTQSb8G2h4OtfGKkYQ9PwrB6XibrjBG9/6P
st/MwIqJiGIA6pH+Km6aFBgPaAtnTSPBP23TRnXqvXPG27XaCfWs9EIv161YHQMM
sB+8ubiaQbVi2VB1BD9U2UnqN6QjSUREbqajSa0AvVe/Fcahe3iFYQnJERJDA9wM
VgX+ZeVx7BA8bzvB2+mci3K6m42WevbqTumEz09gSmQDGTXnLtDGY/DScN/Y1q0p
jeI3ZHaaS1MrtrumCSOWDRM73I0XcFLyGgADMhpT3ctN4v8n6NoSUhN1tO5hafH0
ZZRmWV661x0LzUWxPiEcos6ezR3UdDRSiChLKWq45N7wjUgi6mMDEWXaKO3id8HN
NRFZCozG24VhuAxHTN8Aj5oIfYjYdeKTjOhZlMC0iRsu9ZYvnBDpdUHTFwJsvnK1
lk5I5HPcfftRQLQls9rLj1dUBx0NXmjdmd0wawFZvznLryITREZhZ+7c8c7jLZPo
hGjq5UQ8ZUUPdEW/NqogRkdsEpNOTU+FaOGTLGqhfPG9R296yiR4GDU4VDp0B7bH
bVDbR1DRTisFja9deL5Zy7Nx5Gm2xPz1Z1vHHfGPJ+kERCf2s876JCgTdthGaflr
nIR7m4yRQnzF5flvJuvsXGb7OAbpS33RG+3tEOMx0G6kIFSBwMsthO+ha0YPvq0A
uMj/fVlV3S9djz/SgC89EeSOxwwYzokiRfk9TyZ4IxqmML9SzT8fAnYGDbakWabs
0AViAF7pat7jGtCI9jDqmar0Fuzk0g17n3lK+CjT9gFiow/LZmaFY1zvsqhiKi5E
o7uGBm1tZpMXo3A8D9RfIhBf3RFsTzJTcUB4jSJobJylsU4u4BC2DGTBKuUOYLVi
47r6SdktDbunnahoOzrbIQ0nm9zeZAbDtEzpqhpCjs/VAkgxbYDZKsMHYDd5dWYO
q43s1jECuNkv8WJVNR1GVqrGiICmeKeNpcmEzZxidbi4qqcUzvYOUhB8bbOSuAej
zm1EY7Lp2ihx8D3H3Ko1w9j6cCf/uv4k9PVCb8Vo3djgn88Lz76NDhRPK+Or1dNQ
rBK9aD/ID28rqxZrWOjq8JiK+5ckk7ekv5WW1a+t6IN34jSjYIyR4TGT8SAj5Xio
1O64ifXNaGruB+xpthoUcD1mCYSCalFQK8ItnxhwFor5k2gDXIg5eQzuQOnvfTc0
VqOUFjrd8osYlnq1v9bmPLBok5jJjOaSqOUOcc+xLJZxTBEbn19pQZX1shHaJYx3
gtduo3vwOmXmpv6deuxKtmeU2srgNerR0ap+RfDX+6pyoJoW6uO0BFTKRdbT2wTD
67eyVQZ90xtExF8Y/+YMJGuBjYh+5i3K3E2QTsBoRQhutOq/xxuqbzub4NhgERUh
PaX3rx69SXvLzniaeI0VkCCkaR49Y/YWY8abN69UxLR5YDTwUMJFRGHWE0agjx4m
Tf8M4zZkApSzVd9vSU4vsD1qcNptXDp140QBLMx8IDRCgmlOSP0oEyc3eFFAV/Df
ivDZNNRlOEkIchYn5wzM5Fgvz8EsCwGn1E96Cc60R6YZtZbaUODCVtPrspypUzbS
n0PGKdiRqe+PtGieoM9wqZTXNT435k6nSV/JunnvbDJxDiULr9uH3LGJG8K+ySK0
8ZWFo+0Q1fydTyNNJDV8vX9m2cPsqnSkFcW0+Wrjqw/axvgZZfsg58wfJ8d5Ldh+
/2AMkSmtOrcW8/6GmLkMgvsLMMjz2SFw8eSiN7CK/x6avJyf4qn9oUy4Z3D6gyym
24FIOC8enHDZuQVyIRBJGS6qSmtFJJBzM042DLM6DCTdQy8dzrdBoPnRkc7dcEye
CLA8N6tyvFkjevbh8vZ5VDrSuQyQniENXuZV2bzyEE6Ky9Q32h+47yDywyaGvup4
KONRHOGBd9FtckX9L1FeiHHR4bH6WALZXX/Rbf4ExpSdt1ysohhl/YkxWQaF9YYa
HNKbdRe9Blz35uhSVDfWHkvBHw4ZyqwKbLoZfqi2ZIN8F51sTd2GIalZELeji+hI
lHbvI59/zBnYQQ2oA/sPnYk1YgPsQi9QctNLoecKKvLRg6hxzDNDIBmeqlqU4uDZ
Em0/9jFPaNXathamp3YodpXZRu9lJGpahM2hWPvQM6j2Jk+RYTCfWflM82wP/J33
792gx2BTDsNybEXbDy7K6ZMJo5PxbAEYbvBkxSfDyEUfyTUpVsD37RU5Xo4+8rik
KPSVTA3jmIDuiOQbv5SW+35s1IEAlKfcNySLbL+UdGSq7DeGnY6ECdSdSLwrNpV3
/DdKqmyLlEWGrVUf2oh03b0iUeOIORlRq5/wth+8GqVKeVFG6+qyLp41oqTc6Z5d
m2PCyzMWLVQlmP3ulFAfpryLJlGMyq7Zt8wXFfdNUcxrLZ391jnjETKJj1Tt24lL
HeDsLnU9SDH+XDvu6agZnss/anJ8p9Kqv8tMKXztuJXBmEeNdTbpMfTtt1Pljlyr
slX5c1frfOHmCYeXgVK/e2f3DPTHF2RFWSmmUjCG4qz8Z+4YOg1wzyaMrvRE1x8S
nuzYyeCypRZXlvL/p/VvhwFtX3/tiri9IeAKorkDG2gF6uvsfemPhDJOCYCQ407D
Rv08AGyKBz7T145300nSIFxhm7OJ4PeUaEUjg8ez0/LnEDXFDXD30j0oaWicfA2G
+zdIoBKIwU3kC9JSd8ULskn9+2+qe/MSoF/Uv3lmcdUBsQss+ElBVi5Fkj4OtN/g
prZGxm/LaMI9WH/T+/mVifbmSnbpiu0+9vM16gSb+yRixVw38hbTLBI2TTxLhHEN
C6KRr8gexMgMqbdy8kg7kSaUPLrRw7hq6PLt30Adqf4zfnNNQRVARKQzbuMe7osJ
OLN7dWm4Mz8zgCIsS4p6TNibhc8yVSWbh7rtDhOwbgQVNTDwicB9EiUCsSrKhD99
Y0JbJsZtEqJOfkpsPSvGlBy8Ok9aFPSR1DxmPuQ63zhWXOU0lJoaJSBCnn53tc/W
iviftr1nmZ079iybDOjIidffuUSS0aXrq7ycUZSCrbawtF77tkABjzyM/uAF4cqR
We1vRdHVtO5vHqIGHmWaPR0O9Hkok1YuTtxTWNMZY5kJd7C5vCymkHIqU3C7LZj5
EQ8nzb0RaIFkS/xxe+VRcdzw6EMincZKxQD4CDqDsz5zeI1yzVhT6k/ISHeAki+z
EQ9NS2o2nS4RzK6OaDn/onqIqCQ9qJWqty25wzNE39M/+PLkrx//5P8jB2jCN1qH
rcXicd5CCkuxqTkcP2wZUim6HPefDZmGAuutec/LCvBMVAZ6jLLn+su3bgQUmzcJ
Z2Uy98KtU900MAmBqEyKj/+lXplNg4Ps8AT0K6mn+aLPmX0BWtMgUoUwESke+7VD
yWTHsaDr2rTsz+sykYYbfxSTNGGhgm6ffyt0ppdUMOpJLzFBbHFukDsi44G6gAPr
RcER8zd2jJmckf/kf/JWjOqF1y2iClE0Y6A7L42tf0c3i5QG+QtS+BQGmr0DEKe5
uORfDtSH73MLq8CcNr3fBYjNSCMBJYed9Qbv4KYUxLHEcqsf5ou+RA87alZCHDE+
bJSSfLy1AnW7akkH+Z1oXEV1N3ck7pUwG0A0T2pOYok9SPNQ4ZuhU91x9hDxixed
+jF4vHuq50VPI5ySquBuRCaT8BQVPHNKrn2X8D2RdGUaAMBsU6voJ473ZK83pWna
XZAjSgRN7xAJNrDmqma39rmzWOukmPgCkv5K6/hm202CdfMiG6xu+uUhjtDOoD3j
lTYzLdPUNK7qyVwsZ8PC/ytvPNBY3YOzTgEPpemqt9vvIyIa6gZIhuVI+eEsb10p
lKwkQPW9n3ZWUm3K0kIcADHKeNVONG20N5dj1Mb3DSOMkWiGdz7BZyOrTvd49zaw
IT3mnNhfEb0f7WuOMH1c9m0AS1XHNJ8FTS8KKuKk7oNRzrihlj/M80FxXN/PF17p
7Yw4QcEYBKyTAizPl9styfMaf801r/AW9mjpw2DNzayDnPYJYhjU4FNqT3YjBvNA
C3jhyaNQvLjfD3zZEGa1K4gWcQWX9kJGMj36QWCa9ryVxMTaF+eRMp9TsBPjnMOy
+QsGr+NkKm8DEdLzFLFx8O4Fa+pIE3Qu+HnFXJEw/nFuj8uKXz7PrRw+e0V3YqgG
ZFrdgXd+FyNlq6gCELdNbo0huz0fO9/dyyO+x4VhkamOHIn3FE1yGu7RH76UuO8E
QKQeRMwy4qDfsZzg8fC3qKNLnHSiB0eiwE+jmxuAnRxm6ysGqxbEaGz9/j6rhm8C
PgDeP/xBqlRkBhA+yOoNnTWX0Yon61AT5e622u14e4g5jmSdvfdEG4rQ+GGoVinv
8jzh+ntCE4qupqO561dx2IAG/YjhJYf187Wz0Ggu89kTVKejTy+jH8Kk+lPgGsOJ
UcE6md/tsQPGlBkrYNzzcOXtiS6MsSyTve/4z467BlL8iRdpk5MgstyTkQRzmhN6
tM2Z22rM9CUzp0QBZ9gbqfnmCCpWk/fkoWCx4HzhZFrkCjoYrcUni/MKDfcxIoGR
XI5DU0DfPAbqncGo5p6/u46/DeGYSbzlLS9KRFY62doIGzTL59Uw0gSWvioh+kRx
i4U7aiSsDwm3XL09AH1imoQePwYT/0JCVA/e+Rd+oqXkMmtTTKz3NzuVJ3U+7u06
60NjV+GVNJz0OS7ETle0keCa8U6yKzifgLvc8mwlBho3Ud3xxnkxijDCVjIIzqv4
5WsgZYqs3JMmy6li8W6qGcMoTNozKNT7hbnuc6AZu1ZKV7YkTiLIx2uMc9Qzl/4t
Bm6/Yk6raod0JHYC73TZQY+/GWQljMOilfCsg5FPT20c/D1XEWz2hK93UZnTy99y
v1DqmqVWshk/90Ic74Z8CkDjPEasHqkGuZjionTbS3CjRX5issRUx7W+663jjLH6
PT9sHhSIf1RyRxolCGbYaWOruVSajaDllxG2kfjxR/d96UWKFim3EFfJMpmjYf4N
Zoo2z0dHFrkHDTEnzb+MXpztoMVn1tjgfwDlskoDfDOtAQCzuuCTtoBZf8j7/hbj
byKqv/danjLHFGCem+xm8Mu1PimurDFjCAGmmu5YdzX1GV8016TAIldv+ia9rKar
hsraqSVU/TO2UDs9x7H5FeTSgi5N+8uszqaJIqJr1M1His8uA0Ql2+YZu8lKscoJ
XLsfStWkWvYE4gW8iLzQvr3fCbcoRh2rp6qTsjgZ8YtuZYqh+AcI7KDFxPLQ55Ra
lkGHH7qnbLXvC2cINi3QO+VhRrnm+WIjunT/qq4WDR0NUKPOP5R34J0aq+TKgeML
veEklYHu499eK+wroyPK3zaA2OQRbkq35MwkJssvzzuoR7ZcbrhK74C7kJ+IsFo/
3mP648UTrv6Hn4P7ofv7Qz0jjyfbKPW1mJQWFGQvY4HB/k4NRsfeqzlFYg6j5zAM
GVt34bmsNj2MCb5JwlO7h5oXWU6DcsQFXkZUjYq+1oNWNAiRnkb2pGhpKShle58w
Mc3abZhPBfNrzUL7i106yte3s7nkSgQqDXcs4JheDX90F3vuZ7L5HQ4gPvNZClon
sNZGs5qy0ChekOfGrcocwcI7XWK4InCjg1qf+OUDCkKhLOrfg7/fHrAiB94FW7XZ
fyHGyo+t49ahTkrbw9bJ1bEQRPE1ZkhB3f+SkFN8xEF2F171EgubUyAyJq+rlGN5
SJLB5uKEj5f9rK91R9sX/DuVr9eOuRTo2/jEEv7o2b5R31RwueBWCL2K84HFY3lh
VPqh0Be2ML2+QIupTMqwalD/x20/RV02miY91izxC3XQxCeLSBNO6SrnPMvd5zLx
D+V4GD2GpaWNPu8ATJUPrH5hqmoutS0tR3vNApMGHlFSN92MNXAZup4Gjd3iXGJw
otDnJSru91avFy4LUm7sQymcRNeog1ItbcIm6nZg2kYFH36eRb8JDHX7XvI9PJMZ
rmbVBEgqE+5GM5Z2dkf+KmkFzYiZ4ZkLbwE4cTt2s/OEQa6+qwwPytYe1nN0Vyyh
rPKm0xepk4BKprezuaRymJAJeveAL1XMzJ+2CTbz9d0q/gLKB+qb/ziDklMoYILa
wbWfSNrWx/PWANVnyFZYi+QA/Tr1NaR3Ncdw2MHTSAlLjNs2E64sXkGQvZvvrC3j
Z+DagEjfcejfS3mbr241U5SI717Tbf4NJ1xiMGXcEYMXVgOVxSLHf9syxkj22GL+
Bl0qfnLcHMVn5ybWLbuuAaGKo61MOBHBrCysBOjWRuEByZiVO984zVdrJl9Emn7D
1zP96JCC7JS1xHcT4kXXyZtaKXlvg8c+D3FQFqDlee9XtmVeYUmDwtQSIGwfq7qa
B1I8fclGMbwhn6RMiYYbMWH27NYn5KHUU2XD05w7gqfyOV7ABxXRxKenjP+gCOsx
26Nb8u6C6JrdrQnOrTd56ItkMPlAYB89bnkIW84pwcrkXn7yYeA9RV2B3RBzpUz8
RJToWTJ0H1+oLCSC/30c1vSVOLvh7iZuCtn1V9mIk1Q2FqWcUSyyUgf+lxH7bn14
6wCPPvkCsWNop7FBMrFcTZxBiWwMbxIOu/YXUaRbN2KznZJF4DIuW80zTTZYOCN9
V3uBzE7mFc/39IJ2ejQgyDmz5cF4ETUaWzqSKWnc85SCtRtJSfTvsqs14GwBh9RS
aZSj4ALQbpFNHTuUED4/CTti8kJG3UkNgdsV4M9ZVtRt/FvGEXxKaAcAzJNGaFNU
K6OfTfoDQlF8FOH43FoohQ85cznHHVoJZO5MAs4yc/CS4dQ5sEomnVG4SmkV0dgC
UAz5eNv71002AvH7lr46vDdZk9Q0Jmjz/5NDDhEmlf+flSIqqnAxVKmwm/0nUJZF
3DDjz8zGQKBmftiwjj96RplEE6olfC0Qu1lb9bbkCQXn4aRl7a9YnrgRHzBZ7Edy
oQBq0awpuKtHDy/Dh9WDa0SypHOBj5HbMlHwGUXgyVO9Qg/PGyJ0KXsl7ttatGts
libfHd6ux1jdrRCkyaQ2cisIL527mK7SnDew4HgCT41oX+Oj6yHMziM7+lCZbny4
yPekQ2nt+ymNGk/20lDBcDzSdipb5nXR4A1F6KpGLJtyROE8aGCySu7QiV0+2qhp
x9qlSv/q95ng1hzi7ghxyk8XzuiqtkO/FwhZ8VOsWCi1XB4hoh8Yzq6yb07xXTvQ
ra02b5P53pSP+fs4wyQNqKNjk3ES1KtendIebpacz9Cx0laxe9fxnvfALLhmnsqu
8gyvFGZ4eGXpVrTBZVhnAw6IxX94yh4brEPy+UvQpP4424n1LJf7fAN6t5Q95Hhf
owMFcZyybWKnG0Z77fJu+AagEQ6gFkPbPH45KxW4gduAEmuyt/+TC4F6maybCGRf
6ADrVH/7JQtPGxloE/Yl61KuIc44l2o745OFdWsXH0/Kr2upTtDT/rzhgYSjJ9D9
6zrWJSz6WIH+QGWt4rWdTxDFoYPorS3N22O3jwXgBqXM/hHdGwWy6LtZsTGqrXDd
XST2KOgdigZwfFmwtvY3GMGkH0tG7bnohC8zJWR262MfEJ1qIPUN44QGsI7uNXMd
X/3k1Ie+jxpuV6PtzkkReLByvRbols8cMkT+HyvMBwz8wqjcR7jKiMQaJS1cBUt/
ee80s2eP16dmmUKg6D3brGWrBj+MaR9Ymeh8IGskClYIHjIz9HgYUcsZnF9dpiOp
PONZMKjvonN2P8iZwnsBT+fVmsT1wZX3omFoSwMPoU6VFJJjAR3/92Ji5xQ3EtaO
dAbYvgCOItJ2CcnCFgL6K4nzYNg0tTbJy7jsQZR6puXHD0mjZk8E6U3BjRl9qL+W
O8ZcRAr58/nCcwdHRv7K6CfzGKrvFRGFUX+QtfCuCe/YEP7/4MgbUlXsu5ob1QL7
zz3Ip4dZiyY7HbOLPTsRcVYEeQ4cqFbttV4djXcY6Z9DdIjc+kQpOkhHxCFp+L+h
pujz2sLsJMipIuhFTqOJkJhAwIoKfaLnvrUGNKnFGaSFR2Uk8VccTvqbcSFStrtM
4wFyL11t0QrNT971Q5unXFud6tQZSnQ72youazzsMOp92IqcHrb6LU6MAOwPcfHu
MBnl6UK7oEjMYx396EpXQXZ1tedZXbu9xkK2YKvhcvLztVUQ1AccDhv9mZcLY8FQ
dKtL3dNBnpBYiPuB25nNqgk407wxJ7itNYNYNSJ5Pl+mMz77iJRf/20ghzKjEK96
Qmqzxuz5D5n/vE+t5SKkly3lXtL6kL7KVnKHebsLoTiPo/KAIhjVvU1ovfEBW0jZ
uC3KGoSOZ/HVZG4wWgv0vAnokWMek33FTEf/MIrVw6rAPLUCd8WFS9YWf2mHKPeu
eVxoWkfDJsE2pUBMSpHCfv28UcUtYqCVotB0Mp9k1xKLOQ/KXbGRBoRvRMfcPhi2
oC89eeBsLhzI+459W7yrvz2uHk4NmoTpsu6SxOj7XcLimyPD048806mybzyaZwDC
a9FVSp90Qa7uo2NYD7ls7quK0hrWw7oj3lVSfGrQyOKPh9NSN5lLpWWz8vs3sf2A
qM8idqLnfHRuOCKv/HuKBPxQKeNPnGgFdbIYkT3QmUJG/rBxBOaz2YPYa1cIuitU
4yeMavpWraR5G+bYA5f5g+tJemg6z9/FYb8cv/MsRRM6/7Vu7ixHuC7Cf458CN8c
ZVojc8VVMDs32puJXwHwHvFkstAkbSvuyQxbv7/6pynfWi1ASm5hNcJ9SOUMsp83
jojGM7UmDNFo/2hZ/8KoWtB/mtiHCq1cOxSVLhN6p+OYu4iekpCSbDy1z/xmXOcJ
miUB9ObBNW7xU+Nwzdw/ZtR1t8ajWrxQlJnMWnIitxQQVWZybt/r+Zglr9KY+mml
AstrePJFermgMiBFkS6Pu2Io1sn8p8Tmm94SLjVrW5BBxyZJK/fcEkwiG8LKBBzR
YhGJbCD/cek373KqxeH0UA/K5dlXkKbvIOjFOmM4ZdnF8hOFCOQjfYXRshSSFOKY
4PrxKn0Xg+8OMbLFsQz2ckZzLx3idYiaytVQ44z8hcbgi94ZWYmDpw0j0j+KJrl8
6mcNnRbkX46ECmwLX/dQC4ufks9EH7Mk/eec2LK5MqHuEPu3pnBoz+kduTjm1bDi
aHvuyuG7tFCg9MtDdDzdlM4sdhGRudKarCBd0/cimoa2C1x3AMejxVj/NvzHiZsP
J6trQEmQhiWl4ls9z+vfyeUnLwH57w6YjobHcanyNBIPLBS3yxCF6+Sn3L5PgRJa
o+eek9uXRmOl3pLa6i9l7qP+2Yk0rbxdfePIXlXxbbZUT/Licu6Kazq5c35iaw7G
m8D7lFmdHSOxfqQM4DsrZkN8/bRkgO8dlGyliZ75HHZ3li0hCNnADwc2wJVCBbJE
goYDDBBUemLXhiCC4bLjLGu5gawKPf0hEsr2UuTP+C/9PTfARgCj2p6VTRwCzWTG
kceCY1pBk900L9cnJeGR3/MUsMRfrEboWkthMKWJX4imxawhl5RwVgz3FgWLrDn5
hTXaVoSGWDXfp/Tra5cG7iWTU6A5sk73ylNrgwawiIO7ekPSzI9QgJCEG4SBQ58I
2qFwgoiXQkmn3TyKWQI5gH1QdlUSiaDy/1JjWXBsZ+JHX4HdqSjjFaoOf7Y25oGe
Ny+rWtUbqOQw85zhIdXx8NG8BPhBX2KLhsWUDFjWl83CLQd31WE6fN9Y4I4/nri9
dWDvHPiTERElGa2mwOWUx0Rq1n5kJdxcob/kHrZxhzwCxg7d0iTvDshDeuZ5wzze
4tkKLcrGHWZWV3E=
=egPf
-----END PGP MESSAGE-----

Encrypted Message

[zzoru]

[-- Attachment #1: PGP/MIME version identification --]
[-- Type: application/pgp-encrypted, Size: 11 bytes --]

[-- Attachment #2: OpenPGP encrypted message --]
[-- Type: application/octet-stream, Size: 29385 bytes --]

-----BEGIN PGP MESSAGE-----

hQIMAysDYYUGZ9ybARAAuXwsfwAY2MOwxjJp40IqxDVUGDkJy6OgNkPczXJh6s8/
Rs5mfl0n2IfO14EYT6cUuotzlyFbpbGmjE1+jr8xN2NtcVjtdRsvFsCLs0iwklOJ
vs3iPImKK2ItjW/097rGbno/9qDw2vTxZDCChHgTm3z0olZHIoRCbc6oOKJ2TVV7
yUieeJ89BAB99hsZbgzafIC2RSwek3d5z88uO2yhKb5v3vIukJFnxgV2elnTw1t6
egEGZwtPJNmrLZH1fb8i8j1/7THNkIuUT5u4nUlbzjVZFr1nPrBKTM5KXtGekkfr
TQePHxWje1hvimcUrj4a2VffnOfhoetnM6SmS1CXDbedpwQOWBQyOJgCYaKr4nDR
4/07nfo3DS831EI2zxbSvbCxf7Dl6X9827uUzOFulotLqSxrJJrQHPXaOwss3gNw
K0jrdKW8uL+294Ig3rexj57cAoNGCTeuVUuQb5RNqvNtK3cBYfIDR/6cSDcyzINh
N7D6J4V2wJExVGCFAisEFO3oTIBjajFzWcz88k6fnmJN9/aI1HlHA/a4N1o3TY9h
maEOEi0SGEJuC00BfpLcOE/7yikm70qDPW+YiNQSItAvzgWWG1JRr+zzFiHhbVgt
TL759HB4NnFxCWtn7ta6KirFWYrw9m9t8p86lGoAr61lNb+VUxNGxtfp+FXWeeWF
AQwDL4BE2AK0I9kBCACU0DizhAg6onVKWPEERev8bWaEyXdslzVTVD0PYrbIeJDo
Q2mT8SrI0CDoBIznwGlcGtOwjUEHTgYXYFjXq6b+AVLZEP4Bkr1qAOicLTApnQRX
kkSNZeRpXhdxE9k5rzNORcwgDRTsH1Lrxpb2coS7kiqvLnvFJRBDN4TYZd7jvvTK
eftGBO1AykZwOhevA0kgj1hv6uWEKuxBRX9tDxSrfdksP+VSn5vcI/01gZVu2MLM
SQlN6McMtz4t13tQnauDAnyNTdKx2KOboHiWr+i9L2OyL9eyQuLSeDzuoAwl5ay8
nzb/bDZmoamgC/SdXxs1lsTv2IgMgeRXtHPMxfZn0u0BfyZq2hktnqn2qViPh4nT
oHz2ejUE3RenS+AMUrVIH8IY3KWmEUkBpw2W7PPpPPyKZ/NEg8qYsRdC4dErP0Vo
XbGvEmTEy2FRBOGyh592F4bDqcW9brrK2wmZxkdFGHepGPifaDSsCp/2PIn9U4et
+k9iFlHtCOkpl/8CEI+tejoBL0aE9nuvcghfTjBBnV9MVE5ln1YGIANkslFdNpai
+2yZL3FUclx+iMVJnSWQ/g/149qA+676uXd5FL3QlWcX8T3sVsfxRRAoxissBYS5
YAqW4n8NX3pRsSQkgMj7B8jE/WTnSgj9otXN54tNx3TIJhPUQuduhvFeJ5BgHcc0
f2KxYwv6UyhWZQ5Hr3sjXMKIEZ3CDtLserWSCQYOfl/DEW40iO7gxSLIAXlmD0fe
jvvL1Aq/RuwRYKF2Zmlm75r3it8w6CXQdbWD4Z89eRPgJQR0sidTm8QxwZyR6mqB
dblxtv472H6nOIWc1LkhUJwvzOtgI8VqdAHTPg4Mj5x1QlN57XV3NFMSa095rGwB
pKN5CNTzEgzuUDheP+vnJiQaDDQAuR95KG6MG5qSo0L+VWKOD9ACePFwKxMEUq6q
ADQDbTtbNRerWfvfJy4DfPJku7jiayLug5qB67ymJSFjYISxb5B+Mpn/Hz+iP7U+
XPYRPJPOKsnZh375yBBwyco1zhWIH52AVZa09x2OvFE1B7gBQsLpiUEMHR5xm+fV
6diYAToKuQd+P8946FOfeKPsspEr91VI3m9SZ9dOnSnvR50Xkjl9SULzapRchSqf
46kJk+AN22kH+VM9NmA5pUWeJpIr1Z6G0Op+0sDYnyi16Ku2dPA55xdF6pCXj5rq
KtLDxAOc+DT9dc8HvqMv+gwAWLlj1uN0uCXoGzYyVdUDT8dEFq2vK++E4ZnHlDKt
YutjKHqZI46Dx+zJPi5ZYRnH2WlBBBvkfDmeo0VuTIDfVzmlA54K6dN74lOoxaWa
xQK2+SoTKELlBxLU0wvEvmPfBXtL6GOciKjw+N3Hwg1/VqLeKYl4ndlCeMn8sAhc
bWYJKNdiQo+ws9ou5jVBSSQpkQxIom70WZ/siCBZLLvYBePevohJ/bn/Epv4fhja
AAlWkeaFlfFIkaPIx+8X+k/eXIN8kfdj/XaeAVZn/1Ggq90wGnsPjsK7sLF0Lpvx
CbAv7pBXNcuyHDj0tzUd3hgXy5Qs5vQXcyvCRlY43Ivq4MN1a0W2MSl0jbDuL+li
JaemAviqVBytL+885GQY0MZYqGX0ZKMkqfcfFut1xQAikSIU9HlP5rTGulEP0j9O
IdZdIyL58kWp6YABDzYCGw3A9SCpBTZbc+Ynhe2aw4n/xMQfDSBcH0emkUo3Dnmr
EIyYsGZvRnBNAAJ9AMUiuDIaZA5/+FpX6Nobew9y99gHZDRrQi+9XxTb5g0skor9
7B3/kmKOw+WT3Nj6RcGtKxfW47GE/lFTd+ED8gfKOV2fyvxrN3N7shKFobkumWlD
MbHgiQ5FxrvISQTr2WRGDwaWjNBsF2xudcl5x9GVb5WhlQpsLp8930I8v3VcFJ29
wrbYGKjHwF3aDu6mGClG0ksXbBxVB6BlQ0jm+GG3Yf5mRfyd1y9CBcHPtq5PUIa3
bgBZD/kgAo3+76Lh/T3uzAxtUP9k3r1gXl0RLvXn7lKjQ/XmeJ1wbNwgPaQV87I5
VdW+/GZyb5UifxGvOmSzrsXhmHDcnQmxdAZ/hwiBgvBLvgRMOrXFPGJFaDEcGoOI
m7jn6uszvvJAoV15GcY9/nFfAIflse+UJLwguU6UeNX52mVTr06aMeJZ9fKlTl5D
Mex5xKrDDJD0OuUjhIA4QOpFyECh4DwYtM9f3xpSzRRFM7IGm7nJt2ulqykl0JfF
Mv82ehVpcqWl35E0dakNkrmbGg2ihEpDf8jZnKSsZi54g2YpbKRHnYUHucjuKHFb
HIavk496FVFnwH7uL7XCeDJcYRDpZQN6v6nop8PLiKf+zyeHh13rPECgNzvhXbDG
26Gr5kVQtNjW1tjpqEpOC/i7tXkdQzYVSdczGsTZXAHnSA5N19EVrVT0fBDTowyP
ibl8/FLCkjH6C8k5rZ+QLAAhO8JSJUpiomy/yX1v3Rahlb1xPo/A8lfXZ96+kCmi
CGTHX6+Ri3gmfYm/s+7Ph3PKbHkaefzfTgoPdVGoUlp9Z/5Z3Pi8wR3+9Mixrd39
nFNtUCorB1gaJ68fhmG+dUiTS021hWq+BbR7gQ4BjSSNPLlaXG+1iVSER0lHzaXJ
bI6f+G6NWdTodsXHBSbdfeQ77+byj/bXSZVuXqA7Qcyc+JkwUbtBdf+1aJPbT2eh
DFHh8bQ6XMq4uBXIRr0QadpFN7uV7IwEwLXEjdH7CTgCtZlCVjtGPMeP4yp2GEjs
9fVCdrN61Lji06d+8WZnjvAQkEt2gKlL9Cn6ztFtbLqcZBC8/1ISE0BK/BWZ2q/l
SoRQ9dRCv3fmeaf1bP4kckAXfydQcJDC39qop/JPtB0Wk891F0Z3gXulkL4iyiXY
KMd95ui07c+U1aYnxeKsF9m9UofLiMj/o5pyJf51x6lMsOgvLW0rPV6DroA5Jati
CfQYVv6h7t1UEVXf6+6mz2V9dpL24Fi93oD9DBf3ZpmQrZSulVBEf+pztAB7RCPG
eiuIQz8TfI7QDzmfFopz4Ox1K3Y095R6S//SVvD2wa8846eBofXx5dj7B1HWqcp9
j6/UjWAEAvTYyI2nIk7oAm21DWWnYuiN+TDH2ImMeTTxK5AVYjC8KC63qzFrE5gB
yRV8lCu4kuh0JdS6SyvgKHUr9wtfcGb08J+IKafQKrrkjEFfZBNuBHg+V//hmBXB
1/jQuxhufZf27biaiz7iXJtbVMcNy823yqLne+UPPepUwa2w5vkffzAyzdfipQMy
pQBwy0N1J9zw3oT0/z79TKoIUfI8f01bz3AjcaDPVetiJjuyZrToEbHVm3qLtxEV
UQkJIdXfmfEdKuhSmX58jn2oofgOHLqTIUwq7dDHDUB5U3i9TXDLnCF8GiipwuSb
wn/iGRFXKtL7mFNkLxx2lgevworIdtLwLcxXrvRn7YUl5/vygiVUeK0viCTq3HlK
DSt0NUsSOpn1VSK5FSmXUnFf5vnUfxLuLaa0SausmYPp0Gt5bbkdluOY+0uwmILs
3BCitbkVPgLpoZDzs6B5ZHF13gbMpJEb92kTFdslGKUFttzcczhJrJfzwn1sof8h
vgt+9DTX0OOI1IWgf/n6FOy4ImzqYcmSHIqqxrs9s1822W6Oft+/spdxUkEQmLsO
eWAZhfASkNppm1FbXbpLMk3wkejFHA5ttabnKIMOrB//fLJhVmJR62GjUUbilUVb
2aIL8IuEgTgiduUCh/CB4rDUiszI9JDhZaI9Gv5bYLV/TPZOZZVWOGOY93ohpC/t
t6gyygst9HrWyuG8x/xIcsf3w8c+7MJ0nl6S/t8VWy1WX1WjL/8WtpzaG7zbXufg
YxMSoWyPubxCHjo/sI9/dVC6ipFIwxSwBbB9M63c+Sd7UT/5hsYLyC9PQf57+VZa
pqlsUP0HHiLpbasJNvJBNYvB/Dn0u5nEhdAaH1My59ow1/Seo2rzPOtj8vX2bFo9
SYmWM/GI5VCRuP/SFvTb8dyECIKjr6rdjkETdw7wTWax3/BdieUZZV/LL8Ok89NM
t7glkTsL876cOpgwb2jzWKRWOoOiOd3kDRylTD4LfWI/RLNvzMSBFaBzx7NgV9dH
vaAZu9T7+4gtCOvuPofcCekvPj2t4zKVyEDtAt33dtlRDBzl36zwML74TQcgazrJ
29yBKy7qkiuXS+CNSlnCu3By5vX+s8LTAedO8s2QYzIxEm76ACeE+NFXGg+6WhPF
J+EMJr4k7bbu8fMHReuwy+EHep0E44PJrH4Ma9ZlWRM72Ai4ODEiA67Xf/SLe3e0
YYmqF2/uD1Wvdz/LzgBaOlZkAZMDOencP6tmL69RgISrfE3iqBxACy+IQzFeracs
9NgtPlLCXMD9HwopMozOzVEgEvM9o8ycrxztIX+dEZCSbADSZ8RpPBCyDFA7yLLS
guP3vyvtXSsaTzqZECQad7mTTCKuCNhaldJkJ8E5JrLKMzkc4TAcL1olGo1XxvsP
J+8a2HdVXhlHtxzx0WF5iDdqouEbkDAcnSx0d81p7lg0fWhCt5TS/E8I030YOcWj
lpHOGDESzmuLxA1FgjNPXnt6etNT60Rw7SCfHy53NJpL/qIYJvRMXS69UcoNSeZh
vpIeKuzIO4aixFy9/n8nbeZeJlmw1GMkNxGIe2zRBAGjVfu9bzo7fAJOdYLxwcA0
c0LGBwJg1A8HOTLNBISDFHNsV5uo1ZWWlfoToxw/HHBip6qmmlKNkjDp2lPh0ZWe
Xr717yCwMF/n45dqmorWyZEZ7P72FElJj95gRmaIp//vdR+XnHSxNOeswqUAwQmo
RSjeC7EtteHAtmdBtosULJawAnl6Ul7pLeTJWmeUjdi/+GNgk2Ng/YWjjYcBY9i8
o7hxryp5v83CzWGcmk0HNatUrxFPpcRTTPaHzFomJtnB/Duf9FPh9CRZHYwgwvZn
EHp1d27QH576kE0wW/x5OIC1/WnsU/mUgU0T/OrmijVrWTK7NtmcGT/NaUzSwkb+
gMRIeybzFEqHpW6vPXW8EWAu8pDq0eF8YChjSHQM5YMgkVtKT7fN0Hp83XRMr6jU
fz0wTOnLw40gb3KL3mHgdWn1PSwPaeeuJcakXJxN/kp1Ib+h/DoVsGYJXXP16Qw9
vkP8O78LbSrTzbI0yXsz9U7IU3X15A1JPWhv3HhsRg3nsQqjcaDfhq4N4F2t6Kv2
UKUEc7G80oet/pa7R9YhdJPe/vWYMaSTbRCId8pi9euSc/QHXbVF3wOVK1iQ9Tl0
TLmIf0kaPY6t9hH7BFIJg/G/c/1YOjhLiRzUBRY9KODug/noSnD9o17+Pa6K/nT7
jxKgjz+aamSNyZQap7EiO7/Pi+F2c9vPdk/mdgfRYxwhRH55TqpDXkquTM4xYBcj
t352GnmGUGJ8spgSR2s4zwzpeG1PGZUI9RtnqaPF1Hzpd9KQUqbk4mY3Wzc7+HcO
Ov5ZA3szOF0R/9ebXHJw6ZFQsgHZnWAojSiQ92FB3XQuJT/McpszXtObH9PqqCPa
BHnPe8HuDo/+sdfkA6NZLX/+iPu93EIa2BQVKv+roWaPlSWze27x09z+L+06gky4
wQcxsdBAxrOGBasYeCmtU0f4CPazF5Ov/OVDCVAYbE6O3YVNZ5fR7fPBeiVV8foE
/Cu3PvlFHKrvydFaFkpZUHJblkoKFEyGBeQ3bpe4RT3fbNIZXPPFyvrxVRDzwjy1
G5UATfVSvfvkK79BE8zbVxYDAZq0VdZxTq4kv09WnnaGRrZSVvUSTMCVq2NvbAPr
SPW5QHlMifhhfd717fFFteYaP5sm5WbeAoul028UE9OORYMFHd7TQbhYqr78y3l8
Xj2r6gt1iPgl/Iw0MOH/Mw6CcOoXUYo/hKaI5M/a+EEvokUur004d2dfA6w0Zo3x
sY8AweEQLCHnretLBS579gbldE4GUr4c16+vjz/2e6VSI6JtiOAUHibx3jfsjgVp
k9NodvrBPLDxTx5xNrmu4E426L/VEXPM5G25ktPSV5EJZdza4qRpE6tyvSHe9Ek+
8ph0xeZO3ejhhQNgOvrpmggqmqdpOnjXPdJVyZRxRhHTicxCZialkol6anbDisG+
pGIBMBBJTmvyvYpCSZgFrLY8hEBBf8cDgsUdUp3nYrYFvxBABblJa6T/lKU0W11/
bhZSDUBqrbi4+rlTlOszIg11HkOXqoIiyXcLEJLJm0jf6oWFwxEXBZuhInqb/n0N
t3Ig4cvRMf9+USglhmf9TxF1kjW+bN5JTQaPXaCcwOOQhbuKZiyzmQJ692yTM3zV
uhrUMXvv0Vnu6PfMNVM8YgjXpGrnbV/eanVcY7wnv+pdxm6tLBtA4DQgFWWq+ipO
3PvmzSKVWJbGV3b5XrZsBpGVexVtGqcjI9ys2S8hmP0pqfoaAiYn1REeGfo+G1Jm
2SYNxcC0QrT3/7uVGO09y2wbDWurr11STVZEvkwtAh6IMEQIHZdiEz+izgfrWna8
QpDqxMWRWffEr5FVFt6QbGmkakcow1mroWcCW5vFTth9BlKbhUpgY1ZOoex8lWzd
P4avdcwfjIWTU/DRUxircuWVm7Kk7qjdHetYn0smY8w9+KVQnq2/jsS51FcxD9uL
XZyTamDCCS/GBRak7qlKZBIa67sRCI8kLawFxInUOfc1h08UGVOFk3cVZJ+9j+w1
YDXGVtZTNxgfCUynWVdGr78CiIKB33Q0nApRXTT1qUZEid0Rt1nHE9pZGD8mJiAh
uI+Xr8HO4HaofoiUeJ8nH/I9LGptxlWgFZtlsVN94OfSB2A8soBUBU7LcFN1xA+s
4vO80VGvWgMZZocMvSc/GDCVUh0/viy5ioHB2iOkxt/nW4KXty6jqBFZgL6M+R0p
GgBvcuPusgmicy+hfKQDBoPVMANCrkn4+gphdwcrlnyefDiCeU2V8V9CVr52R+65
ypwubqajBdUnY0Zoj2QiZjhsmLagsh/8hAR5OCzJ9BTnvvUZNJCPCKjum8lxD8ab
BoI6ia9+Z+krrEFBHwy2hm5p/33RjoCWBmnwVS941oZkCD64tBil8OFIBnbF5c2k
kSSZUiJ2048lEL4aH4wCf6uO9fewQyppe6INxvKX9eEXYI8q+U0QqCpQxaN+GIKu
QrqLlH/LOlO7m2NXuVh3U9A8bvVCzZ35u78X3Rm2esHeAmX2YrNAzBDCIm9ZBNJl
Sldk8nBDTC8tRTFWVEoc29JAx5sE2KX+xAt7f7Thc1OeK16hUJjCz4rS6OrfOQSx
oW84SKAu+wG+2QeHR2k8hcyW/7mhlxjpkBbbEqk1OiyI7IQXJqOk1ZeUZq8AeyTD
euHLXiBZs3/45DSX3w/iAeT9V/c1xdEZR6aN2g9DJbozcuyjyYYDV8d+cR7Qv/vY
qs+I33R/a4GJGr+qQejd4Y25b6JVKaKSdous62+RLmhgsr1gHxdPa07KkuvzINbu
wdi3631MF306vq6Gb265RFDQ3cvruH5yC3ryAn8ZYm5TsTW87TVDYfLZ7PG8aR1x
COyoL7nVZD4pdxl4U8aeGo4Q81w6Ozo+R+0QPgml5tD2Qi14MML/Ajk3nT1lO67p
xBjf320AGISZYxk2iJVxX+B+Djpzvb/Ia3jto5peHdxsEkOhe6T53oQMmaIYtwSa
0TJvUOL2X7wB6UPTKzK/mZssU4ILx5N6L/hmko8fV+eHZAJi3yZFfv9XNEeCe9os
/O7mgtl/X3w714WvfFGE4zKQQq21proUxpnG/Bbt0PvJmYWj2o8D4TIx8N03CgvN
B1MZvADSs1qi49Xy1FEFBybkbQ14hGCxwRc2Aw5I2c169CVhcO9iZLbG7zoKENO8
i2S8Sptyi4kFOLx14wzXkG+2MTeXNvch68UMmhXAvOZTtoJPKcnsSjrMr4TRYHAe
QNsffQ0B1RPPUwED6uSpgt8wNmwJwnDsAMxePBQzOstl7vYILmEeagCzl5aCaI09
jUiBtvHkDiEheKld3Eloz3Yo/lyxdtOpUAAva/7BHDDd+5C9NTgTYsUBph3TaCqv
WNBJ4zAkZotWFlY738tcr8TYlBy7eKgREfsnBomLjH1M6eyLdz7AwBncwPx5sxGn
dE51BJDw7FZBuchWBvpchHq/roWyg71s6nfvnlwITkX8wBlDSy+G5VGdjgb6YLKK
RSjCYOi0V+3RO1AHUjdB5LCG9lRul29o5n37FhYqHFA98iCId9Ad129FtmsRGPho
QY3PFPtH3PANAEbktlkjnjYKH7e0CE2jodTs9X4BtWr79HjAxbLPoCd5WP+cMU1Q
mxJ3bcA5U4/LqGlh5QIXUKUARAQdyaGKqZDNEurGB6oVhW2t0yq9SaSuGDLLZt/H
iqcoYteqtt5WsBvHhuQauYSpTOZt8EbYLLWV4Uvac09/WJFpRUvO+N0KxT7PUxAn
hT9qt7y6u7dW2nurXTz4x27EJZLg68gdYE/StXu4nW3RDEIpPb3sDw4qV/iw+k60
T9ZchfYfQQ35UgN/fHP/cdZAt7VOs2l9mS7LIAVdDG8ikRC1EGUk80UNfZ+kUQs6
ZaApurSjYrooGruAsGOOZwZAmxURz+jkuF7d/l9rQCUWctY7u5kPTb0OQtJ/3/l4
TrQkhjc2S1+HAjaN2e96RJTfCATVMd50crqRtGBN1bwvUuQjGrmOawrmg+qWOBY4
2JWO3An1NpMnBlUJFj7Yz1krT/ttDAjuGshME+h0x5dMjQkCRh7T6dqsl5UTFYRH
Sf7VKZCdOewScJ3vyxf2UMkBOc+Pru/u5WQBFSwak5txiGEwhr4P5G1kqNTDBsUC
d5VpddqNsAxMn+XhrAJKteuJSxac8YTd1toZ1Hy5LD5QYCeKEwxPar5JTuDT5eyK
l7BOMKpBI7+EVYAHgNvvzXuI50O636kcHpykHZoVBcU3zzwaR2GLkmv7NMyiNHbq
69Ia09juEa7N4qnQB2AObkTMGoAxwDotwX4AOHgFSP2lNCjkY4+vDTCnlSpSGULl
5BfC8BWTesQuDfkC6o9Yf95GGfADG8LV5qgYyhw8PPFccP98XR+x0NgpknCXEXZ/
O1XfJgInvtUiADfTXE06sC3Zsoo5lrR3T8/MpY5WpM2cx0DR7dLgkBRwOm5WgDie
Nz8kkMwVXWAfH5Hc++vkC4q7A1MdpbABxan3k1qHLl7Dqc7UgwUsesW1qrEdO8lG
CkE7ucPbbnXYOR5/zdEZinTGnokUyjY0AdNFNC4HJh6r+l4ZMSb7YYa8zuixvsEY
riqreh+oSmHAyFzumj4Mn+n4F9z49FU2XjZkQeF3F4Pc/b/gR8Wqm3K/f6uIIMZD
dWRjWEQh0wb5mK3nqpEA5jnZCR3U35oitRYH05Q+fS7iEr0DRzZGZH7EZSWt1iYs
35Dk+tL/bqTUse78hVTDn6JlmO1bxh89SajwXxf55DYWRJtJQuz0o7+A86XcYJ+n
hzzeAtyz+2uO8Jxy+2/0IrI7ldxsPf6zT63GIRlAwrb03Sq2CX/v9HOktvvgffPJ
FI9VCBssIDNn72O0oD65+F7ecBw9inEpVDC/jmukzjlFqAF41aCusgHhcFiUJqgR
ShMau+tBNnULMlYwzSnN1NLAU6SKq23Z66QPffiID6mm7O1Bp8gtEiTAzLbR8iHJ
KTD5Zh4rfjXBlM1ye3wrE5f90th5LmI/z3E+uAc9v71sSVUxc2ZPxZDowMKPJ+/w
xPE2wssCGCZAW1fkxH8IuynDov/nqWLav42WYag7OgAAYUyeH/nikDhhyAcHPsje
vBWYGvc9Pn0IlzLf5gsRP/NPBR3tdGaNu4bH/a8o8+yeDkpYsa2ml/Yha3fXV8JD
+VvQTCr10MRTeyGlHwPcHSVzoEaD0rMsrPuNPujw92mEMb1MOq3f3LFVXXf88iuy
dr3Mk8WTc37xfLzcz8s4nYENlJFhCaP1wkOjHgQZz8p0SjShiaJEUTPx3g1lnTtx
boJxgYu6Iwu2DRfa7zzx/ZqRdMincPis0hAwsqDcGi0MZqpVpenFrXbK0NCymso7
aU8pxkh3wVOV5rbg7cUctQOeaLoZZhKNXrNTyTT8EZ5rsFJxCz3xc+I8HOxugIbb
bRuI8XfgIBf2V9WdvQzw8a3XCSX73Ucf+m4cu1cph9HM5L+jtfWK/lMgnM6H/BDf
vNbG1iUAkCpDbC80EufLRL+z6XuX+Q5PgYac4/TqJORstNEr6VISG27s4QXj2MOc
7GriYI5bs6bWwPQ5fXzB3E4fMPiUXkUeXFdxzBbzaDHR7SLscK8z2vr4aDjKN3uf
VYKS5GI+HceCLCIB/j2RVzwWxzs58tkmKLxit+DhhabbPfQy2B1ttKGc60RVe2lb
dFqZmvBRKmUQXEj6IjoXmASU724sY7jOTdMOe4PRUBKxTABSrfKjiD3UYCq8oaoK
aeuGVDYgL9H0pDOefGhkh2OTeilG0O9gFMFrIHA8JW4EsG4gsqWUJrcRlN3WBZ/7
T3aRYh97nQzkR6slRCqS4oLIRnfumyCfDdl6zks/K7wnJ9Xx3UFF4CEdAPc2gYiN
BRINyEnF4xk2H55wQFJ+xD1zVrXAS09gXjMMruvhsVnWTcf3KWzTOLMTpaPyv2Jc
SVRfY0JJa3dBB1bkwbcvDErstoWty70Xi40wT7+0Hllbhl2jGhu24sfFsDK6gbRp
sPeOSv5lIPQQewWyWHX86U5cOjQ7qo32ffOnmyCBmfSVGcht8qbaFzA8bS4jgiJ4
AFBwJO21soHjuEsjWsfY16uC5zntyWLJwTWt7VUyRrz6JJJp+AHGLRvspblpyZxB
7QqLMLQZHQL0n3Vp6RFvPJi9pI+5GsAtFbFtysP5FtP1FeeBgOGQgMhPrwA58H4Z
QjZxuoWRayDWqikA3cSm26O+Y/pGHYdmHxPhfmgf6SE0R3ri4SnLKBpq+68uw8RT
I58IYRz7XsL6tHBZ4TlWua/9C54t1JoU+nt5Yi5bjt8nwTsS4C0e5W8dKnn2K16h
hLhqA7VnSSjygZyTLD5GFYC+3ZqhpIgRf0rPmWuP+ZkZWnU/L+CCWiT6wshFv7g4
VhqfPxLreBV60cR9RvVgtJCHMyZnjFMcpIvlIYJc10iFf5g6hyP12nlSFxnm9tDq
cebAtJYz4T/7xFxOqDLWiG/MF4qR4laDaOiJg8IihPLqLqMEtI6m4KsNV+EbeqyG
JIHaBX4nGNwekP5iZSXOBN4yg6UmMiTLZd6mAIixwBlfA4naYOyOo/O5iIPPM/NP
Vlfsf3T/esLAui1WHoBmFTlO7f6JumjixGW78x6yirUfghdY/p3DeP+qh2UO5DPC
9YB2zuRPr39guSrsSUIqOu1RQmiwtftelzZqV7uegsldamATbkbyADN8RiQ/uwBn
LeToL5HgylO+XyvzmLkfzS40RyQjcXHnCpI/m7H8MH7V2oNHFG2WnBj6jGij/tsT
I+rzAcdLzxyb4Ok1RDo+0lqt2yK2zaz0QsqwoWWgnOooZAbL9fISCSY9u8n5Nn+1
hko7CTNr3c3htfjirixmYNL1sNCIneJ8Jha+FfP4WD+J+tkjQHVI7jmR/WgUEKB3
ZRnEd1TBaLitirv83bOliBf+4sew/mWF7lsXdvccAEIH2O4ujmjL8xwXt2ZjC3Fx
kbOC2dFPNr0E79cbgB8aiGtnEUCebO1r8EpTFWSm27rKEHQqQAxalaST6DDVzubN
f1BKxjARMgEY7jAw/Nqsc9aTUWf/f3ictkiE6XpoyX9sS/NrSwR6R7bZljI7/IcX
ZXTw4OtgWht2IXBMn83WJHQLgG9kVTbnsNTdcArZ6gGT2qVzkV8KNCI//UiqxQyj
U1EP96TVYRECAm4pY1Uhfl14O7zKfp3GyxjJ8qHV3u1fysIy8YZcCod6a1zH0guB
Yw6syxO7ndb1GLZy2+4CDApAT8neHOojBybEiDOihfCQ/SCnsd0WoGuq2GTZXU5o
JGBn23AHA1vsmMSCf1hlvF0qplHkzv66wJ8NvHl5mgnRB0z8WTB+gtTTNkxZZiu8
T6NDiBdjXdBzAuye3vFE6tkzQKViBFUaW/2DMZSGD0bKvxdAVp3NKxT0cLAem2+n
OZ1d0RPqdshLKJNFT8dYa5VkGVehJq9v753ved+AZTntSGqHzo8WO17sghq7oGyj
eNOmesxhO+KzFp6bE5JisXSxcfNBIooU6rz+++bKLVoONZGm24aGAFLIh7NdsYH5
FsKRw8ThYYrnhy8q31WPPLmtTV+nmUKEJQLfm/8C9Q9mWHPVxOGEnkZWihxtyQZn
Nisje5CwNrQFd8gESC1q5PEhl+hZOBfaWMJTHfyMsxdeUc7rCvHyBAi6LgolPrNL
XmZkz15tWI8B2WQM70e8IakXUroNgT6du+OPAI0LOgp0YJGrGihTBZLnzeCqQ43D
wYu5+xxOcWM9q9IC33JRqNXZcAf/6mN/CliTeDjDz63gL5P/zPKuHMSbq0cPKAZB
Jn48i1RF0ZGyDiWyJ9QCi4y+m0AW6l/Zy8ALNxsofTK7s9Tc8Zwox4m4XOUNRiOb
Of4eueelHAIcQpPcBPrMVPuajWVx31gbXdkE4EgEuurJ11ruXWF5EVtvcr5zCtP/
RCR++4rIF/gurY0yD9CWiDEOrRuGC0BkCltzYI0KJw1Y/vrn6FhF9z31LTT9dIeR
qACvrN4erjkSKx8TX61qe1G+t4UFW6QS1J1wIst5xTqXAiIq7nFahDalKup9YRed
/Lj9JZux3ljKZnUWt0vOv21YNEa0sFE7cf+3Gs7o5Hd6uP2TxGVA3bajGMLwBv89
CPokZ4NzAHLPRjUQUoRc2+yA0LCPf0UjmUFqui0ZsffC6taKdI2qCypfwCNaB98X
xA7PaGHIUnDD3zBm3muh6IDLwkv1cxkUbGR47zDMCZN0SECcKUFJy4iXV67zITdI
VqSqXS+5DMjcsegHEOQzpx7Zp7LUmEIS4VSUE8K7HF4p93jjYUci7eVlOo7WAVxQ
HwusoNZnNt6Hsd8S7BJ8dhJwkvThD92ES/+//Sjk4XwbOX4elSVDkrsSCQI1j98R
9YprAEVii8B1gmKpkkPfPOQvquUkxVY7GrMqfZ8HgFMglGYiuypY14L1wpxRZopK
aFWovZgkvlbvEPR7bkxUvDuMmD5T6Yv232hIQ9Vt9AVZsbOwLurLOwWR5P74toed
Zf7hr24zKpVJUOnfsjjJ4jz/l3J0hXhG9/XyZy2/xOCdpr7Jp98oX1bRP7nmBGP+
LefskThi5n/h16FmSb3xbEW3iNFn8K9ZEuTSIDiSOZAslBgwJDuibBKTVv37GP1j
vk6dYkGgw/eISUhvpwLfyYpVPnKBC4Bd2vizwpk/gNuzpaHjoP/GdWZwLL/bGK2C
Ley2FFa9iGKXcCjF+M1hA+Xl9cYcZI7jPSNFssT+hYVEnSK67cCwLas5NIPldfGd
33Q4eber5pzFG3fEHunV+wvWjLCK6iUqrksolNYsKtH3u8E3O3HILsZke6fCFZXd
ALpR55wop2k+aQejsj65Qh7mDxB14f+TSpx4x1uuOdcQN+GOgwcUzzUfos4AV1ts
FGp0EthQV+srbUF3rB61UdRMVwsA8HDdD9mF2eQXZGOdr7ZuFZYVDea0MRU1+fph
c4Dv+PBlfWE4zsgezujNwNL4kx92Ajm9k2I6/XJ52El5zQzNbKY7SqYOa7xUdm/S
PE4XrZPUtwZotr84kbv+gAPWq1bSF4RHHgfU6KKRKsvTri7cxrlHNsZu1Pg7V3pA
rHj+up7hcDeVNVo+EXiwvntS9hWMJQyt2Hf1SaCg1rBpGM3BB+aPp/gMYO8zUhBf
su+raDdv8TKKgtlZsZWxHHJPEsR47d1Z2FMPsycS4l84rQRhnTk+W7B7xOFHcyeM
Dj2AyVAVt3P7guw8m1SlAfVEGkfOGA/yu/iYaOT1gmWWSX2mtJJ/cZKnNn1nhdRq
R+qGEDoMZwDJDHCXjjR2C0inSesTdfzQplyczaiqO2RMr3+LL89tdOJs2TZb3nPS
v/vy8feSJPoxy0Ga7lJOHOyzCWiXlxU2KBua6cxnWj3rM0s7i5TD7hAJELvsbMlf
onyrHlaVrRCuZhTWcX9JINcyjAFMzUUbsM+QkmMReTbF+nKgb0xsc4MTYfAcXuzr
1VMJ82HGftzf4mwyPA1Dy1ISdp+hBdV/2nafmwEWpFKhkQLdQwrLNUoV8YcFMqyM
VWJtbCCtaBnw8Ec7NILRzgq1IVSDZ2QI+j/8DWBsE/cuQiNrnFX+eIT69aF1iTi6
FmIs4QxMwpgAFFIIeneEZohWQUrDdQlfnI2NaRU65J25mXZQA+OLyM/92htCSTTT
nWt9DqIoxrbn/xvOerhFnguu+WB1X9wuz+o+CqXaoZWkaw8dQXc20jwNnH5S993h
2R2bdz8o8/64isIj74FerXhN6ar8UXsNp2FMbOoQ91g927AKbcWx+87p8Ub2qbSj
HLujjHMGZFre5SBjRDHuRg0h2lI74NcmzhBO+eXrkuaDmwg2b4W0r4F8ou7W/ifz
BRbCf9rYaOclzzRpeibDKEoLxisO3YsrZij52GQ/9DI1FiKnrQhH6ehZV0F2qaOA
AfleO56WBLJ/S0+TLVhftjrSPEnuRYTNqpCPNwYYUxV7IfDnQ3DThPSKlReoaYy5
U7x3JgVaCGTCoFeZIC2qm5HL28oReSr9RTtS1arnxaC4r3f/+CloVbc+s+H/YVpe
YEOemA60wzlnDaOj8e/u/BegT9FXjHSZBDBJAOJxVzQqnYyKFmuPsEIFtqMhVzjm
LMhTxnHANypaFr3rZciho6Pz2Ky7aDsoavBtWMW/DeRMxqwzrODWeWtQeRh++6EA
4M5UZN5oXw7d++pxCWZ8Td2lyTbULdd+v5aQHf8YIuJnZQo8sQEWRkWl1110CtcM
RnXLXDznFpmgK9sWsZJHGgRGq7ZXElkEg/TXCaqoY4GiENVP1B20KnWCjJrpA8S6
KenRSlD+OUtRVu4i97O9N+2xxxFAdc1yz9GuE310LLOf6eIJGOcnu758jqjAu6pw
pqefYY0enS6aFzPoktwzQSaRs+1dmRdqyE5HzrN3vh3VBDEXkVf43nFxwC1srC8B
rc6ErzgurYugh3gXOd5gcOsYdwn4tGo8FByGUdMd7a8UFvTwdZHOBamOhm+ifBE5
dn4dfX37QiQseXjPKYFbcaBS4DxtyS1rirMsgQfyJGxY8zO4cEAzwhKrmPFIEw1M
xuXjFGbmlCswL96LMaXWibch2LOyt+NraY8X4VD2u4rkkC2M3tJMPBFZP7ikh0TK
hMlFjFdGuqG7aOlXXmU8w2QIh3NYquse71YNEZjeLYO7ejvTlPIj603WdGVw7Trq
TM/2TkayuF5HR9YEMwCV2I7PdPCzPohvTUe2RvORqJremu2qd2wMmxOcNTSWaccw
o40VhM7n7RJr6RW+N97hitBaWEq+CxT9QRCaxqx1dxZ+qYHdJNC8UbhTpNSIspEL
x+g3p9r+R9Z0zxg/P0dUhVh+4sPge18HSRBrgf27YenGSyosPYGvBqZh+T6VOHGd
sxX/XFpJadGLkDN+wgSf34wSXaTn+I6XUAJXXkcGWb/PjBzdhTME4OrEZ//RnQ1A
gaBpqZPf6LoDdBh916PHrNtVdtXx9Uwr5Q4+0UxNXWfQs9kEl6jTIacCWCI3GG+f
sYTd+bCxDqgiIjQzIkrAuveQG7ty86ziqVD6Gi+NKu0Vy/+e0rf2l9ResI1GkBGD
AO+i+IY1dswfa1bdTILmAgDaM64L75zxzn1sfzXbOkvc+DwCjoPFIfgvahT4kWJu
FcF4DZ5z0eyF+QML532dRlf4OEdz2LfWbZuRWl7Ft/X2VB2nZg6TzffUQ+jDnHVP
HTewuaJfLxHqqundsAPLgHbVGEV49Y2+jWF279UGA4/nw1qgvhRsMbuOHR/xlTCk
EXFoBnt3gwa8pSyUp21Es1F+AvvIc4MshgyUlhA9F7RLMjv80T8f4gf56o+A1kvh
MU6XZteLdP6awKIa/+ewjZAtixq9+kp+DItpY07Fede4mCBapo50VfJJMRfPKQnm
iuPpHQbuEt9IgYUHuG1XVFExIBmZ8sCSQGcaFp31U2Sq7GT+QSGl6XhnV7XMrh04
4XXuCj+wkAQqJ6kMhSyZJQem20Q3Qykn+NIGRjnCQz03lbqEyY6TLuxHVOThMKCu
lpnRiXu7+wAcSfR5wpNrCBPP55Bq+KzVfb5bd8dpzvAAazQo8vlN4mUQXbmpWO0a
U3g8uAMj0H+a9ebDGwC6kRYxoIBZK3YAgW7BeE3B8p2U7/TFARiMuzPPz+4DVHLK
cLVDLoxn9xNYbY1E46ZEYd7XhbLuKs83abICw2qlgjKEZXdf2c3+TygKsvx2Zrga
qmn3TsiNQHBDVHKGSbTyPdnN7wgzvDkEp0AZdUZ+i4seZgjTuPJh88mHUhk/qO5b
OS4i5wRVtNVf3JnZxdR9wzyYnSJDAIflpJT+cqetkp+vePdJ8Mt3lmh3dpcaOq8Z
hF6zHnlWdPX4UZ7GXBbIzT8754ytQa8QnDoxTsw1R3TGtCNwnKs9shE5eIqm+CNO
JkJF/UMY99n62TogUmCuszuF60vJuYfXcHuL2Rj/gOesui/uTz7qTx9Cgwu18w8c
xk9f1FDkUCotGwy1Rok6ip7lbnhr/C4tFp2w+KIB3PCCVXZVDPjwgNfj/7T40Oe/
uJgxkZ2ZUiF4S+vOnIjP6LKjISbAhD1h1gYAwN9stgcPYdgmMHqVAi4lWbd6O8go
O2yElwxsxQ9IFwJNLNgjxHZ7woUWqI32dT3RcYFIR71Pklvs7NM3/u3lHkrUNxKc
7dI0kpWbAk09QwLGBlggb9Y/Jdiws1XXjZ0YY1JrZ+qUwblclamHIcav4o0YwhA/
tjrRhl+VK5F4EhfS4mE/uhWw9t+sS093FnewcPTE5oVPCAbm5s2EZKKUE8/Du7KX
CL0N56qV8u3vyfXdNFeaVUmZynNpjHGrrH/0M6v82207xHJU7gPpCzxA5BGE8ja3
+T3SnaBNrqbKg63MFd3skDvsFMPDu4bf/+BFl6b0mVEARpPOVGrN6ad08MEtiJUs
WJV3OW1yoxVNxht3Z9TnSdrcsT++NRWOu/nV+TLBedBdwycFGl77/uwOHTyrBKu5
/r6Eu9BaxZwvIiCtEm87bqZ/ZEHw0H0d7FQLY80Go9SQYFBCoPWDhyVOnexyRYmj
vUirUuL/VGaDrWWZPJCwkmtgMaxBfH9/Lu1eMwppdjzF9Ef8YdVLYmsrb5jPCFrq
HXoOLB0O+WOehkh9wVlGSY7eYC8ngtMVmrNYclHGnUBzxZbze0zUWfYVWx5ZABVd
yNES/s353ylnqimAHCBNCqjArCDm37/a6rqIdcf5yHNeerMPmhD2D/8AQ9YWTaut
/M+sgNCS0N2yHuZ4fF+c623KaSfvoRCd9+P93mHuMzmlqrDbAnt+pOUU3rfQyDG3
Nb27YTgAB6nl+7FtPng/XlypwecWp2jGk7Qi8dg15w5FwORH3tEPL/G5G8AnAP1Y
xEHiQ2sVdzLKD5FVKq1oMSWtVtrNmKRhWksnvxlrIahhykyl0Pypq1O3LBjbC4/i
Qu1MQ8IjoG/G7kQcRR1PV9igoqabo6neUKC1dEx/DnjDLpXi1qW2uhZhBXRTuH0C
2Fh1OgN41WizOQaRfYiKKPnTlqnijI+Mtlw5a5sYMZeRx4fyHbR5prRWDJx0peUL
oh3KoeCLm09R87hA1y+Z8k3Ezo+d0qFGWj6EjHVkLPhQE/msAreFzXkB39Huq+r3
zgeSgNf6AUWuMQ4hZtTJminrRsEMF9qATa+zILh+QmfkMNqVRQXezqH5OSp84Lhp
Di0nHSYD5Ys834CLfJFvoVRMDtZshH4Ni3SS2j4TTvU3XYw3v5sUPQIty35m8n4o
cGDpCGiW//bLF+dBlaYnHG2GpzCdx1g9IlLrDj9zBAHgyESpZGTLdQ4Ucw4ObvMg
RBmvAFl1bh8hIA1EMXDFxX5JblkGmIDoHgf+tYOb0HrV+h7+Tv0kl1u3r18+M1Sc
p5GPEG7Zakss97Oxdi64Z/BZT/nLdvh2YJdBKvP6L1zkQt16x2L6ODiuIfe7zULX
Wl/Y5n6vWUYh6x30J6hX29l2+sev+swE4EtULiowz9pHKUyPxtoVHEooQt0Qw1ew
nHDCHeWvVJoqBY8UZ6KxMRAO17h9myar17WPUyVpJd1Ov8MxpNezzQgwa6J4jXmI
1EfUiyxAyU4s9ekEAqXJYzKmkE7y6NR+hWgHZLui/t8vQrS1slGEF1QVk06wMJhx
fipLIvEQoxO2qW4hH/RUPlVYCteWQGNU5ilWFE/ZI2GmmgkyrAHBYl8t1YvRtw7U
erAqdRP6gL5y83lR1hQZEMSQlZb7DCqBEarUIikIQ8pkBNhjqpvlaYhDRYt3MiJD
CkJkl1ioJ+QoKP7RlR5+yP7vPduPX1rRsDuTlZKTm/rtTEFQs56Uy97B37Tz3BP7
tg/KHCkwpfaxOTiBuSGjvzWfznhAeL5rLTBwrjgQPCizT2faD9A/UzVxCsasbNTi
ajWUdv54wEs4zorPcr0KpQ/dW0hEcyjaiX275Eowjau86ycF3bcI85a5gE5hiols
PnTuv9UP300+RJttQXegVRZMoWeOc6gAdtp6Bc34zy30v5wZIk9c7WNqnCMCymWZ
+tACQZjrAVbEh1Dx3XEP5s3pdNYm1QTHa0Ekz45bEUnwJ3/Fb73kdatQ/EoV5k6a
aQa4cGAVkNwKMfBzeCC/XxrIi8aNyREqD8EjbvM2IH/dzjIo7LRlrKgxoKtoibee
JQ8/TMnLlNE6kwWGA5uVN8pebbkxLkrCuwWATm2dNpeHXga1Z20Lvo6vdhsxL8Vf
yAF64KOTYznAwycoJLyq/91T1fPtwddj0T6pMf2zcAo3aJ8ptUct+bXyokVu2ibX
kL9Wq5SQ22toQ3OB08KT3Epg4S7D5iT0mQUAhge/NFwVDCSWUtON9jj1KZnhQc9g
bwB2WSAPB9tRYlfno5mRVbo8OIH/39691oJib+zgvtWxrahUJTTGjpWGlRRAB1so
5FxEhbLmU27eLQOS9M9r7nvMbepKnzJVF3kGsitH8HYaEveVNz+g+wG9jGj55GaG
lrod4Nh5cKUCJuqinWgOsbTtJmK/33ljXxrt32wKyAA4COKRynN6Ir1gldCM9G8c
nf4Nfl4oPBlw7+ekOcceIywGINb2EX25eVr6gudcmrqB6uv4NhUDjdYdEU17i9uD
4Q5gT/ZweqHdbD5OqswKW4DBv9Qdx9TQZZs6RE/vwUiYqX+JSwz4vc+J8ZmEhVof
VMxhpqgWAxKYH8ee5fPQTIVg64JIRslBOXpniY5AHqT280vk4+5afkEp03P4Jvl+
S6s+NLEAXc4SIsN/bUBDub+tMe0uNE3zrJs8eyosimGMuTY21lOmh2R/JNcmPYM/
A5GzVkTNNlp//RskDKx4j/80i6GMzds1Q6QUJ0/3pESj+qQ6DF7AKStqw59tMCBm
rDNxm3XGq0HUNJnfIEimUSAYMjy4bn244Ow/CS7P7WAPSOGKcpUvly+z/Xm4CkwI
JGGR9i2f0V6egvaXrJKwHeAG4iJa+YFXP+2vdKpa8RRyAUpo2KUcHbs5RzPpXeI9
gOlOcy/0nGa1fNqf11Bf4DPUUd01qCoozwejyTsGJvCHr9beziQ5/qzCzOxqUpen
EPO1UJC+ke8xa98DVh88BPHHZGcj7B9KEVwsjgqtqreHsmj+Ndt3QrtKx4JTeUtR
xUd39WLpb1kDVMPg74mSWprFRcWz74Uy5ZZKRDlqtE7wSLHpMZ0PdJQc0ocqKC1E
fQYhSUAj1GvtV8qE0ceLrCnpcLQVWaCfVYdSGZS75A+G+U3ibvZ4ZN04jyhw5eO3
mIfeKDkhO8Ghs99+TRPkVxu29T6GmD0dEitUzI/9p8VDcnCPQRIQ5lusGYBpcybe
ZuE/j0bBSzbrqi9FoPh08PXKo4lozj+M6KKMGo5mLmf4htS4xWUP2P90LCuC9OE9
tm+hE+edRzI8cXGW8mDwfj5fsDMbDeWIvSmWOMs9Wub70eUASIAS/PLul1jZdMaG
titrhGJcMD7x7ItvLJRw+uOlvGcR+ppC67ivOyGlUwpMn8fVkqCYtrzTYPQZCIbK
xonjwRaZfzm1E6KSGLm5vYhH+4X8jf5sAXnIizjpZ34XPwulaFYHdw+yMeuuAMS0
zdHqCeYLdhG1G9Oxkq3MvjWSG8rrmHSEwDz78xkvApIojfmX75E+TC1xE4FnOElA
rZ2CZJUgB748zU4BIBwXGCzGymmbS5JExFABpvklJBesAErEojsET/J18Oa7RwTo
unKCpdhMkPd7LF+A4MIJrSmVBcggGWdqJ8bWJ+zYj49KSG0Q53mQKmK1ckh65nqH
+Fjf2Qp14OZnCLY0l+1DWhr7BEJIp1/g4KGx2i/4WHBisEFK/f5bs04oZ8oDYxwp
6jSSX9puThhtyMDFgN7i1F5jxgmXGdVvpVDACFhvwyx0dNRHNdJTPJ2GKJf2lXSI
hVRozOBfwDUidW3ICNKRYxBa8xAUKOMzWoJgfL3ndQReveJ0KLdZ4V5atAdJlQzQ
K3OBouJsrDRUDW6++eif5val/1VjrWtWSxB8NZiBEdJbvXDEPYncv7JsComovJ2Z
q2wX4iB/Saue+UbxRVvGrjRd66TKU2TFcRj+5xH0uqLLG45uoaLSwnTOZrfZy806
Rx8SRpR+ZPikhW0W4fLY+AkMVictu09ssyHIsSWRz3ypfg9hVYxt/YmSoxmA823l
EBZ8sYA2yAu7oyeDf5FdtZOqQs1VFKEsgd+f+uhOzknZaAM66Rn+3iDOYQOoYoVl
GDo0mt+bYbeGZzvJocLYbmW4aY+BzIlGUWqvv+rgZJKQOe7cqqD6Zfo/EF2iO60U
XpoyUxh1PN8kjNoE8WhT20tIsFQbsWHiflXaIYZHbi0oIJ+vAhbKAFhYv0Su1jhZ
shiUwMHquPuxxZCrRpGU+ZAYpnqQuP1elJ57oH3FNlR7X+0VECMdQ5rI3h8Dj7Dv
UWg9FnX/lZUdvm27oJZ5g4ad4cgnFkh5xTcJ1+XgcgrZrNjFwRYjMXQplrBIMNWQ
pc+oFbZgL7XGBYDl+ZFiX182QTIZUfXaoDhU6vePK5M4zYTR5VBuZ3abnq3J3ZFg
dhlzGMUJ0PhdEv/6ab3P/4Lojbh+kfcAKnKrkqmJN3tEzWbO3hqklj7L1FkrY+fB
Hah/kVjwEkBIv4VD7KQEIE77hQnQ8wDdDrF7Y2hbc6WDRh50Bbu/I4qJEzSYJb4n
qGlhP46TMLPSs+uKzr8WWEmQNfMTWla+w5e9hjr+PFIlO6QhFKRjY65nDTPBg4WH
lcbrzHfwE860ayqHjHx4l3TZIN0BeP5W5pVyFekSCe1txjqzg74ilpD78KzHGgud
B9FRLSfQZ+KnPBaAkwTYps5fVbHhkspSygLL4bD+lbxceq2iPAmRLGYpCRvtZEIx
RPIjTiddepybx9VuYsc+NWlOyi0l7/HO6ic52paGcezR/EKrL/eUWDxjQ4C1pm5J
IVv+VMhgFI2xDSbP2icYQ0PCzZtQQ9ebBQbyJLLQW1VsB/GRFuqWb0M+nz0dH8UG
fVhrdSDkruIKrarvdGXOGz3kDBQCmhmXyKkO2yzh1e6qUFNM6dAIstk3cf9phrcu
HWpakSp8OGvkX1c7cKrtf4vXSr6aTBLdHYcBILhWyW7/mc199SEzY+EnG9gv87qx
A9nDWyJUns0gE7Dor/+msLkFAKHkfwfQlG1PJ6qd5ySNDQbVfaPwBIT5HfQcW3ag
1kKoJYtjmigUcKEAynQ4rv7PUHtc1RSWVOgwmWWC+OLxcW3iSvPpM2ip+fFnUK5U
EYALIeKFt570l4cRo8T6WgwywcZd/gwKKSQoFg6znDle1EH/n12NuzX3bO1xfEnf
8YMzVFlj7Xm7F+cJJG3mU+OOhFB+X4y4p8tCRhcrjwYN2I3Ek8epvKiIl8yNUJUA
EhrY8A1dovHU3OVd09/rLLxjyhYt3AFIJF9oStSO8QO5U8drRPmDhe9ryIQp1FHO
idVRWDg3KslcC8HC7rj4UcdjFQrAbapsAerUVKThO4nzWa/t3A/5GbIyYn6A8AjJ
4/h4dafnCZiytA5HMQajrg+K3l3FnFdBxxQNMnd0BN3vNTgJyK3udgQTF+LvsMN/
0yqVd0nQKroFSh4hDEyZRG2A40iAKzdVvF7aDdIFYTY3J69HnjwAJfrMIrD71MzX
GuyUq4bvak0ZMRaf3b3A34yJO943CAus4BELatCK6uuTIubPh05EqEuS9aPZlle/
y5h9fvnIvkRGQ4RPpA9RiwrW863ZjdIYB4Xu6pgkhs4TRuc3pViSeBW3NfEL0JIg
XN8SFpskRAULA2nDLhV72TTndrsStkmq+L7T+ICDlJuERRhIIYkejIXTm0nM0uV5
HM2G0WUBHbTZv7V3sTEzJwFOP4rdi32WGwi1+/HJtXsyJiopz67OUpj6ysYgWR9a
5oABO/GYRholEYPDXK+s7KjD2Jj5CU1wgR0hJ7iIiLdt6nygiA32hdrUC0hWhJ9B
6Ks0jHe08LCZf49Hmt8PtvlUyVrucKMd0iNefQiRwW/+hE2/YI28FC8FjVWkaOsT
gSOmT4piFDPcsKE21kioTN1enTwkuiCkINRJBQGgvgd42nXYc6LO9a22c1hTgA8a
889ByCPZfF30v92roVRRjBMnwr1sjFEsdcQN0Jb8i6hfAQAneszqYsQUU4Yzs2N4
XxhuFt8Yst94r9ceZzxU/vRLKPxdKlAfg11vF0gfIC9hWcoqO1DVNeQCmzn3TRcP
WPjsAYRC88yxq6X6T5kJ3btgahuXg5qMrX3TyDKaHnKNvl3Xhdr9d6gA+zP8xWgU
jL6CS4zM73VIVaCnqhlf0mPxtdI5t4oFHu7toA88u1nJM3fIiVE1U3E9d/0kmGxL
9iWVsiXsh8gPWtpRv9VtbKzdzeUpEDv0vOURYHd2k7ioeQ4erwvym9J/K5pu+dfW
65v1iNOfjMW9Ybhbp/hFA7Pw5YM59ZdALGugI7pGQz1epwWhPEIw+5hnOVTTCpzc
CGXs6TMx1/NAyQHxneRHEuOiNZHZPaxoSoSjuEUIriDP0NPl4cAIf6GDFPhlTyiJ
wYA9pcUQ0e+D5DxKRFtfhtCZcK4hwRhIlYlvm9hQT/MNbT8485v/n7TQkHR0Ml4f
zF5QqFx2vqw7aLTchJOeUsNXWpuuAp9esE6hC2uImRrHDnNCBpzbb410io7XyO7I
nYiyENhXhcva+525pOqH+23+pWse+6jMjEzDgck3W4lb3fBwBGBou99unnq2tVGy
KlPNxyZ+GLSZKinYcxdSXg6cCWryFd1oyOieA7huklGv+j9+QvQus23woWS4hsB+
zg3XqivlslpOp6jGM3OYqQo9xMOUME3IuC3WayBVB3MvacG36v6UNoR2/Vixwzbw
B3zQtfVV9nRbTBfqvsBOYJIewL1UpnWXGUm3NpNwQ37pRClgO6qfjhvA+Cv3/W9j
3ITJkgUbRzunsdbTMHmP8esUDTOLjpvXcPyigPo0yxyZPgbW7nlv207e/55/8LzV
OMd2iDy5DRrQFlM8bQhjkcB4CupyA0lupy2Dst4DQurtXPwIpDszgGfCJHFvrju4
Kk5LixRDjoqYpHt9V05RZUhPYsg3kaDJabclT+dtE1LXyVXJpr9s0tV6KInBkNb7
hI2s+fBimwmGRKLAepXzCZmG0p62VjQFt5i14C3Se3PIslT7sdVXbnLevg4MtoTc
LbNrgjvLCO9fwLxU8qBzjEpNd9mRcwpX3ucxrLPVKwXpkoUwTf3wuA4MXM9KpwiY
FRFITOlYn30STHUBzmfpiD0vdRss6CfEhmzJ85w5dZaCercj6e+ItrkIC0RsLi6z
jYWjB2jZ5wxFRFaUQnM9R95lSd6u3AExc2WHTE/wCsU6mzTFK5QsRHRnVQfI8Uqg
llzrg8WSNXSs2ZH/Ddb1PEr+SXip5g/eZHnPnb0h1xlZnJkcrOgyqPNcjN7H2Qcm
Rdb3DssgNi0BDa+vijJyEP+vqVWxmhECm+JiYFYosufXhZ36xCUF95XYkoFI3tw5
LOj237oghblg88PVv/r4pmg1ZDHJjkQaFH4LQbxVcd6vBmjlxoIwc7N47128Jxc3
rUWxPyIcR9HA3FTsQBDgalkVPqj+f9SKbNQYwTrziRDhW2+mOp/IwfhdynYOM/vU
wGeUNZjZyz1UTm3ic6Nk0SJ4qP8e/9Jr1YA/jjxwsKISV+VkX9TwLwAZ3J7FuxxT
l58vCfwuHtFF8Lr+cqLEsGgbH3JfH6Md5esoV+00SGOVzaTye6/NIKdUvKN5qg4w
5XQyeXdsV1ep1gnKKkmt9EpWRNOFZ0tAQ0J6LR1xi96GbFMdg6+QqH6hHtDC8ywy
tc926nYA0W4eeftTEhjQVqb1OFwSZRQskMgd/lEidekp/j4AbMtPxNsYGVMm7UDQ
NJjxqdkUaV8JkekGQ3egViENEEcQqhafirfE45EWy5DRfBu2EDcvIXIgzzepkJ/e
LVsw1UvDr0ge4iEytRBnSaWwsgP3RTNKascHvraSa/Q7/J2qO6f0h3hLbJUwthKQ
1OJ4pC0TlpkOLAtjShBjbDSMCX4L7TRGD5qx7pqa6eLN6Bi5jq9aHZXABgnG33Vq
11CskFZvaHRdZmtQ57gc0SHk20blhXsGAsHUSDSUV+2/Xd16v4Fy9GL1XjU6dSzd
PisF4CiAmokqGyOsiMTZ2/zDujOlVuAphsWBkB6Njv/5gexvkSJFjE7Vg5XyOy9C
jrR92V1QOKvUN3MOVHEnJRxoh1IQ7trm0XXX50p8vhfVebjVsl0bv1v4bhoqp5lt
vSNziVWSv/grgzVoPy3dqzxZWxTAPF34R+ycTy57whtnycik9gcFnnpShTVKyx/R
IMBWZJigsKtoT/hdwrBBjrbawoK8MYpabjTNglNdCT70vM8oE1MLgNFmVtC+gf/7
SN073z+Yruq69+IzHUz3tQmuhwLq9hK9Ktla/S7SAMYZ03230GjEV6P3ph+l9tuT
I2Oh8XqXT2FxpXRWu4X6hIE1eWHEFMnPUKWlrn5VOgRu+cXKJmayEQpoT2Y2kxZx
IIKMWCB8jmPEGZah/HM5ST02e0vfDePdOGqKBhf8b7gWoV6+Uk8ZC4qXPbd/qaAY
HckjmwDsBuI8BcO/SO30b54YKNH1tjsJUbhDLaX0vMu6DVzP9ANnkl72xeIacGsj
91Dit6VqWPSKvdQfF5uxVqazP4kShDe3pvFGLBaYLWI7doa6T5caKTO/yMwDlKmY
grqG3OHo8HsRVZCOs1A9wpu0qtAymHAYLJwWvhsXUA3ZbrEIhgTtIUCkY4nphEbP
cTCluiOOOWVnLVAzJPtVuuT66Fw76EY9Zgxn6qaYUysKlq0Z5jna4GWlstlbWBvx
rewtdd0R8V7rUEqcagpSzSnAL+lK3cH/t5O3VuLf7+Q/JfI/3ub6qIHjg49f1WbQ
QqEaxxangYiUD7cyh2xKlgwFGqzbhQ8llKjeOfrN24BPvoy4QpSkRxOUw6dJljtn
D+VuUVDc2q/Yzfa8uwtwYAcCrWjtukZkVoH/uTvA72Os8Fff2bbXisqT8hDANjx8
ftX9vb4h+9M9hQ4JsXSXjnuW4xr2qXsJuSCX6xEqL2z3ncDy1Jki4cYxeypZK0Ol
35dYhN/9Y/5gV7U+Y/7bYPOlU0z5Q8L+owQa9gDxLn5FA+EC1HBtmuMd/NRAUyp5
0XmUR2BWzogYqq89XYPoLK+v9oJP5M+eBB9jbCuHuLGQVqnnW3/vI+PKOCDW2Mcn
7oIWUidq0KJlwZ6L7eaxEmqskCFAzd47+Ai2I54snd1wN32y0wdCrvfSiu0xIR7F
reHESKFyptQ7gIethU2PMwFppI6c2BtW6GdZEQngBKMOIvRgI/80QH1MmBrwLBJf
/Agmx7B2c60taVp422RWedEfkNiSXbq4p2MEIq3Un81+0TrzevEodqwRvZ0dQ/KN
YN41jZsYgfNM06crwBlLMfL34GAdFNPEL7vRlmZmimQMLyt0Gbc4a1Jon6A9gUOZ
26EgVXFCRUq8D/oN8PxvSqTu6GskAa/OVvfktdsQTleGPHO6EPygc0Y39Nq+1Kxk
0gTJZPup6pcUs+GG5dIXJmqaXuAP1ty5BLQmvc8xAHTXUxogQMGNPkPBdsBv6J+l
WLR9DPuIykAXA5L1qpBdBfl1QLB0qvQj0yzux4uHmKs2CAEdeHP6roGGIuSYFdDW
Qb+N21F/BLvQ9AM88SaNZhUFbzfcYBI3Pj6YGZIaGHjPUmRlfslkmK92HGsFt0cz
+NMt9oMm7BspsoCeNfOBllD2o+WHxYixKo5q0CL5/F6qo96IoqsykTTAZP3sUe4c
QLgLWIm8DHzfIam/B521Zswe00iFUUMEw4YIaBdUgObLmqnbiGoo1mVRq58Vitcv
tCg/um180kp7967YRDVoDybEMybSgd7iz4l5p8/+OfT6Ix57jIIenN3gZ0X2PDad
gnYtRzYkQCHHHD/2Ukq6hmueAvjsaaxeRhKysI87zWmoaUoSI3LqNre2iznC7boq
OOPD06/1G+HGtI3jdh34pqESR9LeGo3v+vQwW7xflam8DCXObaJQpYLFph5EP0k6
iBTalE8A/djtGbwMFhpo7JlwyUbotGCMS05L9XfZTb592IWosE0yePkf7sYtxJ3I
CEx4HB4+Kky8jYaK0S56dsO9ARhDxlCFwsBMwc5TfPvvu1nHykp5/osMVa8vqEgJ
V/ZHMizpgzovL+iuZVGkWpWuzAp4HDs96gbQmZ9oJosfqIkbMQF7L7vENW9BI/tC
x41Hc/zaTNDcMvGPq8uH0Jnji0hqI+bLx5qAi7Ei083T8/zLvKteKHA6I8B4sGGx
wQNi+7ulyDsUv3U+Pu9SUs7JBD27nmqF9QyD3EmDJehwO9x6P/lg64Sp6zb7aTNB
Hxuios2ewpGNEZz7PeO27+TKq7EsopaCjC7A+Jf6J0K8sEX/wZjndM0nzL2IFom/
8FI4qC9th7JV2sG9gpGpLR6KJVA1fkwZkvQUdqTppjA38lAA1hKKpHM1ax9KrGT1
Y1+8XzLFwxMU64VbgqLKGN+vK9fr6x/4WGHlrcZNK7mNU5BzRYpO+IrnJD3c6Tc5
9jP7Nduh6SEoh0qSW0OHEu8zC9YnfL0jIxZcl/sep3XrZc4X+5tOY5YepI056cBE
OXRtPJNrM6nVl6LTvgQyhIFZeAgr1ddc0iTLaHYFFmfegAcfrj8l4aqSONyw6m57
jCYqouuCjpJ1IBU0DKUbJD9a3414C4Pkr8CZFvSRjp1sHhcILQzPTMJ7SYydCawL
3Lh2r90NN6GmRI1g7wmBLw4hk0VHy0f/z/DUDha0HBzZZWcWQeMFfXS5scVu5/73
6FHLF3IP9y0VwX3Ry1RJ1fumvD1fZqBWxRx0ahucQwPKTMdt0ZnefyA8IKSkxfm3
f/xD8+m08BZ0338BJPfUwoDaSXVguvDcufE2WWWSWEM4c1DC5C3YV42k2/l0cFl+
XbOV6V2QYzZHwD5+l8LoVrlpY5Vm1Ib7LiAtGCy6RXsTWH7zYH7UiZsMgm5RkMu7
8au56vKSLJRmpsmTM2hzQluuamp3eEhWX5eoxD5oaRA40xOhzl/EBlNUzZNiId2X
L6FAd0YY/otKcuzXSgcev8IowLAZjTzn5Wg4xLlNYhGonI4XncBoAg+LgNNLWceA
vwadBdSOQ0hVx2IQDOirro28CRv+MrX/ESRoMsfgPR4hVlHVwUiWBZAkM+DUMWbc
PMEduIlSMbxgkaonwevDElDTwCxYVCEZPoWfJmPVFJrKW1BKDc8jhT8/DswIwE/M
GGUnnCTgB4KAPQISulh3+F1esQvZkJOKjQBgEGY7T3HFvsss7Q/vaEaHSa0gymi7
pz5QSkQKl7ueRnQIOpfcPz6FzXP5U7WORLzORmOQw+EukcPLuO6dUN6qzu1jV6QM
FlFyDh5MIc8EOX25DvVdwIKhVLPqS+zvo8bmLuMzUY1DCFFJM3FeFNIQRDaHAm2m
kAufSQeJnvGhufi8UDh4qHYVb3CEM6VW59YF6tK+pvniU83mYl7ABfZ8GjbUVf4S
fy+a0Hezmn61MYeJYBTkQZ+IC+nkbSe3jF0Q1FQpLdlZF11+5bKea+vxAjHD1qdq
6txA9A==
=ov6C
-----END PGP MESSAGE-----

Encrypted Message

[zzoru]

[-- Attachment #1: PGP/MIME version identification --]
[-- Type: application/pgp-encrypted, Size: 11 bytes --]

[-- Attachment #2: OpenPGP encrypted message --]
[-- Type: application/octet-stream, Size: 28617 bytes --]

-----BEGIN PGP MESSAGE-----

hQIMAysDYYUGZ9ybAQ/8C3OV2326BWkCo8dAQi6RgyBcTp/fmMsdbJPjOKNanq1c
Mr9dOPHDaZ4wBQhGy7/1TRaEMLf7h8/e4efIA4Dgt1/+Ubv6cSrovYBgDFGMGAPf
nMn4FW7k7RO22jqviks4vc3znHOPnjXANZSZH4C2g/b2jboAtSCL0A8znyN29okh
ZOyXhMq7mwn2/GViBuzEUCKZDNlQmLJrffu5lXbv//rUjTTVPTzOVqdH3UPKNpU5
mPGYH44vcs67zdXohsBWcug/AicX4MRkDDk+Z3Ih8OcwoZ93xxIYJciLaZ2ZrST4
1tdPXTg5/wRUvlX+sGJyeIAj9fpU3uGc8yi5X7bEKRA+89Mabm4LVsZPe1lrW8m5
SVdtoVHNXurEM8NzmDKiHpnoKbQeBn7oegqp59NxV2aoN51dBmn2pwPBjUQMpAdQ
hHSqJ9mXOTgAMviI1vYi+QriKhJAdyi6w0U+SBcsvzxqPGbQ11cVIlWoLMxQ1Wk1
Ixt5pWJapSJvvHWf2BtLGSd5qOTSwj80WJbL0upYH0xCpW4bpG+PMktM4pbg7bRG
iBC16pswwDagtcRjWcI/YuWR++Ut9ciuSKcaYV6qOO2s5Cjd7877sAP7/8OAizuY
7ngYRjRMRY3veWMaP8ZLbCMbrAU4s1ytXDHftBhf5Fv3d/3IDLIDBOmuxRurIBeF
AQwDL4BE2AK0I9kBB/0cZa9jDBxfBxxWUT6Who2VIHIufLdiSXRQqx+mbURJ8AAg
9NeQqoEDFb1CaFN0fYOESnPzX11i0SvP7lCmXdF2qniaYkMOvR2/6LPBVGsETdJB
596cdn+uAbm68InvXEbeSbyPlwde5tgHb+87sSijygXab0nwYhU4LeSA+QVxTauc
EQRlJODnPKQo9Z14k2Tv+D6ocAV9A31VndLdNzeUC1ZZgFJ8r6dsb9lUQQHWTR+1
DSlQPl8n7HjQneVWjpUf/ej6OGJphMo9lhN2M83oXso/m2CR77IAP1LAHU42H6f0
hHGNSqQ0fmotQduOk1cEOcxcKr9uaqadDRXEExp+0u0BqebjN1prPNiKJHgBvS33
sfNUw1dAPma3CuremNZoQHLl/GluGnEEk8CrIjTiSfbmO0DtBhboHIkOodssCAFC
MSc8x9ogLldl/CTHc8MuLJwoNqWwxb2Ulvd3WAfMsQZI11EWP25m4iJJlfpnXfwE
rZqnovJIkSAcLqI/vNGmZkeAJwgNwG+uPNdW15+lYbpNdXGRMJdtvRsQnbPsDUDE
vlOWmCPyRA5JCwxHX1165Bil7axiBrFD1by2DYNGjHHThWWJai7jxcRwtRwFd61j
2HH/HNTnhXkydhxtJPlRdrQEIMPKeG959Fu0BXRLC0ZX+jXZlU7tkLMi4ULOFB/I
10tI+sWHaHLHD2Xl5/eoV9DEiDTERqMCDVSXGTdtWLF7FkBYtcpU+rHHGEz4y82i
EeW81sW6Ar/jDdWCMy4Jp/qlEB5+adO/y04PI1Qka1J22FFamwAdxib2qI0NMNRu
FLgRwtHI2jFpO+IK9bjR+iOGJ2CX9NMOCImA6M75IHdI1c1Wi2EiPfa5ikEncuJc
YbcYtd35ZkmaNcICkhPE47gtw0YSqR0cjKr/+pHp/CQthcYY/X4e6enr0lEDNrY/
R5NUnKceRxq6IZ5NiMxPRdj1P4OnJizl2W71OMr4cmJ3ddKpXrLlkykjGjlwXcBW
hM7R6V/ohtxWmZVe+L1sZiWsNIbhvWNC6Jocno+zE49ZRqFNgsKie8V2HRUSu16w
LXb36jX46bFd4+b/7tcfe+wAAurqlvAbvUJ9+Avd2NavWVND7DyL48IROOZ6zQFJ
tuz2vwTSDqSXzxn/VzOF7CjrEZCDwg7QSOdTk2YYbMe22bpIMZnh6THqtsfFjrJT
kgF8VdzGzQSZgSun3MNef0guvd2VG1H62hGsieXZde0v/BMUiWndSpddBBkK05Mu
g9rmoIto2JyopQssMZTwlWTtjDl3BUakRYsEY8ptGpaVKAbHFjBBZkf8040eBi4V
o1m9JN+Dnp5X63wMFU6F9BtEnnWMXvFyofCYpRrUjooBV8A4ULB/aVKJ8pFpBF7a
/57mhzj9x6u3rtUEj8QyQoZZ+UV2bp6I9av/6ivvfrIyCciO9EqtJdqlhQgENM0o
EfHk3FnF1oZ3AjYHPK9uchoMaWqhARZOEisWXSiOWhpIJcGpw/O5ebeWC+mK/4Hn
2pyqW09xLjQPRBEjutQy4SB6k9nnCtt96wgJGXYMAf5qNC4kYRNoPonDN3C0MYAo
W4QwwYg5JlAh1NjPnf6yvIyFdM80ahtCRoNBOQZDdnBxO2gQWmV/vgA942UrfA5N
J8gxEiS935MraOG5l/Krk7iFEuvvlzPkLLEPU7flaAQF5q0VSOBO/qQ3p9Iv7R8Q
W6JP87B5d/cPk2wJflzDQGhYnF8IbhCzKuWzGTp60zEWyClyYjr1oDhuJOVx1uM1
KyOUWlXOIACiXYrxKUPJLjGfn2fWQvTMt25Amx4tj7WJ4jc8f3jT/C3bMXQkVFvU
QZFUi4KJlgUZGW+fTq1CiOlSkee/J1JEKBz8MSFA8koDwFE3yhTOt/MXHudnx7zD
A+SGVnlRj3llAsK7DP2ifT1FV6cYsxV4WnuQrUObJugkozdn6JnGmhsEciBS/Byf
4ImBI1gLJxfcCGP8PWbE6IjJeZjC95wuXe5Q1770yqT7GOf3d5b7hhE4O2RzAW4X
zNCmtoR43Qwm630TT7gU2hQgL+vCr/NaugUH3v9e+E6hdCFphM9nc+z/fKfm4iVF
MTHX1d/UWOM2hbbW20GrZlj0ySbbSrbsw5W7dTNBlriUybZMZxh9xp8210l8uUpF
nI/L130aS9rZJ+og1zRL255/9l+T05iqoAiaedAFIBwO/FOyYT8PNznKkM5fBJpT
n0VBLEy65q4v69drB2L8ySfCrSwXjNWGJPA62IDwt9TdiRvI2duIKMhLD83P+3aj
PQfOOnZaFlDFUupReHczlAqGNk3cu8OOHP3S1Sg/Gp9jC9Jlpz0trEZ9Ny8kN6Oy
dOT20ADSTmX0OeNOh/vxikSUEmoFg7IBejSOBousDA+OBfIG8jTLL3BR8FcvFVLw
Joh4n7TUtJJajFOoEBq3X/JLZ4JYivYzSZ6DfP3rkD3+z4nGVIIBscjUpeEkf89r
AP79xaUmPJdWnZz0EUOhgwDJhGqokD8N4sR4Eud8xHyU/yQH3SVZouow6Y6I/TCE
ksLdrxKDkg1OTHRRpVw5RrwT+wglS7NjBJA83PV6cjS45ZoHN2VE3Lis7IzExvOy
3Q/MkdfwpDztzPCbor6Vl+Mjo2PjfbjQ0LdKDKw64QXZAsFJ1cYkEpn71MkiN+W/
15VRUvdotqRZdr3zTbKpVDYivveQdW1CO7dy6bJWX7yL+pZTJIRZF1rQgl1ivLK7
aCrc19jcnFX+ZFuFMeMOcGKSS8+pxQI8tjIATNZzNp/uW2Ku+VzBs40L85/jwXUT
jyruGFz2GdCYOkcopJUTWkT5jWY79+Yg/zbMbkLS6U/PTJwN+DAcWeTQRD8CIjgE
PPNuuidv+V5Fmj/luhE0s87gWOtmK+dylBnE/9i2d3NwRoDGf8Yb0BlnwhcjxWbw
H7ADapz0QWC83FHrc5CX7pXjSeSiHjwYZeWjxgVlRqnLsexMpC7eSHDJ2U2zaYWv
aTvzNH64hys2xuIRfhkcGqSbnqKYe/RMHtikTxPCfYYQPyZj/NeMh7kS4YVoewTF
C0FHC5rYzrOwEo0FMeTuC6wjfuZ7aNRPHz7OPzO/NNMon03SfoCyPrLtUFPZh7qi
bYi2UY/Nj6eWpNMraJXuEuKOMieEto0G77yop8MkKrHz3JAb0HvbLzfDUBEB0gpp
x5aciWGzYXEVDb0lJFUM7cRaMuj0Iu49bHXCjYeL2rg5fpyv9T3QNpyMTu4F3TOG
HrgPulyLoGXOb8W0cvN26fRZWhhB4PspqlKIlB3pO9jkQ2l9PITsqgHLfinOup0z
SCzVtkSkWmENplivcpCz973Lwr9VDT4vxQh07Nc98EAQguS7psHVi1Jtes0QUXAu
njJymG2lbiroUVkr4eyW0KWFRCAin0L3HDr78fN4Q0FqH8eAQKh8ei3IzuhprX1R
ZiIlbkQJdC78/4qg6YHvldiISXoj250iZAjqZ6q2jICbGUGX5etcj9O5GCwaKk9C
F7pWbpKVifRRvN7k6+2ck5XguFr4b9X0PZpsZhJSBpimtVB7DHS9U2AL82Ap+ztq
pMkMXRoIMp5FdxiRqr6flilt3cvr8PIhgSJA6Q2b/gsxjC9NgHSjOSbeQJtWtIQh
CfMv5vkDkRN0xCmjIUa92+SELPO98ko0eycpBRsKoR0eR7WiiZWD/6SRz7UyPFyh
/8hgy5sX0YRZqLo/2EEVOR5yCoXkBwc2dEnkDhQ3d94WpYVBxUa5zpOVDfzvqWCl
2ByGyx1OyhyDRY2QSLjVJQnwvNuqso6DjfHkDLALI769LTBrc9cXngXRkvS0BkO6
hDkkWrRabIsMAdtSxR+eCTQS2PjL5s2vuKuPIxAdDvncT+a4waULCmKDI7D+8ynL
FZmoyMgNz4FMH4LgN0oCUQ1MzQS+z+TFR8FzRRVu3oxOS5asrtKPa18y/ADzsU5f
BTTb4RCsZIF5QHjH3zLiaOjru+XDU+PZOsvwTBfHb0arsLvMy6uP05Eek5wRc95v
Cexe1yqUZcioRpf65WomY1i63lsazqnnRNOikZZx3Dzid0qBe1lF2hqTS9DkPtKp
NTv0tbzxsWo7MuRR2xR6QaL9TKvUwCrv3132iZFxwH0l3zcTW4r0e4QVoL2U7zz7
HThhek8PSGIKZ3qhNtvxvUxJMMTrPPtTzmJ92cU5+ibj2vKFvg1UpGxpJfVRf1NX
Drv9CJJsGF1g0xywEwqGAsMZYUgxj6VO55USH7znf1Q/qlROGYs3pj0DX2MXSCFc
A5CJvDwIK98R+MksZ9tcl7yxx/cMPC3J8wEFBMePx3UfTL0Nr4Prt6bi9RBYAAQy
JsgkTLQWmvtgj3F+5lqPJ6PL58MIAzpp+A2rY3MIo5UZTAxVurq81DGXxRalZWYU
IRhX9lnwQn9K4ADxaedkv8GSItXDHA5PpoULS5OaEtUJOoOUeqlumJYVzqhxm8tc
j+30gtATzYNLT0fuk507wYHQW5iLVgtt6rrrYhfXqmp8LlwVgV68S9Tg3uq1NCLj
vwMkeXoT8pLyaOVPKuwtY4+km11dJphvtVseq2KbJWZ7cnT54HJpp4hZ9bDiH9EN
V4bIKsZD0Wp/B8tLVIukk9shNY1IqEhUlgu0srAFD5UBXnIGFPiLL2ALMgz/hn9+
RxlqZvoMuaf4DbSdr57jeSy+irxHuBzfBgKVfcLmaoVP2v/gb2/Nh4+VxMfViK7H
6Xa5u2iSK/FAsmHUPL1htVdAkPgfOtBog7iM8flKQiVfbRifWv36SXa3sQ6b2xT4
x1v+1L25DzLIDHsNDcCKHgwNdAG9KXEkcH9TmgV4MutZUW0Frx+HsZs4WNY3AHGI
6xGXZuFiOlz1dJBWlNg2Pe2vQGhFDbrdeDOUcc9m8RndcshDMis2eyJ5fiIAXBTA
qOm5Il5LBVzp7KMJ5fpHss+2/Y7/vgVmg1cDpFQ1H6lca4+w1QheasRTBV37oFOa
0kDlWwgEcuo9qEDUOVBglZ1x0swf4pJ6D/WktCjB1NVnJqlo168WIqUstMV9CGfO
Ozb2Ctp8jMJKyRlCzzMmwXrz7zhpBcNosjz3NktPo3ohbcfhaxIpiEINobbadmK6
qZxZKj1cf/y+RgHEvvkdLzX7OD13kw9LhE4hRVkbeklYHBEqxx8tm+WuoE9DI2cV
Pn+7PBj3I9aU8eq/0tv/hwkwyhMbK0qoGHsjLSCD5oNMTnITfkjOS7zGqukPdt6p
Y1tNojlemZ5ZszousBdzsZSrN68VCURt6xoTmqyaVkczLF2frVzxeMxjJ5t9OVga
Xz3sySaHxmFoknPVM7lb6Re/PgO3Wiu9EOvCHf8Ypm0U5Rls9/zknmpZ7zMU2pld
wdVbtagf9SFgLi03Q5wI620n72IDJNSY1hIaPxzS2fKgTsYCiBVbq6ehSA58Lyei
BiFzlI3AmjbPmAQ7Ku99FakaM52LgumL2vacNCI6CMyKLKaC+/QQvmotdASb7Ddg
lOerNOiHKt9eePZIXb3zUAqudmEakyA2Meath5iB+Sd6g+3N3OrUB1fMYp3z8P4l
Y9X7SEZBMVj+hZ9xLfJPvIzxVOkVbZjRH1JgHtpSxP5pOyTZDi74cEZY7Rd1MBkh
QJJXyLA655LTW/trvhikp+YiO/UH9nmFQhJtu0JW2ESCge/0ynM/VEu7YUpQNhnM
a4ColHLEndQ/m4AU9I7y8FP3T8sOYEuT3jExfnBAlcvwmQfdCZEJSpGvQFi8BokS
K1U9rv5sh5NBXVVhV3ISbjqF8zC1xR0xajFfdvJUqF+2uwZ/r1SJtV0qM5iIThO/
2eFxkZJ3eRGzeCxx4xAQH7zqlS9Ux+JElJ/8rJoqSXDm+baPA1UW4sHTDKE/i9cP
lYtNHTgQN7tpz7uYH7PGAOB5e91srUMYo+NSgUFOlgbavip9UK76Xs1BrRBjjmgp
FaTltVmTwzbarfaKq1xWHkI1iFIwXnIfRMFceAzfyVRYUAGndj9O4pzir2+UPzi3
ZPLd9Tf08M+bKDjctF0h0K+P0KKXoypVGLmw0zOoSMhy+kEIu+mMocvoE5UsD9DF
0fMJVr9C7eHqrCJRMLQqNSwUJv1zUqWQB+XvFjU8CWX1yRLejm1mfnHDcwP7Hzaf
l78wkClMOU/l/d4iMIgUlrmt9l8jtQy6wnZhgLIe8M49v1I0m19IQtn7ZcxtrL9U
W7h+WcR0PPtm8TekLf5imKY9dkSa7njahKs3E2AQNEc2MHmFgqdB6UHSJFeicLRh
/WrgTnE82C1S40aQnPfa0LejG+c3TNycc4Y20d+6ZFrY8N6S9QT3MR29rvIwe2Jz
z4QaapQaTJJ3uwVKsrhYxnxkIoApVl3Dd/MHAEeJiw/ol/o5JfiCPHwfWwc7v5ge
7641QWzKfMmSwO28sBVYarn8WkCJAgwugSCcB3bA3Q2hKA8c3MIigPlVhGf1xG0J
zZlVZV+kHVq7640r0o9ZKQhYP1PKkihd66qw5vj+niiIHpjKaR3ywJbWIEruYXzx
jmq55+kGrikwlHn6kPZiG6aaO49dt6E1ucfBFHYddIHx25Mynk2Y3ILw7Du7Lik+
YywrwJLrwTMs4ncePboKZLHpWefYXS0xTDI8eOO+UKyPr3L2DtlPzUmaHpB0JIfQ
6O3Nwu/EzqNxiFUNKkkN+pka0CDQCqkt4tD56E/b++/O/9WQ1GwtZ+qKn5XLlU/d
BW1/As1hp/81fR3eU9lxyZFxyEuEps+gu8sB1ig9lMk7TFMlxn+ePfjkPrzrgNkT
oegc1hV3VFmyOsDZWsb3j76hqrjF5Sf69MIAxgzxFr7b76DGDQqQxgnxkcA30txO
K70/hU4bzd02MYibLQdWYSlrhzawITd8hyeytCGm/VIJU80Qf+P6qNOIct2xAjLt
kBF4axety2SmwqNdFtgsZoXQ6ANbf3JLRvhLr5/msPDXYt3bGiJFL45ZMJy0CpVT
JqGzce+Sb83C6W0pX8wXjYvXgOBy0mmc7EJf4hdR0wnQKltveyj2322qbHCmLcQQ
LYPWy/7OkdXjI7njP92+GgyUizAprt9lZAoCRulDFoRCZ+j26gUs4pgeuyvq6ZgN
gkDnAitFcYcFB6tA7g5AI3uVH+0T2zOQmz5hZOBf/RKCW8CmyDqnKNSfp5DJ+pGi
s+NrBrYEHyuGN3avIe9l4daCgETWOvN/Stf7rupobhC2X4d0dgaDwlfe4zIthjq6
6OcXbj1627rWceJn3BHeTYjhvrWjri2fnWdmeogsAkRYpF2wdTmpgBQX8MiNKUlx
gShiHfykziL4KbMTtxMoSxX8SfiuPFG5o9ul+Igq7gY4pn7mUw1+lQjW43ITxl7a
nNTm67cHz8KpC4eDpnp96tEDcIiGeSZJnD/2T6E2jwu8l48oRUcAuQD4T5CaXpjZ
SpEv18zlDH1dUIgfpKC6n7OrTQPp0hes8fbS2MsQvPmBVClr2utNOc2FloEfyagA
P7PAajWE888q1U3VU8LSya0fy2qMZ6CWrdsFte6/V6LWOovk/iRBYsAiLkLIXNr6
VwfFx62rbMEV39DF2Ap+uaObyLdiYYfN7b9yPE7i22yu4tOtoCfWevxl348fkC76
TV1/ji9ArHEaGsYrX9skg1HKQXKCRshDmpw96zlv2KykWaPIALW7RB2d9zoJ6bl4
yK119GGACKmFJ11TMOZu5OKhQogpjpBXfQGcv6oHyTO4XrpQ5FktkEtOgz2FZqsb
QMQPeGvoGETAM1+yFDlNkLqX0xzSkQpdMV42uE5Fxzl/vryduhxjFfkr9s/XdIpl
v5oey6aU93tYNJQ8pjpfRkcuLe+57cpGmCBQZFJExflS+xQVn8PV+MrQch3zpYAl
c80zWwfmU4IdVilyr62AY1+p9NSkCvfrwhJlNsss02ghH9jd516EBuu8d9kfsxAU
QUWC7gKd+01uDJZzoQLJpSF70iXn5WFtQ5Swwwg3XPnNNYHpRKZFB9TuCbhiakr7
9+KicTen+28eye4i3NQLjJo5gunM09I8AhCaFC/k2yopjR4fo0gtR42LH9lf+kCG
C7NVTa1vI2K1v9/mH9CAgis98v0gQSU+HTfP5NvKkIc8CgRtBqODTa1x09zLyBuf
76XWkDyatHpQQx8G0AEc0R/3n12eTSv92tFpCLUQ5O58Iga1nJ102a5RO6cMfNi+
ZVOabhrHxzEBzT71yDJJnMDXRO+PfdFKRtJj3ny/AicVO1XQPws8tolyJ9osfNgQ
UJSXeK3qFlogT8ltLkVQci3fKx37BYBkiY4uapJBxbFA9ND4pOGAPmH6n6BWqtu0
XWLaM9kXfRmkm7IgeSAS88WtaQN2ht4k6FsO5rnfoIpsY3rrXbReCPcWNl/N7DJe
0lzUGYs8VihZJW3A/19EFykMY5fsuTT1sc3E11tpGIkdf9b+4AjY2RIvUANffUe6
5lZw2o990atr9aIlRIg1BF0oEZGX2vHpUsCoc5t+EAA6TGy9xaW8sMUeqQL3qKRq
y4nZdp0p5Q97KDRyz3W7aAkzIEPZJS3m5l67mlTNBUpV9fZcTKfNmeSd1eLpHsoX
HrC+C3Kt4oHkBObcmAWOBWlXxe+yyt5AtBzl74MiWX3oscyZ66uDb5nNtMyijeMB
z4M8bq6s3vRynxcw/CsF1Qv/C33RHfXe1NruGPFncOKsDrscB3fH4UFxzzAOTA9u
sjjzxmL0qudE6H15Sted2BjtT5NW3M3vEjr9+QWBF3N6+8fjsKft9TTe0vAjYQbF
Eg6I/3QTFhSpsv8EWZ6xOLOBoeZ/4iUmyp3FDrQVH2hu29tXd8m8tJkyR7KEIdV9
6qD7BNis8r3AGJpq1vmSOW29/Aove4hiaoqH4OAuKW4apFkXKBJs5htYI7Zyc/ar
cZOwX9YVENYTPH6V5LPoFCsIDwv5yY9Fx2WbZ991KdznmVlurdZbWBLIpi6vfGgd
69xmkcMXAPRu7ZihaCI7qmZJyG2XlseP960Ce0IQpTNNMGfMUn6jXEkUXroy/EGB
jBk0qXnELq/0Op28KA+WFdKrC9KZ98g3WZy+MCkAttkz76MVqoghpzqy8GVt70V5
724z8EVvrmzUlUONb8wYEpr8ZwutGxSSVMfOTZ4W3YLeVThWdI+n9KgV+FnSSqI4
PDKL41gDhAVE2cDLJBhSmlRoUjUuJa4uHKkRKH6rGITxrzeZIvlCpMAru35SWANn
snZxzTSPZQmIxdNiTlQ1fIE8FzIpGpufC+D1Da0j8deLViI4/lODgBtJAZz4MhM9
XiU3oGj85hGvTsUoRhn+wmaJo2vgbGOqYE5HhZYYKpU/D29liyxFQY2siZCHBfFG
+8777ykYyTjtGXzdh8LZy0AcDaMVeQjOSR0hqV09rNh5uiG9VkNiUURsDAVuHL6s
8EZkg6TWLw7df3xBHbaa5Vt0w9RmR3Pu7p06GPDx/F6aPpXYuex5pZurW32P8NW3
DLp0Za18QBU++J9DSqunfooJ8MsM8ZBeKYsy8imq+tiR11KgxuwdoFlYrn7f3kdN
t8Kstukr+lNefBVYDq5E8KSCDMtEVrJpKu1iTHY4llc6bjItpETKwL7ZMB0E0Oqu
phqi56EEedTrtVj3TCg0OswtD/GfsxtWAiVFFhgESSoKbD27pLkqtPqurG2yJIVI
7MdYwcc3MINiRHEB9SFyuKe0YmUS7QFuARnpSQuUyf3BQCuidFHLZ5LROmZ3mKmF
JXA6BtKa+oAClW/eXijpEYSJQlWj2uGDW5zjVKbHP3xqcBJHckSO/FGwyx3kkYrz
8ye/pABoysKwAPKiUwASiAkxquk9Cktwh2TTrdT06p8J3TV6XwhMZh1kWrwVefHy
sqWhQorNrt34ULmWkae6tlvKs7W1m6gK6K4i4Uu06vDskn/+gzlmU8YzkSFZXRYQ
BJSGoYRYWwxL+8+slneBvSGFcYCrTtKCBjd83Ij9fEcTct0/Upg6Z8kLqO3ftOCT
O9lgw1eb6zEfxOBxgwqHK2GrJqYYOcY+uplmP1TF1dHKNFZymj0utusLRItDsQOD
BcUVzsZuhNYioBqiyC9w1L5aR8pGNa1cYJpXRf+uaazsCt7/4EHl22+1bDSYoeyo
jitc7JBdMgh6xlRc7xfQRP5wtdxsWinJsrLqC/ZqhpoIm1B1Oy2bbpxnw6cJBFPI
+0QQ7grCCBVk73vOU2Fl4BjvjcbZ6Akyscf/iVLJResBWk5J+1lCx86U+2uBYeb2
bMXDz1OeFvEnZ58isvGG91KjIFqxHKKp3Hl47sI9j1HDOD8VWdfw5ZlRmQLmoqf1
p3DnZbqMXFCHBgSKvBfkbYclgipc7awKWqRV8iYK1AuvJa+bx8Kwie746EoYcgEB
beVaWjbbCfdKq4wXYMJnw73EMOTz4Yp9LM5omNdn0H7dPgeJePx3Q/pri9wO4VVf
i2xZPfKpuDnJS7DhdQrll1CW7h2Wpx+jcqepEx9xsUNi1LmqQhkXmzVaomo0okMw
yKIIPNT4zdo9xxr3xGSoyvpa5v++9Nh7cCv8P/dXcRgEXUaQC9lM+F9MoJZAuiO/
5Lytiu8FgkbaVdzlA+MF0pq2/4wT160hTephqrnzNmFyQBVN9jcqHrGrSY+liJp9
zwCnbrA0zSJj0XOg1GuYxoXqcdSIWnCuoQG/dTjbcSlDV2BdxcIxhkgnL/XvtUBc
ZXMaGkNmbjoNT48MsegkcqcqsMzMisPSaM2BWLxKyHraUkypzeBwbTMJhJ7TZVIg
NTaiqbOTa+9zxywPo2e4R1mYyrDa6H0Y22duHmP3O9VlFgSTpUAA5DUbI216kCD8
FSONDkj766aZY2jERvaJgF9JAD9Gr4Zj95ZcCPt6/bsnoliUmo+g+ERolei05CzQ
vzQ3WW6/Ew4Q0WnA8b0qdYTk5wB3ojetcMm6iC0qrZcsa5Zy5kGPCt1rV9FviNa/
xyqTxQbPyr+rf/Yua+IGDW6qaoRfi2qGhl7M2DZrt7wTmM13FIao2zqegSzTdes9
mFzV3jgpJuv0wghlPfVYBil59ja3DR7gVlgDqH4ECUbumodhSh7Y1jMNK/UkPhq1
X48pjP8Yz2O8V9gWZm41d0mJcZg4Z7T1X8CDQ6nBM0Sg7+4pW/9ysF0q++XOHnX7
uHo7mQtAmyHpWt9uV7Ck8j5VBFyPQea122fZfvXcF9TdZjm4PpHo+BnzaZoqlp9G
mE4u4fRCmvzbT7fAuDUXVT0Pp2K2Y4iWV/SNQ65LE/D8832ccGzpy1AhP7FxW+kh
0kjYmegneAn+cXmLxFLtcu0VQb3nfm35CIqEEeNtvLTelwWDhGpy7Hhf5WReXm2m
F9ewLHSs+pJslvToLKH+5s6NQDf2ZDuVfLPHFRNHwYNUFWkYPOVE17uaBD0C+JP/
kUATFdhLsruQMuvvZ/h1nVNgC+LGuA9jKC2qHGb0jEvyXor15niqtKCFNAyBhqwe
rkV49un4UCgchHXVhJ0D7vib9HDupALhMqL62dre0aqatd8M08HCkURhTtKWs55X
ExQetgVI5IvHJy4hX4rtGqrjYO3HluGc6mteHmDbP4+8cpVg+4FKfBFQoPybimiN
YSHFKYVlMIt1fLW3i/Nt/DTSbkRi+Eh8DwQNL23o8dIs1xxwVMf1U29cnllVmVlL
tpDfuP0CPiYP6Vg/a8q/9kFh6uqax3Mn0F05OfUT3WM2X4xPm3JmvEY7DCauxXqz
jGiDbpjJ/3dgejc/amXWYZVQjB3OSfdfqx4aVO7HnVBhXRtU7AZFCMoQLKo4tY2d
DbHnTwsMvXnC2kYdsI4jdzJgWuZIwKMwJpqRsQHRq7qONznRX/AUZAlEyv1oFMTO
H4YkF9wDlQ2YGSHc6Fx5ijYUYsIL12BndVQPWUnOJI29MRvyDi76UM8NT7GjgOU8
4v5qe8z9wubTey4y/DM0ORcEBWx9cLl87KV1IkWp1CTCd4Hkw255wjMQPBM7oISb
rZAe8VQqKNWYdT5bgjOoABDJu72U2iqMbagAOI8nDMFvTkGu2gMbBTfaL4oZx/s/
8+h4d2HF3imflVYKEekWY2UY66uzfeBS/kn+vZmHjbk9O+dSo27XbemGFYrFoGfe
YsGnbsb6uChoSjMNsRRHB1gP9/dgm2G1p6TEZdyMq1jioc6+4oIEbG4KbEP2X4wC
oD8RCSq8CiqDTrcPLhRhVSKLBaJ/x64CcS0yV4hmtnsR5Gxkd/5xFBxhzWSE3U7x
vO2VcCLg/U/tjbAMEYxAzhA/DiH+GOdABPp0h7HC9bRrQQS+4BrghPDQXn/smHoe
a0QkRqmWhnbzVPSxMDEr5lr+uiPMPhaNj5bZl5JIDq7smkL4imoQUnqRQdwZm/T/
oyOgFTrQ/yiqrpNLPD5pfjwa1ISmGO13lVl1x5INSsN3crNl6e+/XQhd5KK7ldeu
HmjSCwVYPv+NI7O5ShbCcim7ugBzCJ8IHE+B13ptDfhpVpfOHPvkYz0p8C7wmqMW
D2We2oaCfbLo9Gh78g8BZCnfHmuLn9bbwt3POVCYQzjOQaP0nOJGs0gvt5ueUpa+
3vZsrKkIdYCf7CcOEbAUtLYnkcMBWav2SnpLXKUCNC8R5lAqpJQhwjWWo89xLBVP
aksmOvdds8JBfKPHiCwrwie5eOi60fpHyS4q2DBo4ynJ9AkKEBEca2gc7Q3c6gXi
RiBDQnok1f/lLFfDxiwe2syrk+xEb5ast9fLTBKp4cfwV108suOUYx315vM2GB4a
0S90A1ZP25jocGQXJb442H6/xxO0gS64Q5HQBi7SqzSB58FnQOtrQOUK43yObNM4
Ru1p5D7ayxPyhGmhdYEaeREgeXMe1HzUB0IoTyWf6okwnNQ8Y7EuCQDiIVyJPD2j
bkzZLU/w3KpD4KSOEyqbfEj/PHxZntDuPDwCHwbMDzeaI7uWX9DJbnJxWXRz+ERL
v4ovS2XNzYbrlVdEonSfwmo6H5uyF7y3mai8UDO2z9b2LTW4oByHWQASM3ue375r
ohswTlT+UZhW/hk44oHb/la6wu7ZOj90Z0cCxCPdXQcnaPmkHnS25T1W9ahWox0b
PSeiQsZiayW4v7OUOU1d7qBUH76p0JcWyIJ9wAZRuQ6nQUF+NRWUu6qUPwZOPZmi
9sUFfPwKXfUEBVrLH2DSQrABxGTcS9GiaQMjh1vFZDc9pCZ+rgYr+JN+u/T9s/A6
AT8kPELyPVX8Y+y704ltoRLEaB91rAp+5AHU8E9TxNkEaA+xM3BjC/TZ+R06Cuvm
mxklwtmL3M8bUWMm2i80kAevwMCXbESLYDpXoRV252jX6qvYruJUltnPJmj+EYS1
8dmnHmAVcRDGOF+etep+uRhcnvYNCCxeKuhbYlts3ibgGBch+Qak/hfCh9Hzg3LG
ayx/i8CG5Yj+WYmOJpYhCoLRmgTEey0jKhgRXgR6gdkfl2hfqVtvagCCaw1HlzLB
Mv3o7eTkGSzZs3Y69dONGUe8cPN3mFjEgJAgcpL2q+Zk+78k7qZlJwOXfD5XEF5z
JUOuOPdKWdzXF14+cmFjIxYiyz3ni18mUVOBqNJ5/v0X3QKjI4PqLBeRan/mO7mz
LUfWG4SOCNYg93EEkU+1xvWzfJdJuj8YSYT6tSos6peD1yqpj/zKHMF9EtV67ipd
LmiYXMZCR2p5IvPtpi+0jJMQN5IjSf4gF8m3Ljywh/fjS+OXP9DHy9fkLcj3MqyM
P6ilQkZc8gNfh7RslUjPG/VLombBnmXZsH74yG/gO1pCKP8ImcxPsFCV/Ijzn1s9
ICrGnUp/zUKpd96/x1mqMqt63XTZ8qKXE9SdTbH4URpR50kLpovChPKUDCgAfHb5
hVar3knoXAkD34g+zrZ+etkQsNozvE2dluGEJW5nLca+vwd107CR8O8YL4xbYRwo
bJTyk0HPmt6K8BXjx5A7JsUdlfZnMsNNue1lnwAnq/ozaQrakLIwqQ7WWrYz9pjL
eZUgIZSk48QyCBIkaRRU+RHVKwFxDPRhe71prNQqZRsizfnYNDmNr4GRpnlG8Hb3
QnNCirT05bHkldbk/eDNrGPbtF44Ffu0hQESMGsQ8eIlNxyUqihG3FM3mmTY4uUu
8LABwe2xKoNWLeaainQsjKOR4HkYr7LKEQWaKL8xXHreXBVAO3BHSusidW+0N9Ww
V4Xv/R+DND7CZG85ysJmfGLUs+ANKtbc/JbDoL0R48kdCbBZNudEHR+ipqheoRKP
0sMws1AkGskVnYehi7Qxla2w4dH3bfADZ/fiOHcbMqDDJoWbPbWxOUHHXMP143CD
315cDv3MUAhPQI+9HCge04u4+IgAlXbKQfCqD3zgE2nRAgcE8HeNE71s5Y9Xw1nG
9gPiBu414sIacN1fyYRDu33d/DjGqX8Nbvfq7yjIQcYDeYuk2+go+o8pFNhoSkz9
/OhqtAtO7Dl9OKvZt96m474eSlri8Nw9+FGCvZxZISMLlZOk+ls1nrpcFMIuChQc
aZt+hDY52DmKKy64tmJWNzLrtlHrCarD9B/W+eCXuyZZVxQxklgu5cZoolkb7XDf
e68SCMRD6/rotoivtQiSfsMfpuFRRdGOZxxU7AYlSI2Q4HCigIyrGI7kviHW8n3K
NMl4w93Fq2yiuNkbRg9G3SC3GHnIQBDaIjsQncbqLtH8BzpkCB3NdPh60jLDvJUk
f+v61PVtOKrZMQ0pk9BChbr+M6M+CkrJh1BRc17kfOtnt4JOVLhCBo+HTBWhdZF/
lGHgU2cqprrbobbEE2yoPiKphbUIgV98DXV0SWoWVGF2m+X29NbPMtYyvXEts6Eb
pXaPkl0fbwkZU+y1i9k3OzI/qjSeyV78lGtKurxE9KucA91yR6wIkEjuxJifL60J
Lda0xd2Nc7Qz2zSeWba1QB5yRAx7rrBqORf6r96HBjF8JCTmcKREnusEUeG5Dt5A
+wjTPLy9E5W9NQqXpAANeqbAfNjb53PSolBxoUyj49YbNbW4h5vyQYny+jmrhWUD
FfASw6OACtCQb4WP9DkRMb9dj2SqwUOA3NIKI8aq/GN6aFQzr1LiTtxUaVNZhNmj
mBK0/8xevn/QXrnwi9ntHOO5BQ0oPQTWNM6T0N4g4XX91ltVK+iyhdMvrqGmkOBF
uNIL5yJuEJryEPSGhoCmnRRdVV1U74f+CJ20H6dM9I0WrTjdadiAVkGAjGzo6ENe
asKkT/DDiaLVwj4iSchpvrnGD9g0g+wngA7dCGhQipI58N1DdUoD2kmb8nMsNGFx
2US4ZSSTSSQM7Q9X5E6lb7a1rWu9bDuI7lO6I6iTWnNJ73juFOOrdj02v1ce61UP
S/9N6lgIPHby2mAW23B8qR+M/Go7z82UIP4OzKyVH12T9mRABAbavJnTfWbEbsjD
i+tw89UcLNkqVfdbEnNiszcCLnlzHDrNR32PgQyepFQhjDBfOYGPxJ0BR61OPFKm
LZkV5ui+AqQTzEKl6KZ44Yaseyf+Q0Vo487JeB8XPnjznVTnUTwRmitLkUn8eArc
r4MOAXco85H8CBirkekboR6wDfg9Qm6MELrz/BfSuegBPEeBq7J6xRMQoSIGHLhD
N3VILWbAtDcOf3/fXI3ibEzVbRKTGkq8czFcljYPWrFE+Cq6K48+zqYhQJPQP91W
KBTd2d0gObaBqjdrq+mK6maxOzyvBddaGnK+ixwOuFCEMUJhVqIj5lLlxs5rijCf
Vb/l1cY7DI0wbUXUWFLGSbYprnFJpG8Zii+AO4ZiWM9XgVXeDNq3LglbNnjlS9Uo
8fQLcZ2CfLzh+6m7RQzcKWICED6DZPHeXzNgfy174ri+ono9HVH9ZMag4I9vvFRt
Fp1S5VVHnxTrsw27j6ulx+hNQF2rAnx/9067C+Y8Jk1U45kghZIWBDf7vPSIq4/1
3oE4UIZ/nofkhO5UXZCXi4Sqjf9/dTymsxMr4X6bUNToCbe97ug3CIZVO8q0Oy/M
u8R+spg8XG/JFcInoGMj0leMxNpwmM7H2drkSiOR5+9Y0Z/s9DKpzF7BxfX6A6e4
QaPsjeYz6wx9e+BU45JN+GdQSOoop/NnuRWT+U2a+8BErIr6l6X3eaZHKFvDNJ8L
ejspvaoJuziZyKOH3aypwqdpI1dnpBN/95sCPdY7op9HtiLw9DgNQPSdZ/Kk94WF
bECjNWGr8omw/QNDMpSGvOIbw8xPFgFeg4pHUqYUXPbaCjpl7Dm1EqTBy4rm5EVB
eb7xmzLRDvyOC9WHnIy/M1q8KCsbInqdqOEp2XMD/6shRVwLmEdP5qiTZjwuI95b
ymCZO3JjKlL6cdazs1yIh35RA0yzWrPPt0NJhMPJHrvYxAe9Zd7GzMoLum6E7vmW
ubFu0PohIu2uSewzFcJOFErrkC8efm+DzLZFxIYAbpSt8rbVZMqqOCmJX5nk9TBE
Iq3stImG5HiM7d470Xdu2Nl61etpa9V49pjsQJCWgntS4F8mXcDhL9k9IApvanw3
2fZ0fiXyo8xw3oyZunC5V0N1YvKe2JCgr+dsKqyccEaKh8OKBcFDcvS2u2OOdbWo
F6cQCCYxWzfowWyFDHYiHlTCE0D7mtQu9PY0/NuL0y1iltWQy8k51fPXYbyzPRVc
Z7/Mr9M4Rtwos7uwOfPfKANEWKRKsk0vluY+++F0Np7AyO+7D0c6FZdnNGL9cTXA
bWLZaCyLq95AgZwKLAlN/6LgjDWQKjEcmBVXORi1L/4E9m8eC9Zq0qpRmDFkmHLe
tmKDXDHcCjnrIS/oINsLVMfZ0GV5Lzh19VnvSzJIetr8f/SE7rSb8s3VuvolDAWz
mI8sZ6DdI5aVe4ldMVEMVLPofwlaAeIWcuAQcTjSt11Bd5F+lXzYKMvsX+e5/mMp
wSlXenZCoEwHbFyc1C8rx6pe8vOyjj8IQVZeZ6PQ1VfTGNYWO/PiWI/0jShknNNT
q5IQnZh92lUDLoHhwjThe9e8AP3U1bptz5k0g+3tvl8OUt6Ea8qz2SASz/GrIoSX
QlULwPnqQlQB9EFxieu++WIblBKMzqvFdXyfECyYvQKqqLWg13VwYCIQh3QjsPy6
EWsOByn0EeDAJ76kaj1WKErP2n/lT02ZTwkrK3sjaUNkwCNy8S5j0bSilBQbYbCo
WsVEm+h5/Uv5mLaHRTBqDfj6U1sGXrHBwbvtXJ20UAtLAQUCJqhPHlLy/oY+FRN6
LIxnHXrEJB2m+6VIhs64MzW6ASkCiRjOrfU9WvRFWpDy7KzfOI0WShszQqMbVo3u
Ruee/TL6p0LID4k5KFxpEs5wRZUd8kFy5Df6r6IJzvfHbvxFMLlvgP9btb5xja46
gBwkppgQC7N5Ph6rqcPyrQcu2KpYAgm/BYlkPGFlir1a4t/00hLYtNuAx9RVhVcN
yd8Ewp8amn3Svg+/j7MYLPw1AvUxwRkD/XRrI3F01GTuDQ9xUiGdm3RoBaUP/aMe
2I+9nqhJxgFlPFgBS1y8E7aThiE3I68EX/rG1WmKeKmfornMIQlVWGdjPoI9Jk9+
QVs32SqszE6iYfU5EodDohEf2Vj2UW95kHAFvRKwhbsb9LilS3Li2J5zu8giTZoV
fbdGmWQWa5b6KuifA50F44Wn1575cobMOW317moRDQlGHJsv7rcXNgYg4KE/GOiR
kNxBQrSPdPbcem3nSG+KV76fKlkW4zg2DJ7cjJDkKp6faXvlG2tfSvQbaBH7QyjH
JD8v8Hp4mA1IWh2V1xAdCVwnMEWcPC/gBJLXJ0UqooKSfoSVUdrYOoUcvQzYsiDo
xPXf+esUXpmgDJ7ovUbPsLqLvssdFquJCBy1E2yjvCeOcM8T/EoNKYMolnaa852b
/rH8PR+z4uQTmShRW9uulhjBGPwgl+BOq3vFUAm2H6VsZV69op2KXxsHOjjOQ39p
R6iWmSA6Q2k3RFgzbkkT99HZk6MrA98/ylsTB0U9Swv5N1K/Y17pZnFh4Q3kG8q/
o/75/bqy1rEHL6HpnzkS41EgnLPeRBnvi47VpXW3xR+4YPHFTx8SFlPzoBD5pXlf
vDXSLslg/CUmscqbtdTL2xZBuavIL0Zk7f41cw7SZr/6KwDlhqdBowA5mRSieKMr
yBI1P2iOYQfgVpjT84oPFFvTnCzK11P3gB8vc3U3hS74pNjqEyKu1py8X02pj43Q
fBgGmrhszLC8A5bjl978O87aV7wJlSsMCp+l01VDt0o2dDsqQAp/g3nrnFZLfnaw
Nbplxjfa7LkjbzFHUFv7URZpx6lpru0ux02fcnjvMKtTWJZJIxTZkxDwmw1IAZw2
Sf5rSwfeF3vEoHIyVT9Vx7wjWszvn96UhLpZK8bSefqIppgRmdxv3/Q/V/7U81H3
hEztWggcWDsr+eGxhAJzJoCDGUy7fZnEl07EUfQtpn++dO0lpJmSvfl6fShLcE6J
c4d5FdTL0XYVS6T9rbTgfQQ64e60LVy3r69CmmsysA20aOa1Yzj3pJ+3UEVdhOdJ
Qhb7KuNuADAl7yEoTBGJF2DC6Iz4WIjvo9Uxh5Ksagw+WLOJDNMTjInTnJIujVHF
0ynE7kdIlCy3UeWzuNWjm12kTvptukE6onLld6xHwdF9j83gVQmVW+b0G3KqJs5U
kRdEjOAz/Ey7ynoLCSJlZsJ1lDqdDmuTW54Ka5GEf99WjNH5QMmhTkfmYGvBi8mg
Nln5s5WpWKTXrIrYGMdcWD3nzOYq4oPnNN/nUlOP+ty4pJnGt9WJQ1Bx0hWrbZwe
72PcIYXK51KlBlK1AR0mL3k8quMBX6ZHezgvXXC5jusmu/AdvczpfIeMGP93Zrz8
anrlRl/PpntU8GVa7Lg4treqPbWiuT/IqwGkXM6vac6e81OCS9101J8gDjHpymsD
8BR2wlarMT0YSvBCm4ek7Hmpgr6cXDRSPKxKcJq+fc5stF8vYzHATTxo+4YmJJ+j
18ze5/G4tnsfiCTgt5LXnCjDTO/tRRbbyT82JQ4i194UkefWTVLDwYOYHB0aDyKT
oUw8NUHnuZX2tmNpseASkb4cX6TjpwUV/aWzaWIVwiQ1hyaLQZEdJ2pLwgvOWg5h
q/Bn7EgaeSywkQ4kJXuX5CPILxrnqBZJbHkCAsFsi1Q5xCcSmkcI5U/3lh9FxqtT
dGIXQdkc7+52KLFpiXltz68y3W2EAQAaU6qRjaUDAa6VXEWcSDnnBS2SFn1a/YN/
Y6EhfB8Kd/8wp9bx8SgFOzZynYYYVEpC124WBWCrCBp9NF7smBCKXL1jy/rc4fSJ
LLL0vrcYi09cb33FzT3nPy76Xp47orV3i4MrZGOkpni067knk3gV9mCDfQWVWKFC
Xi8uzKlxCP6qwWBcLw3wkvthiOM5QDIWSzp6p7SlvpSANnWYfM4o/NLYIT4cU/aW
pIB5pFue3fAhEtYZ+ZFVWiWuvQXPmyPoWU5mBIcoeZYFDtnLdn/VYENh1oSVlxYJ
pnZioODtYcPhSZ+dluTqUNDbWSkTKSPP5n0yrBuGQ/KbJs4nTl1hrEHiCJTt/P9T
E2ay70kAchz39gGHTpA2vC4Mc629QIvmXGYhyPgZX9ludNAU88UrFESS9egPA5Hx
59EDnulnKLM33EtmXUCeiLBjxBGPX8kYIgo9rwsMCwhhH2IDfn84JCD1gKNPwyeu
Zkk1f5siahVo+t6D6PcGeXyrC9aW1JJOkEBm9MN5O2LCRMwpNfhSOPuTZkKjpWtB
Zd4MhdNKx8O0+DSgvXwWDaXhszN89CTrePfYa9ZIvxHKRQluiHZsJmpXPJvOtkzM
jOA18/KV2dUY93jwrRoiY7Xz9BBbwDKsJ2TBr7PxeV+90FuLY0gXSekCLpE0EQ38
Ig/yZAc0mYpbQ/JoR/00kkaQWJhT/ndng2HRTneBWVIBeCX/EQpmmlwljVQOZmH+
+XkLVg4m4j5l7ZmVlY1/PZV97kRX++34eVRXDy/FqDbznUa3pRDcnTQWghq0lQ0T
8rK0f+9Rt8iGyOQo+Je5HL8Ey/HeNIDZUMTdnk77aCHsRt+wFM7taPBWmkUv12Ty
vVbtoB2kGv9zaslbQwlcAMI66CHRknworQ2RHcTFYeJSmFhLUpQcpBpuiStWeCVu
PgVdATSFzp/UY5XSmWyuaN3K2J6Ey73LoIgaJWLe582KGAzuODhUSvs6ok8nBdAR
/NvuqanOy3ILmdclBbnGbkG9yvDJko/X6AXT5lRNYNfOs9SZaNJjGfnx0NH8z7sl
2zHVZtsiVWgyw0i3CFEutZ9F20g0NXcgoGNwLo0wcPa7YteLdZNa012gC5T5dce+
CKM4dWmQ5Kf7CJX6PlTbsSiw3Zi8Xe+ilupaykOtX4ZBluMarSUADUrdkZ0F64//
z8t/cZUqY2GT+qD+elqKHUc5HRRknHQZDZ6m33UemEEp1xyXLkAFu3jICnRi/mw4
7tNZcBHiqHwNzPc4ZWrfx0PnHTbuFmOHOaF3ayMDnsmigl7OhxTIIGYMf0eVOVX7
Pn7iMGlj8o6BEWD67wE8IJbeCSwtK1KsMlsxOq6nuZZ8CfFV7l7ot5Loc3KSN31f
HLssgAr2C7UVK4xIR5aMf9VPasBfGQrxglMjBqoMMSCQNZbv6zsbeet8VX2pX9Vn
i3izjBYIrjqPiMDDHNWQieiqGP+d9l1wKWEgzbWaO1znfNM2qlsBdpGIdLTxVXYw
3iPKnsTQ0K0BmPZdRNvxjzPaU8wtLytl0tF89klU2p3+jbowc8G3u/yBj/keLK/N
x+goP5sxXIe5Rae8f8Vgc48cktdkYjOA8ITRs0gkMBW9CCvRWqX2lt97cRTr0ddD
Csc3ZIXqNhgx6g/mzVDKqKcmOVNOWMJEBoxDezkIyfgtfBsCSsfHpRA8ow8pcM9m
R/cmbTIx+YKPXNiR48/FGk6hiFw2KMSw31vnX5WAqDT94YRv5PAoNr85p0EIVhBE
Cnbkb1oThDM1FhJeMN4pk8H7dTmdAOSkc5X9JZRhEHBM8nkAauxEs7ljJAekIVhX
agpPL/x1XyqZWpfqp4d016uVtYoebyWa5ZHA3ZhBl6IA4Cj98aPPU5AySl+a2Fsq
0kY1tNZaZmfOTOMzyBoGYIT0fItkm/MgjjINMsbBYqFwkjQfsPmM1iefG/XRySNO
p2SJenJ0CxPnqmyEFocGayhrhPGTl2gJIepLVIbEVF3Hg2H1LrLnXyFjrn1hVEka
pWc+pUQ3tnfPVS9sBgSI4hKlHXawsUhe+tjZ5ybx6nGFJiVIKcM+FcSU7RFsQOpn
CDCG/YhfjN6xcWrp9fAeIEpzUU/Mk/YSLheI1V2WrYli44cDUFzvT9iM3ea2oHvJ
5LvWVa9QS9DZ7HLAI2W4aQDJcjbncTaYJ29MBwkkY7q6edIYBhiTyXeSLCTE/4+e
9Oht3azqTOO4N9wv0jctNJdwAPdEzufCzVgjHm9mZ1zUHVCC+hiQqm1PHl3tzdHh
T4IeOwoHchLdbenJdsc9lsDGihOmdUed49hgW3gTwmxCYiA2Q0OAt68oIjQURVwP
/rgd8UiwDNBC/ezhBPXtkxTuFcByRgDtU40a8BhOZZ7pO6zo1iHZtcIX3sONyIMl
bybL5fRHu2QVxzNieisyz73FFOAX6IbiRIjfnwDQGXP9Hu5xKg4v1eAiiECCYp4K
abYlI8gfbrysLEzMquHjm6Q0M8WjKOuqAlXMFTm9KO+62+MbjRjhfu1QiqBdB9U3
b8Kv9EGc55lXLwRQPwRcn7CD6olVMyidSLLT2idyPEmOA1ALP127f/IfGzh82Nth
PdFQ9j49olgtGrKE1zvq6F6VpDv0eNXEbv5kcaU7tHtmJQm0vXGuESOUNRvnwzpT
+bzXSgQCT5zfbrZ7WJef7xq6QnfZZhoVFFjbfkIj6iYkjg5HE1mZE8mZ5nAsIoCQ
cKfujLxF1dMlCFX4/AdpRaO1RuNGvAboFzpPY2wwDS/QGlhKMC0aZELhKT+EVute
xugyPlws+nUKDhlOw3YAbKrR8/DYYmcLuQfErpN8GvsRJzqS9ey1X1SOxvKvi1aR
e6c6VEWiZX5SvvIpl+FkybtR5cnRMhas58tk4nZPKWYTxXk6TA+OgFw/Qf+x2lER
vhfrwEs+Hz11s4UIVway6gKfQ55dqUGDEyHZ7zHG1DAyl640ZsauIlgh+nn3SrW9
qapo488NQ9Lpb7IOV0/tqsp7d1z1WX1HC7MG1JB48jiLP1AhrHsyg8oiRFLTuBCd
YyqzAaP0ghID5hJ7lf50pvRQGVSSINOLSb8N+136GVv3ha2Z7Z1czTRfLhI8w1ZY
1+shLST12Cm+zCpjTU2VzbE/8hDrohUVSk5QWZNZTxLgL6If1RCgcucP0wxRfIXr
zGE0ccuXC89E38uZodrvWlxVkope+JQJDUrTZp8iwqsRtua59cFk3+OTnTXoCIfU
ujY5W5pZVft3iS7IA0lyqRxc2zFh1Nt0ETzNABYELIoKPDk6FxFAXOHHn3n6eqjQ
IpZFwjyr0+gf7x9q1/LA97yNfHg7dsvPif9IWIugk3d06zjbFMLQfC89hlKblF3X
UbYuazfklNR3VKzInT2/auOinLI2czGc//N3hZa4Hwxz+ZaMKkzLxa+jjxwfZFga
WdJIkGoQqLuHRllydrAuTAtP3UbuTl8nGVzmmggbpHzoVEXKDvzS8oG2psMZwVTR
9h/JYnRnYqt0Mq2TnEad109N0bOkS/GGyw3vh4YndquVRdV2oPK33Joa8CxvysvX
nTZWxXwSkvcYPv8brIqRBm3HqabPiAex9PqCeO7AH8OoxvoxXZq1zJNmQ2JSQ6V3
CSzi33jtu47DVXjlNhtGTPUZmYh07LtoKnUkdTaxnat7N7HOGJ869tbbpZwUPWAq
Z1+Nm8PbiNeDOeDmlsEUF/HIJn+DDSNfNBq0OZ7DZr+EfH6SEsAPs7NTqYXj9C9G
63+XjxVfzFU0btjRJoY++vt6IgcuJeHelsrJiVp7bhQbAtz/FXyptpj8CbLIQDh7
2sGBEwL+bjMTRzmHtvWp+3EPULqr8x/XeHzDcG4of4c3MT6wc928H2c4iOMSwKm+
a5tnXfzPimjQNQA+wPxQudBxPppqyLi4ESG4xUdnpLkaDQP9zLXo7q8U3AS5lBlA
dFVR6A/buup/X2+ZPb5/mYzC8DNON/2VrKs6T43URMuE+rsWVk14rUzjBIj1avgO
FQfL4R1TTsbqANGGszg+269RfU2yJif3uIIxwtISx6YoZIIbLzcxeNP8QNNSUFLi
YXVIM82BNnNTUmhEZ0hTclPU9TGGIGK9VVQsmLwMa/9foLtcuiUlcQEP40vcjuJO
kHz0/9fwc8XXoFJpe4LGnQSXQF9hSLdgTBdv/Onj8wQhNH1fHW6slY7wEuok1fP/
rqOO6ni2fY1TkJlUZzJSlud/sE03PzayBbOvk1kzutd9vUqt2c9/F0cxhuthFGdk
zxB7hIbxX3xrkJr+f69bgbXYKdHmjDS0SU4+FjVzcQp7XCw3uGqSxeD01N8cIl2u
eJkM5mUksR3a76d8od0F56L2klVoFbO9smmSyITCZy5M+TEmwo7NffYXh5EtOqCm
+GFmP7idt+G3AhRMUsg+qv1Rl9U58Ju3p2QlXP/rrLSPV6RhMKAqoiizMThL+Wni
U3hUzUmnO3YyFHx9oWAiZ8HwdvqF2hIPtqfUXAEQ4h5+8gbwzcsJcdg4hkfj8Ylx
rtvs2YyFCaOLQJ3boO/qMt4ibYj/xuswV1cZD3M7BsOghLFBuSBNkx9n4Mv9Cthu
+nmxhfXTbf23RhlgtaquBUXUofjw8nN/pxroldQo+fgWswcicATPbprhqVBvFUob
vDh6h2TJM6gj8wo3Etu0YmAVTFWs+dXhJj2esNyD5F4+SZnynypC9k8pxq26fA0e
y9YGbXBJz95ACtCPVgEVSWqU5aFvLcq6nn4LmCUKx9DMtGny/Yss/ejMZqTwOve7
lcMA4yG8MSxIJqULmResjS5zsNsqXvEcLF/w8qsevM64QSexOUFfS6dIE006tJjy
MBGVtrcIwe1M/JPhJpxRgkJ8tOEt0LiVpTYdYdKBR4MgLKArlBPIPJPko8vqC2Xi
SpZNzpqDbuRaLdC/LWNLNUEH8dNxbKetKGU3+CzUIRck+/lqEy4j/VRuHwZCnM6R
rt3aPd9Kf46jbzpO0aoNGNOCrTrx5x6ReLFC1siuc5vZYuZ6Ml7uHXREsPZGPKpl
WDtZBARplxjerc1CKDq0kVl+lT7OxGXPKa2IHZV9MDGLTc0pZzlnN+0KYqpzhQjJ
REIn+/DvVfSVElmj/RtmInxfJP4nsVqEEIp+5Ini8Syl2EzeRde/5g/lHH3tUs24
ELibRaRMWtUdhvigKKN8if/ysoKnj04+XwF3VitdcNRbNXO3orccM6N1xXVd90f3
iS2wOfyZbJlOtQJS3d1tFR4RBfTuy1YukR+yezVCWEmrByzvaD6HiZWlfteIzkoW
7PsUR0LUxcaKynpCfUmlj1lS+guplHIUufrVSUo8xlNI/ZnAyHcDniPYZQDzZOTe
Cex751Yg0xb8PuTMl9WBVd8zj2Y42j/euRk8GIbc432kKrE6BF+R9aHtXRGXOeuI
Ln1mI0lSTwOiQKo8TstjvnTFOKSuh8YJhfl3ErBcA5nC4S6VCqAZLQCyV7w4XR5m
nry5A8hn61H57wPgG7ZbZwJUaCLYeQOawRhhEJ0P64u+yiU3vyJc2/uSqrSkbEBX
KGGZdUv4j5u1g4iTmS5dl1xe8xL+JMyjwZkMq8lqCwa7t3Wdy3Cph+q/FA6OXtFW
L973lYqu38s52zW7OIoEcXbwR7BXuCKzEv/HwPwhv4QREqnAbWuKHjCuYh+oN8BO
uF68GcK6VceT4STu5Q/hh04hb6yvW1bI+/gnizBuKp2kh6WQM7oQAen7EZz4p/E1
NSww9pmQhr9hCRAgI5Da5cBHck/Ey4FFe/JIWKsOGaSYuNIsYhaPCfvfZs/sAbNR
BoMeaK8xBrJjIG5bc1CoZVefOVEGJEQvpHy7yG8ZDnl8p+qdR9A/XXZBdI4ydrZR
l0ZoG5o0W1gpnEzAUxiG6COqL1tL0nnyGVD6cua379nZMMr4Ef9sbQtfPa01ftDU
n2lIiFbu0RFnHthtOL9SYZkjfV7Px3nP9PAgryxymDUCIDpbaHg53SKTCLiFv5q/
cC5FQt2EIgza66+bqetc61+6MeTuccAlbkMnUl/0lseVByJo7DiztixWQysebAui
PZHauCwUY8ZJ0Bwi4nD3mLANr+yrFCPZRp8CU5Id+BtnB50F2ZooqdldKPWCebBn
DEgDEQHfKV/7MD7CjP2ivW3TMMTYnUoR7iltSvbxOd1TktbmS9gXhdbbq+4MJNVV
9mVyup4miu7/2FHC3Qnl/cCYonF9Nkt3YhPCTsQKgO4rwfWY93RlZfSjHppwMSRA
zTpYsqF0E5WCe+a7NzWjb8x+Q938mdpWzOKUVJK9kNL8LhPzdnF+rcxhqegJkQEX
Fc/o8G5OXz1+NSZI/rBe0m2q7K+4PGMRjcxn9Ajxfmg69JRPVcVitNIZ78zjUiGO
yrdq3fP31FEw5QSPqEZraXXNVRn+R+h8PkWjRyY/dyy/1MsCwD3GuMWy9cLN0K0h
vdiHTcstfOtrJG+eQXDNZHVf/opD4JoJecSqrdCYiyRU0wpGF9CijIjxNPTb2yeL
Vdx9r1C/jMxF/T4/LkFpTgadIU3l5yDcuaXhnAnBrEoDyMF90ZZmmmT7bSRbYLub
LjIv+OgeB54Jn5fTZHwA4ZBvDS1pSbZvqAXiFSO5oDpd4qYaXhJ/V9YvP8OSTu87
9wPqU1PmXvgN6vrq7GpODXQEvqHJ2yvIPmGLvyydv3iRqSsfyqtrmMAMz3cqVr3Y
Yy4mEmrawtDVALz5SXPATKQtBU+1toMr+akFpjJsp9h/Pd4Y6Vfc5cRHzK1P/nr1
Km0MA14QLWm9VZEC6rpvw/B9xbUpfVye7nodAdR2F2ExE9qazNA9K7urhFSJSbEU
o/w1sgsOnekkcUHrqoHJySf6/R6kpWAXSBw+UHUMTCrTI3zm8dbvtHQMt1XN+qxy
qPJ4oE7X6AGJJouSe04lhMWzBHDbnB7y2nbGBnjbEGBkOxpk0CIED9TqwkiksRb2
Pf8gWuCGfw/fiZNH7feEIlQYwFbQ/ZzKFkx/otQNyXqIWSSP1ICTP4uOvmXUO1YE
cdGZEbzm7G+bL/UDFlrSdMZ9h/9x3oDWu7VTVcYnyXKCWMfMqlKGAjUETeSh/0fp
7YiwvU9yDfjtKVcM8Q037sC/8n8ErWumBQJwud+7aLxVgL58NbbD7w8h5lHHiQVK
rHm42Y8LRzrx5gIAD7ifOMfb3ZbiRdrzl4g6c+u4RMMgqQlQGI0m//Fi+pWdgl2U
CB1J6aCav1ZYKTI345jBmUujWbef+tRHc36YWO6BOM7hX97f1fgPksdfbx2DzM2o
kOFcIgMzm0uPBzqoskXOSbsld/sIxShjTwLpVqJn+BomIl/dZucx0HGqjCjiDwXu
LVdhMy26Lzy8bu0vF1INZ04BZrq4IVqruGF/FUrIOpuYvGVIzliJ3PPGctro4G+T
maV9gxJUHMs9WD8OPlUkx2/ve1S1FrrFPueh9RvOjnyywblbYWsTNHTfaWySd02i
RIb9QtREPrsE9BUUiwppanF6QJ6iEHQDIHXvAjypKBTX59VZzCBc+mSjzZiyzjsp
qVKT8JRHUz3wLoB4podWO8SA6C9Y1kuY3cn/pqsX6PEV5a1i203DyXTstZEdFPe3
8O1MKT7r0qIFKXbv4FzQ3ovMJq0emJ+JQVXmyTrFn6ne3WKI9BzG1kaLryo6urIV
bj/ZXgPAXqeX0EkVdb5h+PiNmhLqEOCVr5euXViYgf6OV+dgVMRVmnwr0jJYndHo
ZwHT93nv4gCgoX6C7iyLUDRK2dWsnz1+Q7EpkTb7fuxNgmNrGRb/i5lBVarM9zKN
xI27fvwFwBYqlhMTkHG0MWwZsQeO86Qjz1ymvtVTt1KHnsvKU+S6KVOYWDlDZGG8
TS2AidDvg35KiFbLMEmFWVvEMphNAqJFStpW5AI9Qgq12mvPwHnxdfxsrJ5/ccDl
vvwUZNlykqjHey7zJr30mAqFAMVjjY1ggCgmJF8d2oA4oqSpw2mRP6WnD73dyUv5
VxKras55RlghxgrbjXU5YTQdoAl13nPhRrLwHbWEBLpo30bJ8jLDv1iHcrWPbo9e
gAED0yFLVtXTyKlxrDLe+NOkI0OSTLg4cYSiyUj2rCMR9P+NC2oyqj7cScd+RxlS
iXVSYjSyrE7tFOVI9N71h/tGZY2E0x/GW1b/F4wHVPY96JJ3pXzuAA2TBAFQqC6L
bYgThkW4L3plVh42gVUXTV40iPd7sXYv0+kPrI1LAnNzB63OuXOtonnBpfQPuqkf
OYN/j9RgIkgIZk5KHvG1w7qsmUxGqteFQZI6aPOc0ch3lX2zmANRI0oAxk+v1CXC
nBm+ij3BWzUGW1pIZ0rQ
=r9af
-----END PGP MESSAGE-----