Unverified Commit ab472430 authored by Mark Brown's avatar Mark Brown
Browse files

Add cs42l43 PC focused SoundWire CODEC 

Merge series from Charles Keepax <ckeepax@opensource.cirrus.com>:

This patch chain adds support for the Cirrus Logic cs42l43 PC focused
SoundWire CODEC.
parents 46f53bde ef75e767

Documentation/ABI/testing/sysfs-bus-cxl

+13 −2
Original line number Diff line number Diff line
@@ -82,7 +82,12 @@ Description: 
		whether it resides in persistent capacity, volatile capacity,

		or the LSA, is made permanently unavailable by whatever means

		is appropriate for the media type. This functionality requires

		the device to be not be actively decoding any HPA ranges.

		the device to be disabled, that is, not actively decoding any

		HPA ranges. This permits avoiding explicit global CPU cache

		management, relying instead for it to be done when a region

		transitions between software programmed and hardware committed

		states. If this file is not present, then there is no hardware

		support for the operation.





What            /sys/bus/cxl/devices/memX/security/erase
@@ -92,7 +97,13 @@ Contact: linux-cxl@vger.kernel.org 
Description:

		(WO) Write a boolean 'true' string value to this attribute to

		secure erase user data by changing the media encryption keys for

		all user data areas of the device.

		all user data areas of the device. This functionality requires

		the device to be disabled, that is, not actively decoding any

		HPA ranges. This permits avoiding explicit global CPU cache

		management, relying instead for it to be done when a region

		transitions between software programmed and hardware committed

		states. If this file is not present, then there is no hardware

		support for the operation.





What:		/sys/bus/cxl/devices/memX/firmware/

Documentation/ABI/testing/sysfs-devices-system-cpu

+7 −6
Original line number Diff line number Diff line
@@ -513,17 +513,18 @@ Description: information about CPUs heterogeneity. 
		cpu_capacity: capacity of cpuX.



What:		/sys/devices/system/cpu/vulnerabilities

		/sys/devices/system/cpu/vulnerabilities/gather_data_sampling

		/sys/devices/system/cpu/vulnerabilities/itlb_multihit

		/sys/devices/system/cpu/vulnerabilities/l1tf

		/sys/devices/system/cpu/vulnerabilities/mds

		/sys/devices/system/cpu/vulnerabilities/meltdown

		/sys/devices/system/cpu/vulnerabilities/mmio_stale_data

		/sys/devices/system/cpu/vulnerabilities/retbleed

		/sys/devices/system/cpu/vulnerabilities/spec_store_bypass

		/sys/devices/system/cpu/vulnerabilities/spectre_v1

		/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

		/sys/devices/system/cpu/vulnerabilities/srbds

		/sys/devices/system/cpu/vulnerabilities/tsx_async_abort

		/sys/devices/system/cpu/vulnerabilities/itlb_multihit

		/sys/devices/system/cpu/vulnerabilities/mmio_stale_data

		/sys/devices/system/cpu/vulnerabilities/retbleed

Date:		January 2018

Contact:	Linux kernel mailing list <linux-kernel@vger.kernel.org>

Description:	Information about CPU vulnerabilities

Documentation/ABI/testing/sysfs-platform-hidma

+1 −1
Original line number Diff line number Diff line
@@ -2,7 +2,7 @@ What: /sys/devices/platform/hidma-*/chid 
		/sys/devices/platform/QCOM8061:*/chid

Date:		Dec 2015

KernelVersion:	4.4

Contact:	"Sinan Kaya <okaya@codeaurora.org>"

Contact:	"Sinan Kaya <okaya@kernel.org>"

Description:

		Contains the ID of the channel within the HIDMA instance.

		It is used to associate a given HIDMA channel with the

Documentation/ABI/testing/sysfs-platform-hidma-mgmt

+10 −10
Original line number Diff line number Diff line
@@ -2,7 +2,7 @@ What: /sys/devices/platform/hidma-mgmt*/chanops/chan*/priority 
		/sys/devices/platform/QCOM8060:*/chanops/chan*/priority

Date:		Nov 2015

KernelVersion:	4.4

Contact:	"Sinan Kaya <okaya@codeaurora.org>"

Contact:	"Sinan Kaya <okaya@kernel.org>"

Description:

		Contains either 0 or 1 and indicates if the DMA channel is a

		low priority (0) or high priority (1) channel.
