Skip to content

Commit

Permalink
add missing file from 5.4.47.tar.xz
Browse files Browse the repository at this point in the history
  • Loading branch information
@jason416
jason416 committed Jun 21, 2020
1 parent ef88bba commit 824c647
Show file tree
Hide file tree
Showing 7 changed files with 670 additions and 0 deletions.
149 changes: 149 additions & 0 deletions Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,149 @@
.. SPDX-License-Identifier: GPL-2.0
SRBDS - Special Register Buffer Data Sampling
=============================================

SRBDS is a hardware vulnerability that allows MDS :doc:`mds` techniques to
infer values returned from special register accesses. Special register
accesses are accesses to off core registers. According to Intel's evaluation,
the special register reads that have a security expectation of privacy are
RDRAND, RDSEED and SGX EGETKEY.

When RDRAND, RDSEED and EGETKEY instructions are used, the data is moved
to the core through the special register mechanism that is susceptible
to MDS attacks.

Affected processors
--------------------
Core models (desktop, mobile, Xeon-E3) that implement RDRAND and/or RDSEED may
be affected.

A processor is affected by SRBDS if its Family_Model and stepping is
in the following list, with the exception of the listed processors
exporting MDS_NO while Intel TSX is available yet not enabled. The
latter class of processors are only affected when Intel TSX is enabled
by software using TSX_CTRL_MSR otherwise they are not affected.

============= ============ ========
common name Family_Model Stepping
============= ============ ========
IvyBridge 06_3AH All

Haswell 06_3CH All
Haswell_L 06_45H All
Haswell_G 06_46H All

Broadwell_G 06_47H All
Broadwell 06_3DH All

Skylake_L 06_4EH All
Skylake 06_5EH All

Kabylake_L 06_8EH <= 0xC
Kabylake 06_9EH <= 0xD
============= ============ ========

Related CVEs
------------

The following CVE entry is related to this SRBDS issue:

============== ===== =====================================
CVE-2020-0543 SRBDS Special Register Buffer Data Sampling
============== ===== =====================================

Attack scenarios
----------------
An unprivileged user can extract values returned from RDRAND and RDSEED
executed on another core or sibling thread using MDS techniques.


Mitigation mechanism
-------------------
Intel will release microcode updates that modify the RDRAND, RDSEED, and
EGETKEY instructions to overwrite secret special register data in the shared
staging buffer before the secret data can be accessed by another logical
processor.

During execution of the RDRAND, RDSEED, or EGETKEY instructions, off-core
accesses from other logical processors will be delayed until the special
register read is complete and the secret data in the shared staging buffer is
overwritten.

This has three effects on performance:

#. RDRAND, RDSEED, or EGETKEY instructions have higher latency.

#. Executing RDRAND at the same time on multiple logical processors will be
serialized, resulting in an overall reduction in the maximum RDRAND
bandwidth.

#. Executing RDRAND, RDSEED or EGETKEY will delay memory accesses from other
logical processors that miss their core caches, with an impact similar to
legacy locked cache-line-split accesses.

The microcode updates provide an opt-out mechanism (RNGDS_MITG_DIS) to disable
the mitigation for RDRAND and RDSEED instructions executed outside of Intel
Software Guard Extensions (Intel SGX) enclaves. On logical processors that
disable the mitigation using this opt-out mechanism, RDRAND and RDSEED do not
take longer to execute and do not impact performance of sibling logical
processors memory accesses. The opt-out mechanism does not affect Intel SGX
enclaves (including execution of RDRAND or RDSEED inside an enclave, as well
as EGETKEY execution).

IA32_MCU_OPT_CTRL MSR Definition
--------------------------------
Along with the mitigation for this issue, Intel added a new thread-scope
IA32_MCU_OPT_CTRL MSR, (address 0x123). The presence of this MSR and
RNGDS_MITG_DIS (bit 0) is enumerated by CPUID.(EAX=07H,ECX=0).EDX[SRBDS_CTRL =
9]==1. This MSR is introduced through the microcode update.

Setting IA32_MCU_OPT_CTRL[0] (RNGDS_MITG_DIS) to 1 for a logical processor
disables the mitigation for RDRAND and RDSEED executed outside of an Intel SGX
enclave on that logical processor. Opting out of the mitigation for a
particular logical processor does not affect the RDRAND and RDSEED mitigations
for other logical processors.

Note that inside of an Intel SGX enclave, the mitigation is applied regardless
of the value of RNGDS_MITG_DS.

Mitigation control on the kernel command line
---------------------------------------------
The kernel command line allows control over the SRBDS mitigation at boot time
with the option "srbds=". The option for this is:

============= =============================================================
off This option disables SRBDS mitigation for RDRAND and RDSEED on
affected platforms.
============= =============================================================

