mirror of
https://github.com/linux-msm/laptops-kernel.git
synced 2026-08-13 14:19:53 -07:00
Merge v6.10-rc6 into drm-next
The exynos-next pull is based on a newer -rc than drm-next. hence backmerge first to make sure the unrelated conflicts we accumulated don't end up randomly in the exynos merge pull, but are separated out. Conflicts are all benign: Adjacent changes in amdgpu and fbdev-dma code, and cherry-pick conflict in xe. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This commit is contained in:
Daniel Vetter
@@ -5,7 +5,6 @@ root = true
|
||||
[{*.{awk,c,dts,dtsi,dtso,h,mk,s,S},Kconfig,Makefile,Makefile.*}]
|
||||
charset = utf-8
|
||||
end_of_line = lf
|
||||
trim_trailing_whitespace = true
|
||||
insert_final_newline = true
|
||||
indent_style = tab
|
||||
indent_size = 8
|
||||
@@ -13,7 +12,6 @@ indent_size = 8
|
||||
[*.{json,py,rs}]
|
||||
charset = utf-8
|
||||
end_of_line = lf
|
||||
trim_trailing_whitespace = true
|
||||
insert_final_newline = true
|
||||
indent_style = space
|
||||
indent_size = 4
|
||||
@@ -26,7 +24,6 @@ indent_size = 8
|
||||
[*.yaml]
|
||||
charset = utf-8
|
||||
end_of_line = lf
|
||||
trim_trailing_whitespace = unset
|
||||
insert_final_newline = true
|
||||
indent_style = space
|
||||
indent_size = 2
|
||||
|
||||
@@ -72,6 +72,8 @@ Andrey Ryabinin <ryabinin.a.a@gmail.com> <aryabinin@virtuozzo.com>
|
||||
Andrzej Hajda <andrzej.hajda@intel.com> <a.hajda@samsung.com>
|
||||
André Almeida <andrealmeid@igalia.com> <andrealmeid@collabora.com>
|
||||
Andy Adamson <andros@citi.umich.edu>
|
||||
Andy Shevchenko <andy@kernel.org> <andy@smile.org.ua>
|
||||
Andy Shevchenko <andy@kernel.org> <ext-andriy.shevchenko@nokia.com>
|
||||
Anilkumar Kolli <quic_akolli@quicinc.com> <akolli@codeaurora.org>
|
||||
Anirudh Ghayal <quic_aghayal@quicinc.com> <aghayal@codeaurora.org>
|
||||
Antoine Tenart <atenart@kernel.org> <antoine.tenart@bootlin.com>
|
||||
@@ -217,6 +219,7 @@ Geliang Tang <geliang@kernel.org> <geliang.tang@suse.com>
|
||||
Geliang Tang <geliang@kernel.org> <geliangtang@xiaomi.com>
|
||||
Geliang Tang <geliang@kernel.org> <geliangtang@gmail.com>
|
||||
Geliang Tang <geliang@kernel.org> <geliangtang@163.com>
|
||||
Geliang Tang <geliang@kernel.org> <tanggeliang@kylinos.cn>
|
||||
Georgi Djakov <djakov@kernel.org> <georgi.djakov@linaro.org>
|
||||
Gerald Schaefer <gerald.schaefer@linux.ibm.com> <geraldsc@de.ibm.com>
|
||||
Gerald Schaefer <gerald.schaefer@linux.ibm.com> <gerald.schaefer@de.ibm.com>
|
||||
@@ -605,6 +608,7 @@ Simon Kelley <simon@thekelleys.org.uk>
|
||||
Sricharan Ramabadhran <quic_srichara@quicinc.com> <sricharan@codeaurora.org>
|
||||
Srinivas Ramana <quic_sramana@quicinc.com> <sramana@codeaurora.org>
|
||||
Sriram R <quic_srirrama@quicinc.com> <srirrama@codeaurora.org>
|
||||
Stanislav Fomichev <sdf@fomichev.me> <sdf@google.com>
|
||||
Stefan Wahren <wahrenst@gmx.net> <stefan.wahren@i2se.com>
|
||||
Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr>
|
||||
Stephen Hemminger <stephen@networkplumber.org> <shemminger@linux-foundation.org>
|
||||
|
||||
@@ -788,25 +788,6 @@
|
||||
Documentation/networking/netconsole.rst for an
|
||||
alternative.
|
||||
|
||||
<DEVNAME>:<n>.<n>[,options]
|
||||
Use the specified serial port on the serial core bus.
|
||||
The addressing uses DEVNAME of the physical serial port
|
||||
device, followed by the serial core controller instance,
|
||||
and the serial port instance. The options are the same
|
||||
as documented for the ttyS addressing above.
|
||||
|
||||
The mapping of the serial ports to the tty instances
|
||||
can be viewed with:
|
||||
|
||||
$ ls -d /sys/bus/serial-base/devices/*:*.*/tty/*
|
||||
/sys/bus/serial-base/devices/00:04:0.0/tty/ttyS0
|
||||
|
||||
In the above example, the console can be addressed with
|
||||
console=00:04:0.0. Note that a console addressed this
|
||||
way will only get added when the related device driver
|
||||
is ready. The use of an earlycon parameter in addition to
|
||||
the console may be desired for console output early on.
|
||||
|
||||
uart[8250],io,<addr>[,options]
|
||||
uart[8250],mmio,<addr>[,options]
|
||||
uart[8250],mmio16,<addr>[,options]
|
||||
@@ -2192,12 +2173,6 @@
|
||||
Format: 0 | 1
|
||||
Default set by CONFIG_INIT_ON_FREE_DEFAULT_ON.
|
||||
|
||||
init_mlocked_on_free= [MM] Fill freed userspace memory with zeroes if
|
||||
it was mlock'ed and not explicitly munlock'ed
|
||||
afterwards.
|
||||
Format: 0 | 1
|
||||
Default set by CONFIG_INIT_MLOCKED_ON_FREE_DEFAULT_ON
|
||||
|
||||
init_pkru= [X86] Specify the default memory protection keys rights
|
||||
register contents for all processes. 0x55555554 by
|
||||
default (disallow access to all but pkey 0). Can
|
||||
|
||||
@@ -59,8 +59,8 @@ properties:
|
||||
- 3
|
||||
|
||||
dma-channels:
|
||||
minItems: 1
|
||||
maxItems: 64
|
||||
minimum: 1
|
||||
maximum: 64
|
||||
|
||||
clocks:
|
||||
minItems: 1
|
||||
|
||||
@@ -77,7 +77,7 @@ required:
|
||||
- clocks
|
||||
|
||||
allOf:
|
||||
- $ref: i2c-controller.yaml
|
||||
- $ref: /schemas/i2c/i2c-controller.yaml#
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
|
||||
@@ -21,7 +21,7 @@ description: |
|
||||
google,cros-ec-spi or google,cros-ec-i2c.
|
||||
|
||||
allOf:
|
||||
- $ref: i2c-controller.yaml#
|
||||
- $ref: /schemas/i2c/i2c-controller.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
||||
@@ -139,7 +139,7 @@ allOf:
|
||||
Voltage output range of the channel as <minimum, maximum>
|
||||
Required connections:
|
||||
Rfb1x for: 0 to 2.5 V; 0 to 3V; 0 to 5 V;
|
||||
Rfb2x for: 0 to 10 V; 2.5 to 7.5V; -5 to 5 V;
|
||||
Rfb2x for: 0 to 10 V; -2.5 to 7.5V; -5 to 5 V;
|
||||
oneOf:
|
||||
- items:
|
||||
- const: 0
|
||||
|
||||
@@ -128,7 +128,6 @@ required:
|
||||
- cell-index
|
||||
- reg
|
||||
- fsl,fman-ports
|
||||
- ptp-timer
|
||||
|
||||
dependencies:
|
||||
pcs-handle-names:
|
||||
|
||||
@@ -29,7 +29,6 @@ properties:
|
||||
- qcom,pm7325-gpio
|
||||
- qcom,pm7550ba-gpio
|
||||
- qcom,pm8005-gpio
|
||||
- qcom,pm8008-gpio
|
||||
- qcom,pm8018-gpio
|
||||
- qcom,pm8019-gpio
|
||||
- qcom,pm8038-gpio
|
||||
@@ -126,7 +125,6 @@ allOf:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- qcom,pm8008-gpio
|
||||
- qcom,pmi8950-gpio
|
||||
- qcom,pmr735d-gpio
|
||||
then:
|
||||
@@ -448,7 +446,6 @@ $defs:
|
||||
- gpio1-gpio10 for pm7325
|
||||
- gpio1-gpio8 for pm7550ba
|
||||
- gpio1-gpio4 for pm8005
|
||||
- gpio1-gpio2 for pm8008
|
||||
- gpio1-gpio6 for pm8018
|
||||
- gpio1-gpio12 for pm8038
|
||||
- gpio1-gpio40 for pm8058
|
||||
|
||||
@@ -65,6 +65,7 @@ patternProperties:
|
||||
description: The hard wired USB devices
|
||||
type: object
|
||||
$ref: /schemas/usb/usb-device.yaml
|
||||
additionalProperties: true
|
||||
|
||||
required:
|
||||
- peer-hub
|
||||
|
||||
@@ -571,6 +571,7 @@ encoded manner. The codes are the following:
|
||||
um userfaultfd missing tracking
|
||||
uw userfaultfd wr-protect tracking
|
||||
ss shadow stack page
|
||||
sl sealed
|
||||
== =======================================
|
||||
|
||||
Note that there is no guarantee that every flag and associated mnemonic will
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!-- Created with Inkscape (http://www.inkscape.org/) -->
|
||||
<!-- Updated to inclusive terminology by Wolfram Sang -->
|
||||
|
||||
<svg
|
||||
xmlns:dc="http://purl.org/dc/elements/1.1/"
|
||||
@@ -1120,7 +1121,7 @@
|
||||
<rect
|
||||
style="opacity:1;fill:#ffb9b9;fill-opacity:1;stroke:#f00000;stroke-width:2.8125;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
id="rect4424-3-2-9-7"
|
||||
width="112.5"
|
||||
width="134.5"
|
||||
height="113.75008"
|
||||
x="112.5"
|
||||
y="471.11221"
|
||||
@@ -1133,15 +1134,15 @@
|
||||
y="521.46259"
|
||||
id="text4349"><tspan
|
||||
sodipodi:role="line"
|
||||
x="167.5354"
|
||||
x="178.5354"
|
||||
y="521.46259"
|
||||
style="font-size:25px;line-height:1.25;font-family:sans-serif;text-align:center;text-anchor:middle"
|
||||
id="tspan1273">I2C</tspan><tspan
|
||||
sodipodi:role="line"
|
||||
x="167.5354"
|
||||
x="178.5354"
|
||||
y="552.71259"
|
||||
style="font-size:25px;line-height:1.25;font-family:sans-serif;text-align:center;text-anchor:middle"
|
||||
id="tspan1285">Master</tspan></text>
|
||||
id="tspan1285">Controller</tspan></text>
|
||||
<rect
|
||||
style="color:#000000;clip-rule:nonzero;display:inline;overflow:visible;visibility:visible;opacity:1;isolation:auto;mix-blend-mode:normal;color-interpolation:sRGB;color-interpolation-filters:linearRGB;solid-color:#000000;solid-opacity:1;fill:#b9ffb9;fill-opacity:1;fill-rule:nonzero;stroke:#006400;stroke-width:2.8125;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;color-rendering:auto;image-rendering:auto;shape-rendering:auto;text-rendering:auto;enable-background:accumulate"
|
||||
id="rect4424-3-2-9-7-3-3-5-3"
|
||||
@@ -1171,7 +1172,7 @@
|
||||
x="318.59131"
|
||||
y="552.08752"
|
||||
style="font-size:25.00000191px;line-height:1.25;font-family:sans-serif;text-align:center;text-anchor:middle;stroke-width:1px"
|
||||
id="tspan1287">Slave</tspan></text>
|
||||
id="tspan1287">Target</tspan></text>
|
||||
<path
|
||||
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1.99968767;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
d="m 112.49995,677.36223 c 712.50005,0 712.50005,0 712.50005,0"
|
||||
@@ -1233,7 +1234,7 @@
|
||||
x="468.59131"
|
||||
y="552.08746"
|
||||
style="font-size:25.00000191px;line-height:1.25;font-family:sans-serif;text-align:center;text-anchor:middle;stroke-width:1px"
|
||||
id="tspan1287-6">Slave</tspan></text>
|
||||
id="tspan1287-6">Target</tspan></text>
|
||||
<rect
|
||||
style="color:#000000;clip-rule:nonzero;display:inline;overflow:visible;visibility:visible;opacity:1;isolation:auto;mix-blend-mode:normal;color-interpolation:sRGB;color-interpolation-filters:linearRGB;solid-color:#000000;solid-opacity:1;vector-effect:none;fill:#b9ffb9;fill-opacity:1;fill-rule:nonzero;stroke:#006400;stroke-width:2.8125;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;color-rendering:auto;image-rendering:auto;shape-rendering:auto;text-rendering:auto;enable-background:accumulate"
|
||||
id="rect4424-3-2-9-7-3-3-5-3-1"
|
||||
@@ -1258,7 +1259,7 @@
|
||||
x="618.59131"
|
||||
y="552.08746"
|
||||
style="font-size:25.00000191px;line-height:1.25;font-family:sans-serif;text-align:center;text-anchor:middle;stroke-width:1px"
|
||||
id="tspan1287-9">Slave</tspan></text>
|
||||
id="tspan1287-9">Target</tspan></text>
|
||||
<path
|
||||
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1.99968743;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#DotM)"
|
||||
d="m 150,583.61221 v 93.75"
|
||||
|
||||
|
Before Width: | Height: | Size: 55 KiB After Width: | Height: | Size: 55 KiB |
@@ -3,29 +3,27 @@ Introduction to I2C and SMBus
|
||||
=============================
|
||||
|
||||
I²C (pronounce: I squared C and written I2C in the kernel documentation) is
|
||||
a protocol developed by Philips. It is a slow two-wire protocol (variable
|
||||
speed, up to 400 kHz), with a high speed extension (3.4 MHz). It provides
|
||||
a protocol developed by Philips. It is a two-wire protocol with variable
|
||||
speed (typically up to 400 kHz, high speed modes up to 5 MHz). It provides
|
||||
an inexpensive bus for connecting many types of devices with infrequent or
|
||||
low bandwidth communications needs. I2C is widely used with embedded
|
||||
systems. Some systems use variants that don't meet branding requirements,
|
||||
low bandwidth communications needs. I2C is widely used with embedded
|
||||
systems. Some systems use variants that don't meet branding requirements,
|
||||
and so are not advertised as being I2C but come under different names,
|
||||
e.g. TWI (Two Wire Interface), IIC.
|
||||
|
||||
The latest official I2C specification is the `"I2C-bus specification and user
|
||||
manual" (UM10204) <https://www.nxp.com/webapp/Download?colCode=UM10204>`_
|
||||
published by NXP Semiconductors. However, you need to log-in to the site to
|
||||
access the PDF. An older version of the specification (revision 6) is archived
|
||||
`here <https://web.archive.org/web/20210813122132/https://www.nxp.com/docs/en/user-guide/UM10204.pdf>`_.
|
||||
The latest official I2C specification is the `"I²C-bus specification and user
|
||||
manual" (UM10204) <https://www.nxp.com/docs/en/user-guide/UM10204.pdf>`_
|
||||
published by NXP Semiconductors, version 7 as of this writing.
|
||||
|
||||
SMBus (System Management Bus) is based on the I2C protocol, and is mostly
|
||||
a subset of I2C protocols and signaling. Many I2C devices will work on an
|
||||
a subset of I2C protocols and signaling. Many I2C devices will work on an
|
||||
SMBus, but some SMBus protocols add semantics beyond what is required to
|
||||
achieve I2C branding. Modern PC mainboards rely on SMBus. The most common
|
||||
achieve I2C branding. Modern PC mainboards rely on SMBus. The most common
|
||||
devices connected through SMBus are RAM modules configured using I2C EEPROMs,
|
||||
and hardware monitoring chips.
|
||||
|
||||
Because the SMBus is mostly a subset of the generalized I2C bus, we can
|
||||
use its protocols on many I2C systems. However, there are systems that don't
|
||||
use its protocols on many I2C systems. However, there are systems that don't
|
||||
meet both SMBus and I2C electrical constraints; and others which can't
|
||||
implement all the common SMBus protocol semantics or messages.
|
||||
|
||||
@@ -33,29 +31,52 @@ implement all the common SMBus protocol semantics or messages.
|
||||
Terminology
|
||||
===========
|
||||
|
||||
Using the terminology from the official documentation, the I2C bus connects
|
||||
one or more *master* chips and one or more *slave* chips.
|
||||
The I2C bus connects one or more controller chips and one or more target chips.
|
||||
|
||||
.. kernel-figure:: i2c_bus.svg
|
||||
:alt: Simple I2C bus with one master and 3 slaves
|
||||
:alt: Simple I2C bus with one controller and 3 targets
|
||||
|
||||
Simple I2C bus
|
||||
|
||||
A **master** chip is a node that starts communications with slaves. In the
|
||||
Linux kernel implementation it is called an **adapter** or bus. Adapter
|
||||
drivers are in the ``drivers/i2c/busses/`` subdirectory.
|
||||
A **controller** chip is a node that starts communications with targets. In the
|
||||
Linux kernel implementation it is also called an "adapter" or "bus". Controller
|
||||
drivers are usually in the ``drivers/i2c/busses/`` subdirectory.
|
||||
|
||||
An **algorithm** contains general code that can be used to implement a
|
||||
whole class of I2C adapters. Each specific adapter driver either depends on
|
||||
an algorithm driver in the ``drivers/i2c/algos/`` subdirectory, or includes
|
||||
its own implementation.
|
||||
An **algorithm** contains general code that can be used to implement a whole
|
||||
class of I2C controllers. Each specific controller driver either depends on an
|
||||
algorithm driver in the ``drivers/i2c/algos/`` subdirectory, or includes its
|
||||
own implementation.
|
||||
|
||||
A **slave** chip is a node that responds to communications when addressed
|
||||
by the master. In Linux it is called a **client**. Client drivers are kept
|
||||
in a directory specific to the feature they provide, for example
|
||||
``drivers/media/gpio/`` for GPIO expanders and ``drivers/media/i2c/`` for
|
||||
A **target** chip is a node that responds to communications when addressed by a
|
||||
controller. In the Linux kernel implementation it is also called a "client".
|
||||
While targets are usually separate external chips, Linux can also act as a
|
||||
target (needs hardware support) and respond to another controller on the bus.
|
||||
This is then called a **local target**. In contrast, an external chip is called
|
||||
a **remote target**.
|
||||
|
||||
Target drivers are kept in a directory specific to the feature they provide,
|
||||
for example ``drivers/gpio/`` for GPIO expanders and ``drivers/media/i2c/`` for
|
||||
video-related chips.
|
||||
|
||||
For the example configuration in figure, you will need a driver for your
|
||||
I2C adapter, and drivers for your I2C devices (usually one driver for each
|
||||
device).
|
||||
For the example configuration in the figure above, you will need one driver for
|
||||
the I2C controller, and drivers for your I2C targets. Usually one driver for
|
||||
each target.
|
||||
|
||||
Synonyms
|
||||
--------
|
||||
|
||||
As mentioned above, the Linux I2C implementation historically uses the terms
|
||||
"adapter" for controller and "client" for target. A number of data structures
|
||||
have these synonyms in their name. So, when discussing implementation details,
|
||||
you should be aware of these terms as well. The official wording is preferred,
|
||||
though.
|
||||
|
||||
Outdated terminology
|
||||
--------------------
|
||||
|
||||
In earlier I2C specifications, controller was named "master" and target was
|
||||
named "slave". These terms have been obsoleted with v7 of the specification and
|
||||
their use is also discouraged by the Linux Kernel Code of Conduct. You may
|
||||
still find them in references to documentation which has not been updated. The
|
||||
general attitude, however, is to use the inclusive terms: controller and
|
||||
target. Work to replace the old terminology in the Linux Kernel is on-going.
|
||||
|
||||
@@ -128,7 +128,7 @@ executed to make module versioning work.
|
||||
|
||||
modules_install
|
||||
Install the external module(s). The default location is
|
||||
/lib/modules/<kernel_release>/extra/, but a prefix may
|
||||
/lib/modules/<kernel_release>/updates/, but a prefix may
|
||||
be added with INSTALL_MOD_PATH (discussed in section 5).
|
||||
|
||||
clean
|
||||
@@ -417,7 +417,7 @@ directory:
|
||||
|
||||
And external modules are installed in:
|
||||
|
||||
/lib/modules/$(KERNELRELEASE)/extra/
|
||||
/lib/modules/$(KERNELRELEASE)/updates/
|
||||
|
||||
5.1 INSTALL_MOD_PATH
|
||||
--------------------
|
||||
@@ -438,10 +438,10 @@ And external modules are installed in:
|
||||
-------------------
|
||||
|
||||
External modules are by default installed to a directory under
|
||||
/lib/modules/$(KERNELRELEASE)/extra/, but you may wish to
|
||||
/lib/modules/$(KERNELRELEASE)/updates/, but you may wish to
|
||||
locate modules for a specific functionality in a separate
|
||||
directory. For this purpose, use INSTALL_MOD_DIR to specify an
|
||||
alternative name to "extra."::
|
||||
alternative name to "updates."::
|
||||
|
||||
$ make INSTALL_MOD_DIR=gandalf -C $KDIR \
|
||||
M=$PWD modules_install
|
||||
|
||||
@@ -1603,7 +1603,7 @@ operations:
|
||||
attributes:
|
||||
- header
|
||||
reply:
|
||||
attributes: &pse
|
||||
attributes:
|
||||
- header
|
||||
- podl-pse-admin-state
|
||||
- podl-pse-admin-control
|
||||
@@ -1620,7 +1620,10 @@ operations:
|
||||
|
||||
do:
|
||||
request:
|
||||
attributes: *pse
|
||||
attributes:
|
||||
- header
|
||||
- podl-pse-admin-control
|
||||
- c33-pse-admin-control
|
||||
-
|
||||
name: rss-get
|
||||
doc: Get RSS params.
|
||||
|
||||
@@ -123,8 +123,6 @@ operations:
|
||||
doc: dump pending nfsd rpc
|
||||
attribute-set: rpc-status
|
||||
dump:
|
||||
pre: nfsd-nl-rpc-status-get-start
|
||||
post: nfsd-nl-rpc-status-get-done
|
||||
reply:
|
||||
attributes:
|
||||
- xid
|
||||
|
||||
@@ -32,6 +32,7 @@ Security-related interfaces
|
||||
seccomp_filter
|
||||
landlock
|
||||
lsm
|
||||
mfd_noexec
|
||||
spec_ctrl
|
||||
tee
|
||||
|
||||
|
||||
@@ -0,0 +1,86 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
==================================
|
||||
Introduction of non-executable mfd
|
||||
==================================
|
||||
:Author:
|
||||
Daniel Verkamp <dverkamp@chromium.org>
|
||||
Jeff Xu <jeffxu@chromium.org>
|
||||
|
||||
:Contributor:
|
||||
Aleksa Sarai <cyphar@cyphar.com>
|
||||
|
||||
Since Linux introduced the memfd feature, memfds have always had their
|
||||
execute bit set, and the memfd_create() syscall doesn't allow setting
|
||||
it differently.
|
||||
|
||||
However, in a secure-by-default system, such as ChromeOS, (where all
|
||||
executables should come from the rootfs, which is protected by verified
|
||||
boot), this executable nature of memfd opens a door for NoExec bypass
|
||||
and enables “confused deputy attack”. E.g, in VRP bug [1]: cros_vm
|
||||
process created a memfd to share the content with an external process,
|
||||
however the memfd is overwritten and used for executing arbitrary code
|
||||
and root escalation. [2] lists more VRP of this kind.
|
||||
|
||||
On the other hand, executable memfd has its legit use: runc uses memfd’s
|
||||
seal and executable feature to copy the contents of the binary then
|
||||
execute them. For such a system, we need a solution to differentiate runc's
|
||||
use of executable memfds and an attacker's [3].
|
||||
|
||||
To address those above:
|
||||
- Let memfd_create() set X bit at creation time.
|
||||
- Let memfd be sealed for modifying X bit when NX is set.
|
||||
- Add a new pid namespace sysctl: vm.memfd_noexec to help applications in
|
||||
migrating and enforcing non-executable MFD.
|
||||
|
||||
User API
|
||||
========
|
||||
``int memfd_create(const char *name, unsigned int flags)``
|
||||
|
||||
``MFD_NOEXEC_SEAL``
|
||||
When MFD_NOEXEC_SEAL bit is set in the ``flags``, memfd is created
|
||||
with NX. F_SEAL_EXEC is set and the memfd can't be modified to
|
||||
add X later. MFD_ALLOW_SEALING is also implied.
|
||||
This is the most common case for the application to use memfd.
|
||||
|
||||
``MFD_EXEC``
|
||||
When MFD_EXEC bit is set in the ``flags``, memfd is created with X.
|
||||
|
||||
Note:
|
||||
``MFD_NOEXEC_SEAL`` implies ``MFD_ALLOW_SEALING``. In case that
|
||||
an app doesn't want sealing, it can add F_SEAL_SEAL after creation.
|
||||
|
||||
|
||||
Sysctl:
|
||||
========
|
||||
``pid namespaced sysctl vm.memfd_noexec``
|
||||
|
||||
The new pid namespaced sysctl vm.memfd_noexec has 3 values:
|
||||
|
||||
- 0: MEMFD_NOEXEC_SCOPE_EXEC
|
||||
memfd_create() without MFD_EXEC nor MFD_NOEXEC_SEAL acts like
|
||||
MFD_EXEC was set.
|
||||
|
||||
- 1: MEMFD_NOEXEC_SCOPE_NOEXEC_SEAL
|
||||
memfd_create() without MFD_EXEC nor MFD_NOEXEC_SEAL acts like
|
||||
MFD_NOEXEC_SEAL was set.
|
||||
|
||||
- 2: MEMFD_NOEXEC_SCOPE_NOEXEC_ENFORCED
|
||||
memfd_create() without MFD_NOEXEC_SEAL will be rejected.
|
||||
|
||||
The sysctl allows finer control of memfd_create for old software that
|
||||
doesn't set the executable bit; for example, a container with
|
||||
vm.memfd_noexec=1 means the old software will create non-executable memfd
|
||||
by default while new software can create executable memfd by setting
|
||||
MFD_EXEC.
|
||||
|
||||
The value of vm.memfd_noexec is passed to child namespace at creation
|
||||
time. In addition, the setting is hierarchical, i.e. during memfd_create,
|
||||
we will search from current ns to root ns and use the most restrictive
|
||||
setting.
|
||||
|
||||
[1] https://crbug.com/1305267
|
||||
|
||||
[2] https://bugs.chromium.org/p/chromium/issues/list?q=type%3Dbug-security%20memfd%20escalation&can=1
|
||||
|
||||
[3] https://lwn.net/Articles/781013/
|
||||
@@ -62,12 +62,21 @@ shared page with scale and offset values into user space. User
|
||||
space code performs the same algorithm of reading the TSC and
|
||||
applying the scale and offset to get the constant 10 MHz clock.
|
||||
|
||||
Linux clockevents are based on Hyper-V synthetic timer 0. While
|
||||
Hyper-V offers 4 synthetic timers for each CPU, Linux only uses
|
||||
timer 0. Interrupts from stimer0 are recorded on the "HVS" line in
|
||||
/proc/interrupts. Clockevents based on the virtualized PIT and
|
||||
local APIC timer also work, but the Hyper-V synthetic timer is
|
||||
preferred.
|
||||
Linux clockevents are based on Hyper-V synthetic timer 0 (stimer0).
|
||||
While Hyper-V offers 4 synthetic timers for each CPU, Linux only uses
|
||||
timer 0. In older versions of Hyper-V, an interrupt from stimer0
|
||||
results in a VMBus control message that is demultiplexed by
|
||||
vmbus_isr() as described in the Documentation/virt/hyperv/vmbus.rst
|
||||
documentation. In newer versions of Hyper-V, stimer0 interrupts can
|
||||
be mapped to an architectural interrupt, which is referred to as
|
||||
"Direct Mode". Linux prefers to use Direct Mode when available. Since
|
||||
x86/x64 doesn't support per-CPU interrupts, Direct Mode statically
|
||||
allocates an x86 interrupt vector (HYPERV_STIMER0_VECTOR) across all CPUs
|
||||
and explicitly codes it to call the stimer0 interrupt handler. Hence
|
||||
interrupts from stimer0 are recorded on the "HVS" line in /proc/interrupts
|
||||
rather than being associated with a Linux IRQ. Clockevents based on the
|
||||
virtualized PIT and local APIC timer also work, but Hyper-V stimer0
|
||||
is preferred.
|
||||
|
||||
The driver for the Hyper-V synthetic system clock and timers is
|
||||
drivers/clocksource/hyperv_timer.c.
|
||||
|
||||
@@ -40,7 +40,7 @@ Linux guests communicate with Hyper-V in four different ways:
|
||||
arm64, these synthetic registers must be accessed using explicit
|
||||
hypercalls.
|
||||
|
||||
* VMbus: VMbus is a higher-level software construct that is built on
|
||||
* VMBus: VMBus is a higher-level software construct that is built on
|
||||
the other 3 mechanisms. It is a message passing interface between
|
||||
the Hyper-V host and the Linux guest. It uses memory that is shared
|
||||
between Hyper-V and the guest, along with various signaling
|
||||
@@ -54,8 +54,8 @@ x86/x64 architecture only.
|
||||
|
||||
.. _Hyper-V Top Level Functional Spec (TLFS): https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/tlfs/tlfs
|
||||
|
||||
VMbus is not documented. This documentation provides a high-level
|
||||
overview of VMbus and how it works, but the details can be discerned
|
||||
VMBus is not documented. This documentation provides a high-level
|
||||
overview of VMBus and how it works, but the details can be discerned
|
||||
only from the code.
|
||||
|
||||
Sharing Memory
|
||||
@@ -74,7 +74,7 @@ follows:
|
||||
physical address space. How Hyper-V is told about the GPA or list
|
||||
of GPAs varies. In some cases, a single GPA is written to a
|
||||
synthetic register. In other cases, a GPA or list of GPAs is sent
|
||||
in a VMbus message.
|
||||
in a VMBus message.
|
||||
|
||||
* Hyper-V translates the GPAs into "real" physical memory addresses,
|
||||
and creates a virtual mapping that it can use to access the memory.
|
||||
@@ -133,9 +133,9 @@ only the CPUs actually present in the VM, so Linux does not report
|
||||
any hot-add CPUs.
|
||||
|
||||
A Linux guest CPU may be taken offline using the normal Linux
|
||||
mechanisms, provided no VMbus channel interrupts are assigned to
|
||||
the CPU. See the section on VMbus Interrupts for more details
|
||||
on how VMbus channel interrupts can be re-assigned to permit
|
||||
mechanisms, provided no VMBus channel interrupts are assigned to
|
||||
the CPU. See the section on VMBus Interrupts for more details
|
||||
on how VMBus channel interrupts can be re-assigned to permit
|
||||
taking a CPU offline.
|
||||
|
||||
32-bit and 64-bit
|
||||
@@ -169,14 +169,14 @@ and functionality. Hyper-V indicates feature/function availability
|
||||
via flags in synthetic MSRs that Hyper-V provides to the guest,
|
||||
and the guest code tests these flags.
|
||||
|
||||
VMbus has its own protocol version that is negotiated during the
|
||||
initial VMbus connection from the guest to Hyper-V. This version
|
||||
VMBus has its own protocol version that is negotiated during the
|
||||
initial VMBus connection from the guest to Hyper-V. This version
|
||||
number is also output to dmesg during boot. This version number
|
||||
is checked in a few places in the code to determine if specific
|
||||
functionality is present.
|
||||
|
||||
Furthermore, each synthetic device on VMbus also has a protocol
|
||||
version that is separate from the VMbus protocol version. Device
|
||||
Furthermore, each synthetic device on VMBus also has a protocol
|
||||
version that is separate from the VMBus protocol version. Device
|
||||
drivers for these synthetic devices typically negotiate the device
|
||||
protocol version, and may test that protocol version to determine
|
||||
if specific device functionality is present.
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user