[Eisfair] Kernel 4.9.207 SMT auf E-64 Fileserver?

[Thomas Bork]

Am 27.01.2020 um 01:37 schrieb Kay Martinen:

>> Vulnerability Itlb multihit:     KVM: Vulnerable
>> Vulnerability L1tf:              Mitigation; PTE Inversion
>> Vulnerability Mds:               Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled
>> Vulnerability Meltdown:          Mitigation; PTI
>> Vulnerability Spec store bypass: Vulnerable
>> Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user pointer sanitizatio
>>                                   n
>> Vulnerability Spectre v2:        Mitigation; Full generic retpoline, STIBP disabled, RSB filling
>> Vulnerability Tsx async abort:   Not affected
[...]
> und da hab ich doch eine Frage: Kann ich da SMT separat wieder
> aktivieren? Ich hab die Begriffe Mds und SMT disabled mal ge-startpage'd
> und komme auf
> https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html zu
> der Bemerkung das es auf bestimmte Workloads Einige Leistungseinbußen
> geben kann. Das ist Echtes Blech das nur im Internen LAN genutzt wird
> und was ich nicht einschätzen kann (die Seite nennt keine Workloads) ist
> ob das An/Aus von SMT großen Einfluß oder große Risiken bringt.

Es ist langsam nicht mehr lustig, welche Lücken Intel-Prozessoren 
aufweisen. Die Kernel-Entwickler halten dagegen - aber einfacher wird es 
dadurch nicht, wenn man eine spezielle mitigation wieder aufheben 
möchte. Hier ein Auszug der Kernel-Parameter unseres Kernels, um diese 
Abschwächung der Lücken zu beeinflussen:

<------>kvm.nx_huge_pages=
<------><------><------>[KVM] Controls the software workaround for the
<------><------><------>X86_BUG_ITLB_MULTIHIT bug.
<------><------><------>force<->: Always deploy workaround.
<------><------><------>off<--->: Never deploy workaround.
<------><------><------>auto    : Deploy workaround based on the presence of
<------><------><------><------>  X86_BUG_ITLB_MULTIHIT.

<------><------><------>Default is 'auto'.

<------><------><------>If the software workaround is enabled for the host,
<------><------><------>guests do need not to enable it for nested guests.
[...]
<------>l1tf=           [X86] Control mitigation of the L1TF 
vulnerability on
<------><------><------>      affected CPUs

<------><------><------>The kernel PTE inversion protection is 
unconditionally
<------><------><------>enabled and cannot be disabled.

<------><------><------>full
<------><------><------><------>Provides all available mitigations for the
<------><------><------><------>L1TF vulnerability. Disables SMT and
<------><------><------><------>enables all mitigations in the
<------><------><------><------>hypervisors, i.e. unconditional L1D flush.

<------><------><------><------>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 flush.

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

<------><------><------><------>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 restriction on both hypervisor and
<------><------><------><------>bare metal.

<------><------><------>Default is 'flush'.

<------><------><------>For details see: Documentation/hw-vuln/l1tf.rst
[...]
<------>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
<------><------><------>full,nosmt - Enable MDS mitigation and disable
<------><------><------><------>     SMT on vulnerable CPUs
<------><------><------>off        - Unconditionally disable MDS mitigation

<------><------><------>On TAA-affected machines, mds=off can be 
prevented by
<------><------><------>an active TAA mitigation as both vulnerabilities are
<------><------><------>mitigated with the same mechanism so in order to 
disable
<------><------><------>this mitigation, you need to specify 
tsx_async_abort=off
<------><------><------>too.

<------><------><------>Not specifying this option is equivalent to
<------><------><------>mds=full.

<------><------><------>For details see: Documentation/hw-vuln/mds.rst
[...]
<------>mitigations=
<------><------><------>[X86] Control optional mitigations for CPU
<------><------><------>vulnerabilities.  This is a set of curated,
<------><------><------>arch-independent options, each of which is an
<------><------><------>aggregation of existing arch-specific options.