@@ -11,7 +11,7 @@ What: /sys/devices/platform/hidma-mgmt*/chanops/chan*/weight 
		/sys/devices/platform/QCOM8060:*/chanops/chan*/weight

Date:		Nov 2015

KernelVersion:	4.4

Contact:	"Sinan Kaya <okaya@codeaurora.org>"

Contact:	"Sinan Kaya <okaya@kernel.org>"

Description:

		Contains 0..15 and indicates the weight of the channel among

		equal priority channels during round robin scheduling.
@@ -20,7 +20,7 @@ What: /sys/devices/platform/hidma-mgmt*/chreset_timeout_cycles 
		/sys/devices/platform/QCOM8060:*/chreset_timeout_cycles

Date:		Nov 2015

KernelVersion:	4.4

Contact:	"Sinan Kaya <okaya@codeaurora.org>"

Contact:	"Sinan Kaya <okaya@kernel.org>"

Description:

		Contains the platform specific cycle value to wait after a

		reset command is issued. If the value is chosen too short,
@@ -32,7 +32,7 @@ What: /sys/devices/platform/hidma-mgmt*/dma_channels 
		/sys/devices/platform/QCOM8060:*/dma_channels

Date:		Nov 2015

KernelVersion:	4.4

Contact:	"Sinan Kaya <okaya@codeaurora.org>"

Contact:	"Sinan Kaya <okaya@kernel.org>"

Description:

		Contains the number of dma channels supported by one instance

		of HIDMA hardware. The value may change from chip to chip.
@@ -41,7 +41,7 @@ What: /sys/devices/platform/hidma-mgmt*/hw_version_major 
		/sys/devices/platform/QCOM8060:*/hw_version_major

Date:		Nov 2015

KernelVersion:	4.4

Contact:	"Sinan Kaya <okaya@codeaurora.org>"

Contact:	"Sinan Kaya <okaya@kernel.org>"

Description:

		Version number major for the hardware.
@@ -49,7 +49,7 @@ What: /sys/devices/platform/hidma-mgmt*/hw_version_minor 
		/sys/devices/platform/QCOM8060:*/hw_version_minor

Date:		Nov 2015

KernelVersion:	4.4

Contact:	"Sinan Kaya <okaya@codeaurora.org>"

Contact:	"Sinan Kaya <okaya@kernel.org>"

Description:

		Version number minor for the hardware.
@@ -57,7 +57,7 @@ What: /sys/devices/platform/hidma-mgmt*/max_rd_xactions 
		/sys/devices/platform/QCOM8060:*/max_rd_xactions

Date:		Nov 2015

KernelVersion:	4.4

Contact:	"Sinan Kaya <okaya@codeaurora.org>"

Contact:	"Sinan Kaya <okaya@kernel.org>"

Description:

		Contains a value between 0 and 31. Maximum number of

		read transactions that can be issued back to back.
@@ -69,7 +69,7 @@ What: /sys/devices/platform/hidma-mgmt*/max_read_request 
		/sys/devices/platform/QCOM8060:*/max_read_request

Date:		Nov 2015

KernelVersion:	4.4

Contact:	"Sinan Kaya <okaya@codeaurora.org>"

Contact:	"Sinan Kaya <okaya@kernel.org>"

Description:

		Size of each read request. The value needs to be a power

		of two and can be between 128 and 1024.
@@ -78,7 +78,7 @@ What: /sys/devices/platform/hidma-mgmt*/max_wr_xactions 
		/sys/devices/platform/QCOM8060:*/max_wr_xactions

Date:		Nov 2015

KernelVersion:	4.4

Contact:	"Sinan Kaya <okaya@codeaurora.org>"

Contact:	"Sinan Kaya <okaya@kernel.org>"

Description:

		Contains a value between 0 and 31. Maximum number of

		write transactions that can be issued back to back.
@@ -91,7 +91,7 @@ What: /sys/devices/platform/hidma-mgmt*/max_write_request 
		/sys/devices/platform/QCOM8060:*/max_write_request

Date:		Nov 2015

KernelVersion:	4.4

Contact:	"Sinan Kaya <okaya@codeaurora.org>"

Contact:	"Sinan Kaya <okaya@kernel.org>"

Description:

		Size of each write request. The value needs to be a power

		of two and can be between 128 and 1024.