SRBDS System Information
-----------------------
The Linux kernel provides vulnerability status information through sysfs. For
SRBDS this can be accessed by the following sysfs file:
/sys/devices/system/cpu/vulnerabilities/srbds

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: Microcode Processor is vulnerable and mitigation is in
effect.
Mitigation: TSX disabled Processor is only vulnerable when TSX is
enabled while this system was booted with TSX
disabled.
Unknown: Dependent on
hypervisor status Running on virtual guest processor that is
affected but with no way to know if host
processor is mitigated or vulnerable.
============================== =============================================

SRBDS Default mitigation
------------------------
This new microcode serializes processor access during execution of RDRAND,
RDSEED ensures that the shared buffer is overwritten before it is released for
reuse. Use the "srbds=off" kernel command line to disable the mitigation for
RDRAND and RDSEED.
129 changes: 129 additions & 0 deletions Documentation/sound/hd-audio/realtek-pc-beep.rst
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,129 @@
===============================
Realtek PC Beep Hidden Register
===============================

This file documents the "PC Beep Hidden Register", which is present in certain
Realtek HDA codecs and controls a muxer and pair of passthrough mixers that can
route audio between pins but aren't themselves exposed as HDA widgets. As far
as I can tell, these hidden routes are designed to allow flexible PC Beep output
for codecs that don't have mixer widgets in their output paths. Why it's easier
to hide a mixer behind an undocumented vendor register than to just expose it
as a widget, I have no idea.

Register Description
====================

The register is accessed via processing coefficient 0x36 on NID 20h. Bits not
identified below have no discernible effect on my machine, a Dell XPS 13 9350::

MSB LSB
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |h|S|L| | B |R| | Known bits
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|0|0|1|1| 0x7 |0|0x0|1| 0x7 | Reset value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1Ah input select (B): 2 bits
When zero, expose the PC Beep line (from the internal beep generator, when
enabled with the Set Beep Generation verb on NID 01h, or else from the
external PCBEEP pin) on the 1Ah pin node. When nonzero, expose the headphone
jack (or possibly Line In on some machines) input instead. If PC Beep is
selected, the 1Ah boost control has no effect.

Amplify 1Ah loopback, left (L): 1 bit
Amplify the left channel of 1Ah before mixing it into outputs as specified
by h and S bits. Does not affect the level of 1Ah exposed to other widgets.

Amplify 1Ah loopback, right (R): 1 bit
Amplify the right channel of 1Ah before mixing it into outputs as specified
by h and S bits. Does not affect the level of 1Ah exposed to other widgets.

Loopback 1Ah to 21h [active low] (h): 1 bit
When zero, mix 1Ah (possibly with amplification, depending on L and R bits)
into 21h (headphone jack on my machine). Mixed signal respects the mute
setting on 21h.

Loopback 1Ah to 14h (S): 1 bit
When one, mix 1Ah (possibly with amplification, depending on L and R bits)
into 14h (internal speaker on my machine). Mixed signal **ignores** the mute
setting on 14h and is present whenever 14h is configured as an output.

Path diagrams
=============

1Ah input selection (DIV is the PC Beep divider set on NID 01h)::

<Beep generator> <PCBEEP pin> <Headphone jack>
| | |
+--DIV--+--!DIV--+ {1Ah boost control}
| |
+--(b == 0)--+--(b != 0)--+
|
>1Ah (Beep/Headphone Mic/Line In)<

Loopback of 1Ah to 21h/14h::

<1Ah (Beep/Headphone Mic/Line In)>
|
{amplify if L/R}
|
+-----!h-----+-----S-----+
| |
{21h mute control} |
| |
>21h (Headphone)< >14h (Internal Speaker)<

Background
==========

All Realtek HDA codecs have a vendor-defined widget with node ID 20h which
provides access to a bank of registers that control various codec functions.
Registers are read and written via the standard HDA processing coefficient
verbs (Set/Get Coefficient Index, Set/Get Processing Coefficient). The node is
named "Realtek Vendor Registers" in public datasheets' verb listings and,
apart from that, is entirely undocumented.

This particular register, exposed at coefficient 0x36 and named in commits from
Realtek, is of note: unlike most registers, which seem to control detailed
amplifier parameters not in scope of the HDA specification, it controls audio
routing which could just as easily have been defined using standard HDA mixer
and selector widgets.

Specifically, it selects between two sources for the input pin widget with Node
ID (NID) 1Ah: the widget's signal can come either from an audio jack (on my
laptop, a Dell XPS 13 9350, it's the headphone jack, but comments in Realtek
commits indicate that it might be a Line In on some machines) or from the PC
Beep line (which is itself multiplexed between the codec's internal beep
generator and external PCBEEP pin, depending on if the beep generator is
enabled via verbs on NID 01h). Additionally, it can mix (with optional
amplification) that signal onto the 21h and/or 14h output pins.