<------><------><------>off
<------><------><------><------>Disable all optional CPU mitigations.  This
<------><------><------><------>improves system performance, but it may also
<------><------><------><------>expose users to several CPU vulnerabilities.
<------><------><------><------>Equivalent to: nopti [X86]
<------><------><------><------><------>       nospectre_v1 [X86]
<------><------><------><------><------>       nospectre_v2 [X86]
<------><------><------><------><------>       spectre_v2_user=off [X86]
<------><------><------><------><------> 
spec_store_bypass_disable=off [X86]
<------><------><------><------><------>       l1tf=off [X86]
<------><------><------><------><------>       mds=off [X86]
<------><------><------><------><------>       tsx_async_abort=off [X86]
<------><------><------><------><------>       kvm.nx_huge_pages=off [X86]

<------><------><------><------>Exceptions:
<------><------><------><------><------>       This does not have any 
effect on
<------><------><------><------><------>       kvm.nx_huge_pages when
<------><------><------><------><------>       kvm.nx_huge_pages=force.

<------><------><------>auto (default)
<------><------><------><------>Mitigate all CPU vulnerabilities, but 
leave SMT
<------><------><------><------>enabled, even if it's vulnerable.  This 
is for
<------><------><------><------>users who don't want to be surprised by SMT
<------><------><------><------>getting disabled across kernel upgrades, 
or who
<------><------><------><------>have other ways of avoiding SMT-based 
attacks.
<------><------><------><------>Equivalent to: (default behavior)

<------><------><------>auto,nosmt
<------><------><------><------>Mitigate all CPU vulnerabilities, 
disabling SMT
<------><------><------><------>if needed.  This is for users who always 
want to
<------><------><------><------>be fully mitigated, even if it means 
losing SMT.
<------><------><------><------>Equivalent to: l1tf=flush,nosmt [X86]
<------><------><------><------><------>       mds=full,nosmt [X86]
<------><------><------><------><------> 
tsx_async_abort=full,nosmt [X86]
[...]
<------>nospectre_v1<-->[X86,PPC] Disable mitigations for Spectre Variant 1
<------><------><------>(bounds check bypass). With this option data 
leaks are
<------><------><------>possible in the system.

<------>nospectre_v2<-->[X86,PPC_FSL_BOOK3E] Disable all mitigations for 
the Spectre variant 2
<------><------><------>(indirect branch prediction) vulnerability. 
System may
<------><------><------>allow data leaks with this option, which is 
equivalent
<------><------><------>to spectre_v2=off.

<------>nospec_store_bypass_disable
<------><------><------>[HW] Disable all mitigations for the Speculative 
Store Bypass vulnerability
[...]
<------>pti=<--><------>[X86_64] Control Page Table Isolation of user and
<------><------><------>kernel address spaces.  Disabling this feature
<------><------><------>removes hardening, but improves performance of
<------><------><------>system calls and interrupts.

<------><------><------>on   - unconditionally enable
<------><------><------>off  - unconditionally disable
<------><------><------>auto - kernel detects whether your CPU model is
<------><------><------>       vulnerable to issues that PTI mitigates

<------><------><------>Not specifying this option is equivalent to 
pti=auto.

<------>nopti<-><------>[X86_64]
<------><------><------>Equivalent to pti=off
[...]
#<------>spectre_v2=<--->[X86] Control mitigation of Spectre variant 2
<------><------><------>(indirect branch speculation) vulnerability.
<------><------><------>The default operation protects the kernel from
<------><------><------>user space attacks.

<------><------><------>on   - unconditionally enable, implies
<------><------><------>       spectre_v2_user=on
<------><------><------>off  - unconditionally disable, implies
<------><------><------>       spectre_v2_user=off
<------><------><------>auto - kernel detects whether your CPU model is
<------><------><------>       vulnerable