Documentation/admin-guide/hw-vuln/gather_data_sampling.rst

0 → 100644
+109 −0
Original line number Diff line number Diff line 
.. SPDX-License-Identifier: GPL-2.0



GDS - Gather Data Sampling

==========================



Gather Data Sampling is a hardware vulnerability which allows unprivileged

speculative access to data which was previously stored in vector registers.



Problem

-------

When a gather instruction performs loads from memory, different data elements

are merged into the destination vector register. However, when a gather

instruction that is transiently executed encounters a fault, stale data from

architectural or internal vector registers may get transiently forwarded to the

destination vector register instead. This will allow a malicious attacker to

infer stale data using typical side channel techniques like cache timing

attacks. GDS is a purely sampling-based attack.



The attacker uses gather instructions to infer the stale vector register data.

The victim does not need to do anything special other than use the vector

registers. The victim does not need to use gather instructions to be

vulnerable.



Because the buffers are shared between Hyper-Threads cross Hyper-Thread attacks

are possible.



Attack scenarios

----------------

Without mitigation, GDS can infer stale data across virtually all

permission boundaries:



	Non-enclaves can infer SGX enclave data

	Userspace can infer kernel data

	Guests can infer data from hosts

	Guest can infer guest from other guests

	Users can infer data from other users



Because of this, it is important to ensure that the mitigation stays enabled in

lower-privilege contexts like guests and when running outside SGX enclaves.



The hardware enforces the mitigation for SGX. Likewise, VMMs should  ensure

that guests are not allowed to disable the GDS mitigation. If a host erred and

allowed this, a guest could theoretically disable GDS mitigation, mount an

attack, and re-enable it.



Mitigation mechanism

--------------------

This issue is mitigated in microcode. The microcode defines the following new

bits:



 ================================   ===   ============================

 IA32_ARCH_CAPABILITIES[GDS_CTRL]   R/O   Enumerates GDS vulnerability

                                          and mitigation support.

 IA32_ARCH_CAPABILITIES[GDS_NO]     R/O   Processor is not vulnerable.

 IA32_MCU_OPT_CTRL[GDS_MITG_DIS]    R/W   Disables the mitigation

                                          0 by default.

 IA32_MCU_OPT_CTRL[GDS_MITG_LOCK]   R/W   Locks GDS_MITG_DIS=0. Writes

                                          to GDS_MITG_DIS are ignored

                                          Can't be cleared once set.

 ================================   ===   ============================



GDS can also be mitigated on systems that don't have updated microcode by

disabling AVX. This can be done by setting gather_data_sampling="force" or

"clearcpuid=avx" on the kernel command-line.



If used, these options will disable AVX use by turning off XSAVE YMM support.

However, the processor will still enumerate AVX support.  Userspace that

does not follow proper AVX enumeration to check both AVX *and* XSAVE YMM

support will break.



Mitigation control on the kernel command line

---------------------------------------------

The mitigation can be disabled by setting "gather_data_sampling=off" or

"mitigations=off" on the kernel command line. Not specifying either will default

to the mitigation being enabled. Specifying "gather_data_sampling=force" will

use the microcode mitigation when available or disable AVX on affected systems

where the microcode hasn't been updated to include the mitigation.



GDS System Information

------------------------

The kernel provides vulnerability status information through sysfs. For

GDS this can be accessed by the following sysfs file:



/sys/devices/system/cpu/vulnerabilities/gather_data_sampling



The possible values contained in this file are:



 ============================== =============================================

 Not affected                   Processor not vulnerable.

 Vulnerable                     Processor vulnerable and mitigation disabled.

 Vulnerable: No microcode       Processor vulnerable and microcode is missing

                                mitigation.

 Mitigation: AVX disabled,

 no microcode                   Processor is vulnerable and microcode is missing

                                mitigation. AVX disabled as mitigation.

 Mitigation: Microcode          Processor is vulnerable and mitigation is in

                                effect.

 Mitigation: Microcode (locked) Processor is vulnerable and mitigation is in

                                effect and cannot be disabled.

 Unknown: Dependent on

 hypervisor status              Running on a virtual guest processor that is

                                affected but with no way to know if host

                                processor is mitigated or vulnerable.

 ============================== =============================================



GDS Default mitigation

----------------------

The updated microcode will enable the mitigation by default. The kernel's

default action is to leave the mitigation enabled.