The register's reset value is 0x3717, corresponding to PC Beep on 1Ah that is
then amplified and mixed into both the headphones and the speakers. Not only
does this violate the HDA specification, which says that "[a vendor defined
beep input pin] connection may be maintained *only* while the Link reset
(**RST#**) is asserted", it means that we cannot ignore the register if we care
about the input that 1Ah would otherwise expose or if the PCBEEP trace is
poorly shielded and picks up chassis noise (both of which are the case on my
machine).

Unfortunately, there are lots of ways to get this register configuration wrong.
Linux, it seems, has gone through most of them. For one, the register resets
after S3 suspend: judging by existing code, this isn't the case for all vendor
registers, and it's led to some fixes that improve behavior on cold boot but
don't last after suspend. Other fixes have successfully switched the 1Ah input
away from PC Beep but have failed to disable both loopback paths. On my
machine, this means that the headphone input is amplified and looped back to
the headphone output, which uses the exact same pins! As you might expect, this
causes terrible headphone noise, the character of which is controlled by the
1Ah boost control. (If you've seen instructions online to fix XPS 13 headphone
noise by changing "Headphone Mic Boost" in ALSA, now you know why.)

The information here has been obtained through black-box reverse engineering of
the ALC256 codec's behavior and is not guaranteed to be correct. It likely
also applies for the ALC255, ALC257, ALC235, and ALC236, since those codecs
seem to be close relatives of the ALC256. (They all share one initialization
function.) Additionally, other codecs like the ALC225 and ALC285 also have this
register, judging by existing fixups in ``patch_realtek.c``, but specific
data (e.g. node IDs, bit positions, pin mappings) for those codecs may differ
from what I've described here.
83 changes: 83 additions & 0 deletions drivers/media/rc/keymaps/rc-videostrong-kii-pro.c
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,83 @@
// SPDX-License-Identifier: GPL-2.0+
//
// Copyright (C) 2019 Mohammad Rasim <mohammad.rasim96@gmail.com>

#include <media/rc-map.h>
#include <linux/module.h>

//
// Keytable for the Videostrong KII Pro STB remote control
//

static struct rc_map_table kii_pro[] = {
{ 0x59, KEY_POWER },
{ 0x19, KEY_MUTE },
{ 0x42, KEY_RED },
{ 0x40, KEY_GREEN },
{ 0x00, KEY_YELLOW },
{ 0x03, KEY_BLUE },
{ 0x4a, KEY_BACK },
{ 0x48, KEY_FORWARD },
{ 0x08, KEY_PREVIOUSSONG},
{ 0x0b, KEY_NEXTSONG},
{ 0x46, KEY_PLAYPAUSE },
{ 0x44, KEY_STOP },
{ 0x1f, KEY_FAVORITES}, //KEY_F5?
{ 0x04, KEY_PVR },
{ 0x4d, KEY_EPG },
{ 0x02, KEY_INFO },
{ 0x09, KEY_SUBTITLE },
{ 0x01, KEY_AUDIO },
{ 0x0d, KEY_HOMEPAGE },
{ 0x11, KEY_TV }, // DTV ?
{ 0x06, KEY_UP },
{ 0x5a, KEY_LEFT },
{ 0x1a, KEY_ENTER }, // KEY_OK ?
{ 0x1b, KEY_RIGHT },
{ 0x16, KEY_DOWN },
{ 0x45, KEY_MENU },
{ 0x05, KEY_ESC },
{ 0x13, KEY_VOLUMEUP },
{ 0x17, KEY_VOLUMEDOWN },
{ 0x58, KEY_APPSELECT },
{ 0x12, KEY_VENDOR }, // mouse
{ 0x55, KEY_PAGEUP }, // KEY_CHANNELUP ?
{ 0x15, KEY_PAGEDOWN }, // KEY_CHANNELDOWN ?
{ 0x52, KEY_1 },
{ 0x50, KEY_2 },
{ 0x10, KEY_3 },
{ 0x56, KEY_4 },
{ 0x54, KEY_5 },
{ 0x14, KEY_6 },
{ 0x4e, KEY_7 },
{ 0x4c, KEY_8 },
{ 0x0c, KEY_9 },
{ 0x18, KEY_WWW }, // KEY_F7
{ 0x0f, KEY_0 },
{ 0x51, KEY_BACKSPACE },
};

static struct rc_map_list kii_pro_map = {
.map = {
.scan = kii_pro,
.size = ARRAY_SIZE(kii_pro),
.rc_proto = RC_PROTO_NEC,
.name = RC_MAP_KII_PRO,
}
};

static int __init init_rc_map_kii_pro(void)
{
return rc_map_register(&kii_pro_map);
}

static void __exit exit_rc_map_kii_pro(void)
{
rc_map_unregister(&kii_pro_map);
}

module_init(init_rc_map_kii_pro)
module_exit(exit_rc_map_kii_pro)

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Mohammad Rasim <mohammad.rasim96@gmail.com>");
Loading

0 comments on commit 824c647

Please sign in to comment.