<------><------><------>Selecting 'on' will, and 'auto' may, choose a
<------><------><------>mitigation method at run time according to the
<------><------><------>CPU, the available microcode, the setting of the
<------><------><------>CONFIG_RETPOLINE configuration option, and the
<------><------><------>compiler with which the kernel was built.

<------><------><------>Selecting 'on' will also enable the mitigation
<------><------><------>against user space to user space task attacks.

<------><------><------>Selecting 'off' will disable both the kernel and
<------><------><------>the user space protections.

<------><------><------>Specific mitigations can also be selected manually:

<------><------><------>retpoline<----->  - replace indirect branches
<------><------><------>retpoline,generic - google's original retpoline
<------><------><------>retpoline,amd     - AMD-specific minimal thunk

<------><------><------>Not specifying this option is equivalent to
<------><------><------>spectre_v2=auto.

<------>spectre_v2_user=
<------><------><------>[X86] Control mitigation of Spectre variant 2
<------><------>        (indirect branch speculation) vulnerability between
<------><------>        user space tasks

<------><------><------>on<---->- Unconditionally enable mitigations. Is
<------><------><------><------>  enforced by spectre_v2=on

<------><------><------>off     - Unconditionally disable mitigations. Is
<------><------><------><------>  enforced by spectre_v2=off

<------><------><------>prctl   - Indirect branch speculation is enabled,
<------><------><------><------>  but mitigation can be enabled via prctl
<------><------><------><------>  per thread.  The mitigation control state
<------><------><------><------>  is inherited on fork.

<------><------><------>prctl,ibpb
<------><------><------><------>- Like "prctl" above, but only STIBP is
<------><------><------><------>  controlled per thread. IBPB is issued
<------><------><------><------>  always when switching between 
different user
<------><------><------><------>  space processes.

<------><------><------>seccomp
<------><------><------><------>- Same as "prctl" above, but all seccomp
<------><------><------><------>  threads will enable the mitigation unless
<------><------><------><------>  they explicitly opt out.

<------><------><------>seccomp,ibpb
<------><------><------><------>- Like "seccomp" above, but only STIBP is
<------><------><------><------>  controlled per thread. IBPB is issued
<------><------><------><------>  always when switching between different
<------><------><------><------>  user space processes.

<------><------><------>auto    - Kernel selects the mitigation depending on
<------><------><------><------>  the available CPU features and 
vulnerability.

<------><------><------>Default mitigation:
<------><------><------>If CONFIG_SECCOMP=y then "seccomp", otherwise 
"prctl"

<------><------><------>Not specifying this option is equivalent to
<------><------><------>spectre_v2_user=auto.

<------>spec_store_bypass_disable=
<------><------><------>[HW] Control Speculative Store Bypass (SSB) 
Disable mitigation
<------><------><------>(Speculative Store Bypass vulnerability)

<------><------><------>Certain CPUs are vulnerable to an exploit against a
<------><------><------>a common industry wide performance optimization 
known
<------><------><------>as "Speculative Store Bypass" in which recent stores
<------><------><------>to the same memory location may not be observed by
<------><------><------>later loads during speculative execution. The idea
<------><------><------>is that such stores are unlikely and that they can
<------><------><------>be detected prior to instruction retirement at the
<------><------><------>end of a particular speculation execution window.

<------><------><------>In vulnerable processors, the speculatively 
forwarded
<------><------><------>store can be used in a cache side channel 
attack, for
<------><------><------>example to read memory to which the attacker 
does not
<------><------><------>directly have access (e.g. inside sandboxed code).

<------><------><------>This parameter controls whether the Speculative 
Store
<------><------><------>Bypass optimization is used.

<------><------><------>on      - Unconditionally disable Speculative 
Store Bypass
<------><------><------>off     - Unconditionally enable Speculative 
Store Bypass
<------><------><------>auto    - Kernel detects whether the CPU model 
contains an
<------><------><------><------>  implementation of Speculative Store 
Bypass and
<------><------><------><------>  picks the most appropriate mitigation. 
If the
<------><------><------><------>  CPU is not vulnerable, "off" is 
selected. If the
<------><------><------><------>  CPU is vulnerable the default 
mitigation is
<------><------><------><------>  architecture and Kconfig dependent. 
See below.
<------><------><------>prctl   - Control Speculative Store Bypass per 
thread
<------><------><------><------>  via prctl. Speculative Store Bypass is 
enabled
<------><------><------><------>  for a process by default. The state of 
the control
<------><------><------><------>  is inherited on fork.
<------><------><------>seccomp - Same as "prctl" above, but all seccomp 
threads
<------><------><------><------>  will disable SSB unless they 
explicitly opt out.

<------><------><------>Not specifying this option is equivalent to
<------><------><------>spec_store_bypass_disable=auto.

<------><------><------>Default mitigations:
<------><------><------>X86:<-->If CONFIG_SECCOMP=y "seccomp", otherwise 
"prctl"
[...]
<------>tsx=<--><------>[X86] Control Transactional Synchronization
<------><------><------>Extensions (TSX) feature in Intel processors that
<------><------><------>support TSX control.

<------><------><------>This parameter controls the TSX feature. The 
options are:

<------><------><------>on<---->- Enable TSX on the system. Although 
there are
<------><------><------><------>mitigations for all known security 
vulnerabilities,
<------><------><------><------>TSX has been known to be an accelerator for
<------><------><------><------>several previous speculation-related 
CVEs, and
<------><------><------><------>so there may be unknown>security risks 
associated
<------><------><------><------>with leaving it enabled.

<------><------><------>off<--->- Disable TSX on the system. (Note that this
<------><------><------><------>option takes effect only on newer CPUs 
which are
<------><------><------><------>not vulnerable to MDS, i.e., have
<------><------><------><------>MSR_IA32_ARCH_CAPABILITIES.MDS_NO=1 and 
which get
<------><------><------><------>the new IA32_TSX_CTRL MSR through a 
microcode
<------><------><------><------>update. This new MSR allows for the reliable
<------><------><------><------>deactivation of the TSX functionality.)

<------><------><------>auto<-->- Disable TSX if X86_BUG_TAA is present,
<------><------><------><------>  otherwise enable TSX on the system.

<------><------><------>Not specifying this option is equivalent to tsx=off.

<------><------><------>See Documentation/hw-vuln/tsx_async_abort.rst
<------><------><------>for more details.

<------>tsx_async_abort= [X86,INTEL] Control mitigation for the TSX Async
<------><------><------>Abort (TAA) vulnerability.

<------><------><------>Similar to Micro-architectural Data Sampling (MDS)
<------><------><------>certain CPUs that support Transactional
<------><------><------>Synchronization Extensions (TSX) 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 TAA mitigation.  The
<------><------><------>options are:

<------><------><------>full       - Enable TAA mitigation on vulnerable 
CPUs
<------><------><------><------>     if TSX is enabled.

<------><------><------>full,nosmt - Enable TAA mitigation and disable 
SMT on
<------><------><------><------>     vulnerable CPUs. If TSX is 
disabled, SMT
<------><------><------><------>     is not disabled because CPU is not
<------><------><------><------>     vulnerable to cross-thread TAA attacks.
<------><------><------>off        - Unconditionally disable TAA mitigation

<------><------><------>On MDS-affected machines, tsx_async_abort=off can be
<------><------><------>prevented by an active MDS mitigation as both 
vulnerabilities
<------><------><------>are mitigated with the same mechanism so in 
order to disable
<------><------><------>this mitigation, you need to specify mds=off too.

<------><------><------>Not specifying this option is equivalent to
<------><------><------>tsx_async_abort=full.  On CPUs which are MDS 
affected
<------><------><------>and deploy MDS mitigation, TAA mitigation is not
<------><------><------>required and doesn't provide any additional
<------><------><------>mitigation.

<------><------><------>For details see:
<------><------><------>Documentation/hw-vuln/tsx_async_abort.rst

-- 
der tom
[eisfair-team]