A successful call to NOTIFY_RETRIEVE by filesystem carries promise from
the kernel to send back NOTIFY_REPLY message. However if the filesystem
is not reading requests with fuse_conn->max_pages capacity,
fuse_dev_do_read might see that the "request is too large" and decide to
"reply with an error and restart the read". "Reply with an error" has
underlying assumption that there is a "requester thread" that is waiting
for request completion, which is true for most requests, but is not true
for NOTIFY_REPLY: NOTIFY_RETRIEVE handler completes with OK status right
after it could successfully queue NOTIFY_REPLY message without waiting
for NOTIFY_REPLY completion. This leads to situation when filesystem
requested to retrieve inode data with NOTIFY_RETRIEVE, got err=OK for
that notification request, but NOTIFY_REPLY is not coming back.
More, since there is no "requester thread" to handle the error, the
situation shows itself as /sys/fs/fuse/connections/X/waiting=1 _and_
/dev/fuse read(s) queued. Which is misleading since NOTIFY_REPLY request
was removed from pending queue and abandoned.
One way to fix would be to change NOTIFY_RETRIEVE handler to wait until
queued NOTIFY_REPLY is actually read back to the server and only then
return NOTIFY_RETRIEVE status. However this is change in behaviour and
would require filesystems to have at least 2 threads. In particular a
single-threaded filesystem that was previously successfully using
NOTIFY_RETRIEVE would become stuck after the change. This way of fixing
is thus not acceptable.
However we can fix it another way - by always returning NOTIFY_REPLY
irregardless of its original size - with so much data as provided read
buffer could fit. This aligns with the way NOTIFY_RETRIEVE handler
works, which already unconditionally caps requested retrieve size to
fuse_conn->max_pages. This way it should not hurt NOTIFY_RETRIEVE
semantic if we return less data than was originally requested.
This fix requires another behaviour change however - to be sure that
read buffer has enough capacity to always fit fixed NOTIFY_REPLY part
plus at least some (0 or more) data, we have to precheck the buffer
before dequeuing and handling a request. And if the buffer is very small -
return EINVAL to read in filesystem with semantic that queued read was
invalid from the viewpoint of FUSE protocol. Even though this is also
behaviour change, this should not practically cause problems: 1d3d752b47
(fuse: clean up request size limit checking), which originally removed
such EINVAL return and reworked fuse_dev_do_read to loop and retry, also
added FUSE_MIN_READ_BUFFER=8K to user-visible fuse.h with comment that
"The read buffer is required to be at least 8k ..." Even though
FUSE_MIN_READ_BUFFER is not currently checked anywhere in the kernel,
libfuse always initializes session with bufsize=32·pages and, since its
beginning, (at least from 2005) issues a warning should user modify
fuse_session->bufsize directly to be sure that queued buffers are at
least as large as that sane minimum:
https://github.com/libfuse/libfuse/blob/fuse-3.3.0-22-g63d53ecc3a/lib/fuse_…https://github.com/libfuse/libfuse/blob/fuse-3.3.0-22-g63d53ecc3a/lib/fuse_…
(semantic added in https://github.com/libfuse/libfuse/commit/044da2e9e0)
This way we should be safe to add the check for minimum read buffer size.
I've hit this bug for real with my filesystem that is using
https://github.com/hanwen/go-fuse: there was no NOTIFY_REPLY after
successful NOTIFY_RETRIEVE and the filesystem was stuck waiting,
because FUSE protocol (definition scattered through many places) states
that NOTIFY_REPLY is guaranteed to come after successful NOTIFY_RETRIEVE
(see 2d45ba381a "fuse: add retrieve request"). After inspecting
/sys/fs/fuse/connections/X/waiting and seeing it was 1, I was initially
suspecting that it was user-space who is not issuing /dev/fuse reads and
NOTIFY_REPLY is there but stuck in kernel pending queue. However tracing
what is going on in /dev/fuse exchange and in both kernel and userspace
(see https://lab.nexedi.com/kirr/wendelin.core/blob/13d2d1f8/wcfs/fusetrace)
showed that there are correctly queued /dev/fuse reads still pending
after NOTIFY_RETRIEVE returns and it is the kernel who is not replying back:
...
P2 2.215710 /dev/fuse <- qread wcfs/11399_4_r:
syscall.Syscall+48
syscall.Read+73
github.com/hanwen/go-fuse/fuse.(*Server).readRequest.func1+85github.com/hanwen/go-fuse/fuse.handleEINTR+39github.com/hanwen/go-fuse/fuse.(*Server).readRequest+355github.com/hanwen/go-fuse/fuse.(*Server).loop+107
runtime.goexit+1
P2 2.215810 /dev/fuse -> read wcfs/11399_4_r:
.56 RELEASE i8 ... (ret=64)
P2 2.215859 /dev/fuse <- write wcfs/11399_5_w:
.56 (0) ...
syscall.Syscall+48
syscall.Write+73
github.com/hanwen/go-fuse/fuse.(*Server).systemWrite.func1+76github.com/hanwen/go-fuse/fuse.handleEINTR+39github.com/hanwen/go-fuse/fuse.(*Server).systemWrite+931github.com/hanwen/go-fuse/fuse.(*Server).write+194github.com/hanwen/go-fuse/fuse.(*Server).handleRequest+179github.com/hanwen/go-fuse/fuse.(*Server).loop+399
runtime.goexit+1
P2 2.215871 /dev/fuse -> write_ack wcfs/11399_5_w (ret=16)
P2 2.215876 /dev/fuse <- qread wcfs/11399_5_r: <-- NOTE
syscall.Syscall+48
syscall.Read+73
github.com/hanwen/go-fuse/fuse.(*Server).readRequest.func1+85github.com/hanwen/go-fuse/fuse.handleEINTR+39github.com/hanwen/go-fuse/fuse.(*Server).readRequest+355github.com/hanwen/go-fuse/fuse.(*Server).loop+107
runtime.goexit+1
P0 2.221527 /dev/fuse <- qread wcfs/11401_1_r: <-- NOTE
syscall.Syscall+48
syscall.Read+73
github.com/hanwen/go-fuse/fuse.(*Server).readRequest.func1+85github.com/hanwen/go-fuse/fuse.handleEINTR+39github.com/hanwen/go-fuse/fuse.(*Server).readRequest+355github.com/hanwen/go-fuse/fuse.(*Server).loop+107
runtime.goexit+1
P1 2.239384 /dev/fuse -> read wcfs/11398_6_r: # woken read that was queued before "..."
.57 READ i5 ... (ret=80)
P0 2.239626 /dev/fuse <- write wcfs/11397_0_w:
NOTIFY_RETRIEVE ...
syscall.Syscall+48
syscall.Write+73
github.com/hanwen/go-fuse/fuse.(*Server).systemWrite.func1+76github.com/hanwen/go-fuse/fuse.handleEINTR+39github.com/hanwen/go-fuse/fuse.(*Server).systemWrite+931github.com/hanwen/go-fuse/fuse.(*Server).write+194github.com/hanwen/go-fuse/fuse.(*Server).InodeRetrieveCache+764github.com/hanwen/go-fuse/fuse/nodefs.(*FileSystemConnector).FileRetrieveCa…
main.(*BigFile).invalidateBlk+232
main.(*Root).zδhandle1.func1+72
golang.org/x/sync/errgroup.(*Group).Go.func1+87
runtime.goexit+1
P0 2.239660 /dev/fuse -> write_ack wcfs/11397_0_w (ret=48)
# stuck
# (full trace: https://lab.nexedi.com/kirr/wendelin.core/commit/96416aaabd)
with queued / served read analysis confirming that two reads were indeed queued
and not served:
grep -w -e '<- qread\>' y.log |awk {'print $6'} |sort >qread.txt
grep -w -e '-> read\>' y.log |awk {'print $6'} |sort >read.txt
# xdiff qread.txt read.txt
diff --git a/qread.txt b/read.txt
index 4ab50d7..fdd2be1 100644
--- a/qread.txt
+++ b/read.txt
@@ -53,7 +53,5 @@ wcfs/11399_1_r:
wcfs/11399_2_r:
wcfs/11399_3_r:
wcfs/11399_4_r:
-wcfs/11399_5_r:
wcfs/11400_0_r:
wcfs/11401_0_r:
-wcfs/11401_1_r:
The bug was hit because go-fuse by default uses 64K for read buffer size
https://github.com/hanwen/go-fuse/blob/33711add/fuse/server.go#L142
and the kernel presets fuse_conn->max_pages to be 128K (= 32·4K pages).
Go-fuse will be likely fixed to both use bufsize=kernel's and to
correctly handle size > bufsize in InodeRetrieveCache. However we should
also fix the kernel to always deliver NOTIFY_REPLY once NOTIFY_RETRIEVE
was successful, so that FUSE protocol guarantee always holds
irregardless of whether userspace used default or other valid buffer
size setting, and so that filesystems can count not to get stuck waiting
for kernel who promised a reply.
This way this patch is here.
Signed-off-by: Kirill Smelkov <kirr(a)nexedi.com>
Cc: Han-Wen Nienhuys <hanwen(a)google.com>
Cc: Jakob Unterwurzacher <jakobunt(a)gmail.com>
Cc: <stable(a)vger.kernel.org> # v2.6.36+
---
( This is my first patch to fs/fuse, so please forgive me if I missed anything. )
fs/fuse/dev.c | 70 ++++++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 64 insertions(+), 6 deletions(-)
diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
index 8a63e52785e9..59bb97f2f491 100644
--- a/fs/fuse/dev.c
+++ b/fs/fuse/dev.c
@@ -381,6 +381,40 @@ static void queue_request(struct fuse_iqueue *fiq, struct fuse_req *req)
kill_fasync(&fiq->fasync, SIGIO, POLL_IN);
}
+/*
+ * fuse_req_truncate_data truncates data in request that has paged data
+ * (req.in.argpages=1), so that whole request, when serialized, is <= nbytes.
+ *
+ * nbytes must be >= size(request without data).
+ */
+static void fuse_req_truncate_data(struct fuse_req *req, unsigned nbytes) {
+ unsigned size, n;
+
+ BUG_ON(!req->in.argpages);
+ BUG_ON(req->in.numargs < 1);
+
+ /* request size without data */
+ size = sizeof(struct fuse_in_header) +
+ len_args(req->in.numargs - 1, (struct fuse_arg *) req->in.args);
+ BUG_ON(nbytes < size);
+
+ /* truncate paged data */
+ for (n = 0; n < req->num_pages; n++) {
+ struct fuse_page_desc *p = &req->page_descs[n];
+
+ if (size >= nbytes) {
+ p->length = 0;
+ } else {
+ p->length = min_t(unsigned, p->length, nbytes - size);
+ }
+
+ size += p->length;
+ }
+
+ /* update whole request length in the header */
+ req->in.h.len = size;
+}
+
void fuse_queue_forget(struct fuse_conn *fc, struct fuse_forget_link *forget,
u64 nodeid, u64 nlookup)
{
@@ -1317,6 +1351,15 @@ static ssize_t fuse_dev_do_read(struct fuse_dev *fud, struct file *file,
unsigned reqsize;
unsigned int hash;
+ /*
+ * Require sane minimum read buffer - that has capacity for fixed part
+ * of any request + some room for data. If the requirement is not
+ * satisfied return EINVAL to the filesystem without dequeueing /
+ * aborting any request.
+ */
+ if (nbytes < FUSE_MIN_READ_BUFFER)
+ return -EINVAL;
+
restart:
spin_lock(&fiq->waitq.lock);
err = -EAGAIN;
@@ -1358,12 +1401,27 @@ static ssize_t fuse_dev_do_read(struct fuse_dev *fud, struct file *file,
/* If request is too large, reply with an error and restart the read */
if (nbytes < reqsize) {
- req->out.h.error = -EIO;
- /* SETXATTR is special, since it may contain too large data */
- if (in->h.opcode == FUSE_SETXATTR)
- req->out.h.error = -E2BIG;
- request_end(fc, req);
- goto restart;
+ switch (in->h.opcode) {
+ default:
+ req->out.h.error = -EIO;
+ /* SETXATTR is special, since it may contain too large data */
+ if (in->h.opcode == FUSE_SETXATTR)
+ req->out.h.error = -E2BIG;
+ request_end(fc, req);
+ goto restart;
+
+ /*
+ * NOTIFY_REPLY is special: if it was queued we already
+ * promised to filesystem to deliver it when handling
+ * NOTIFY_RETRIVE. We know that read buffer has capacity for at
+ * least some data. Truncate retrieved data to read buffer size
+ * and deliver it to stay to the promise.
+ */
+ case FUSE_NOTIFY_REPLY:
+ fuse_req_truncate_data(req, nbytes);
+ reqsize = in->h.len;
+ }
+
}
spin_lock(&fpq->lock);
list_add(&req->list, &fpq->io);
--
2.21.0.rc0.269.g1a574e7a28
Just in case it hasn't been reported yet:
drivers/tty/serial/samsung.c: In function 's3c24xx_serial_set_termios':
drivers/tty/serial/samsung.c:820:19: error: 'UPSTAT_AUTOCTS' undeclared
Guenter
Current overlap check of minor range cannot correctly
handle a case which is baseminor < existing baseminor &&
baseminor + minorct > existing baseminor + minorct.
Fix it and meanwhile do some code cleanups.
Fixes: 01d553d0fe9f90 ("Chardev checking of overlapping ranges")
Signed-off-by: Chengguang Xu <cgxu519(a)gmx.com>
Cc: stable(a)vger.kernel.org
---
fs/char_dev.c | 94 ++++++++++++++++++++++++---------------------------
1 file changed, 44 insertions(+), 50 deletions(-)
diff --git a/fs/char_dev.c b/fs/char_dev.c
index a279c58fe360..b25b1da097d5 100644
--- a/fs/char_dev.c
+++ b/fs/char_dev.c
@@ -88,86 +88,80 @@ static int find_dynamic_major(void)
/*
* Register a single major with a specified minor range.
*
- * If major == 0 this functions will dynamically allocate a major and return
- * its number.
- *
- * If major > 0 this function will attempt to reserve the passed range of
- * minors and will return zero on success.
+ * If major == 0 this function will dynamically allocate an unused major,
+ * otherwise attempt to reserve the range of minors with given major.
*
- * Returns a -ve errno on failure.
*/
static struct char_device_struct *
__register_chrdev_region(unsigned int major, unsigned int baseminor,
int minorct, const char *name)
{
- struct char_device_struct *cd, **cp;
- int ret = 0;
+ struct char_device_struct *new, *curr, *prev = NULL;
+ int ret = -EBUSY;
int i;
- cd = kzalloc(sizeof(struct char_device_struct), GFP_KERNEL);
- if (cd == NULL)
+ if (major >= CHRDEV_MAJOR_MAX) {
+ pr_err("CHRDEV \"%s\" major requested (%u) is greater than the maximum (%u)\n",
+ name, major, CHRDEV_MAJOR_MAX-1);
+ return ERR_PTR(-EINVAL);
+ }
+
+ if (minorct > MINORMASK + 1 - baseminor) {
+ pr_err("CHRDEV \"%s\" minor range requested (%u-%u) is out of range of maximum range (%u-%u) for a single major\n",
+ name, baseminor, baseminor + minorct - 1, 0, MINORMASK);
+ return ERR_PTR(-EINVAL);
+ }
+
+ new = kzalloc(sizeof(struct char_device_struct), GFP_KERNEL);
+ if (new == NULL)
return ERR_PTR(-ENOMEM);
mutex_lock(&chrdevs_lock);
if (major == 0) {
- ret = find_dynamic_major();
- if (ret < 0) {
+ major = find_dynamic_major();
+ if (major < 0) {
pr_err("CHRDEV \"%s\" dynamic allocation region is full\n",
name);
goto out;
}
- major = ret;
}
- if (major >= CHRDEV_MAJOR_MAX) {
- pr_err("CHRDEV \"%s\" major requested (%u) is greater than the maximum (%u)\n",
- name, major, CHRDEV_MAJOR_MAX-1);
- ret = -EINVAL;
- goto out;
- }
-
- cd->major = major;
- cd->baseminor = baseminor;
- cd->minorct = minorct;
- strlcpy(cd->name, name, sizeof(cd->name));
-
i = major_to_index(major);
+ for (curr = chrdevs[i]; curr; prev = curr, curr = curr->next) {
+ if (curr->major < major)
+ continue;
- for (cp = &chrdevs[i]; *cp; cp = &(*cp)->next)
- if ((*cp)->major > major ||
- ((*cp)->major == major &&
- (((*cp)->baseminor >= baseminor) ||
- ((*cp)->baseminor + (*cp)->minorct > baseminor))))
+ if (curr->major > major)
break;
- /* Check for overlapping minor ranges. */
- if (*cp && (*cp)->major == major) {
- int old_min = (*cp)->baseminor;
- int old_max = (*cp)->baseminor + (*cp)->minorct - 1;
- int new_min = baseminor;
- int new_max = baseminor + minorct - 1;
+ if (curr->baseminor + curr->minorct <= baseminor)
+ continue;
- /* New driver overlaps from the left. */
- if (new_max >= old_min && new_max <= old_max) {
- ret = -EBUSY;
- goto out;
- }
+ if (curr->baseminor >= baseminor + minorct)
+ break;
- /* New driver overlaps from the right. */
- if (new_min <= old_max && new_min >= old_min) {
- ret = -EBUSY;
- goto out;
- }
+ goto out;
+ }
+
+ new->major = major;
+ new->baseminor = baseminor;
+ new->minorct = minorct;
+ strlcpy(new->name, name, sizeof(new->name));
+
+ if (!prev) {
+ new->next = curr;
+ chrdevs[i] = new;
+ } else {
+ new->next = prev->next;
+ prev->next = new;
}
- cd->next = *cp;
- *cp = cd;
mutex_unlock(&chrdevs_lock);
- return cd;
+ return new;
out:
mutex_unlock(&chrdevs_lock);
- kfree(cd);
+ kfree(new);
return ERR_PTR(ret);
}
--
2.20.1
Thomas,
Andi and I have made an update to our draft of the Spectre admin guide.
We may be out on Christmas vacation for a while. But we want to
send it out for everyone to take a look.
Thanks.
Tim
From: Andi Kleen <ak(a)linux.intel.com>
There are no document in admin guides describing
Spectre v1 and v2 side channels and their mitigations
in Linux.
Create a document to describe Spectre and the mitigation
methods used in the kernel.
Signed-off-by: Andi Kleen <ak(a)linux.intel.com>
Signed-off-by: Tim Chen <tim.c.chen(a)linux.intel.com>
---
Documentation/admin-guide/spectre.rst | 502 ++++++++++++++++++++++++++++++++++
1 file changed, 502 insertions(+)
create mode 100644 Documentation/admin-guide/spectre.rst
diff --git a/Documentation/admin-guide/spectre.rst b/Documentation/admin-guide/spectre.rst
new file mode 100644
index 0000000..0ba708e
--- /dev/null
+++ b/Documentation/admin-guide/spectre.rst
@@ -0,0 +1,502 @@
+Spectre side channels
+=====================
+
+Spectre is a class of side channel attacks against modern CPUs that
+exploit branch prediction and speculative execution to read memory,
+possibly bypassing access controls. These exploits do not modify memory.
+
+This document covers Spectre variant 1 and 2.
+
+Affected processors
+-------------------
+
+The vulnerability affects a wide range of modern high performance
+processors, since most modern high speed processors use branch prediction
+and speculative execution.
+
+The following CPUs are vulnerable:
+
+ - Intel Core, Atom, Pentium, Xeon CPUs
+ - AMD CPUs like Phenom, EPYC, Zen.
+ - IBM processors like POWER and zSeries
+ - Higher end ARM processors
+ - Apple CPUs
+ - Higher end MIPS CPUs
+ - Likely most other high performance CPUs. Contact your CPU vendor for details.
+
+This document describes the mitigations on Intel CPUs. Mitigations
+on other architectures may be different.
+
+Related CVEs
+------------
+
+The following CVE entries describe Spectre variants:
+
+ ============= ======================= ==========
+ CVE-2017-5753 Bounds check bypass Spectre-V1
+ CVE-2017-5715 Branch target injection Spectre-V2
+
+Problem
+-------
+
+CPUs have shared caches, such as buffers for branch prediction, which are
+later used to guide speculative execution. These buffers are not flushed
+over context switches or change in privilege levels. Malicious software
+might influence these buffers and trigger specific speculative execution
+in the kernel or different user processes. This speculative execution can
+then be used to read data in memory and cause side effects, such as displacing
+data in a data cache. The side effect can then later be measured by the
+malicious software, and used to determine the memory values read speculatively.
+
+Spectre attacks allow tricking other software to disclose
+values in their memory.
+
+In a typical Spectre variant 1 attack, the attacker passes an parameter
+to a victim. The victim boundary checks the parameter and rejects illegal
+values. However due to speculation over branch prediction the code path
+for correct values might be speculatively executed, then reference memory
+controlled by the input parameter and leave measurable side effects in
+the caches. The attacker could then measure these side effects
+and determine the leaked value.
+
+There are some extensions of Spectre variant 1 attacks for reading
+data over the network, see [2]. However the attacks are very
+difficult, low bandwidth and fragile and considered low risk.
+
+For Spectre variant 2 the attacker poisons the indirect branch
+predictors of the CPU. Then control is passed to the victim, which
+executes indirect branches. Due to the poisoned branch predictor data
+the CPU can speculatively execute arbitrary code in the victim's
+address space, such as a code sequence ("disclosure gadget") that
+reads arbitrary data on some input parameter and causes a measurable
+cache side effect based on the value. The attacker can then measure
+this side effect after gaining control again and determine the value.
+
+The most useful gadgets take an attacker-controlled input parameter so
+that the memory read can be controlled. Gadgets without input parameters
+might be possible, but the attacker would have very little control over what
+memory can be read, reducing the risk of the attack revealing useful data.
+
+Attack scenarios
+----------------
+
+Here is a list of attack scenarios that have been anticipated, but
+may not cover all possible attack patterns. Reduing the occurrences of
+attack pre-requisites listed can reduce the risk that a spectre attack
+leaks useful data.
+
+1. Local User process attacking kernel
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Code in system calls often enforces access controls with conditional
+branches based on user data. These branches are potential targets for
+Spectre v2 exploits. Interrupt handlers, on the other hand, rarely
+handle user data or enforce access controls, which makes them unlikely
+exploit targets.
+
+For typical variant 2 attack, the attacker may poison the CPU branch
+buffers first, and then enter the kernel and trick it into jumping to a
+disclosure gadget through an indirect branch. If the attacker wants to control the
+memory addresses leaked, it would also need to pass a parameter
+to the gadget, either through a register or through a known address in
+memory. Finally when it executes again it can measure the side effect.
+
+Necessary Prequisites:
+1. Malicious local process passing parameters to kernel
+2. Kernel has secrets.
+
+2. User process attacking another user process
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+In this scenario an malicious user process wants to attack another
+user process through a context switch.
+
+For variant 1 this generally requires passing some parameter between
+the processes, which needs a data passing relationship, such a remote
+procedure calls (RPC).
+
+For variant 2 the poisoning can happen through a context switch, or
+on CPUs with simultaneous multi-threading (SMT) potentially on the
+thread sibling executing in parallel on the same core. In either case,
+controlling the memory leaked by the disclosure gadget also requires a data
+passing relationship to the victim process, otherwise while it may
+observe values through side effects, it won't know which memory
+addresses they relate to.
+
+Necessary Prerequisites:
+1. Malicious code running as local process
+2. Victim processes containing secrets running on same core.
+
+3. User sandbox attacking runtime in process
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+A process, such as a web browser, might be running interpreted or JITed
+untrusted code, such as javascript code downloaded from a website.
+It uses restrictions in the JIT code generator and checks in a run time
+to prevent the untrusted code from attacking the hosting process.
+
+The untrusted code might either use variant 1 or 2 to trick
+a disclosure gadget in the run time to read memory inside the process.
+
+Necessary Prerequisites:
+1. Sandbox in process running untrusted code.
+2. Runtime in same process containing secrets.
+
+4. Kernel sandbox attacking kernel
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The kernel has support for running user-supplied programs within the
+kernel. Specific rules (such as bounds checking) are enforced on these
+programs by the kernel to ensure that they do not violate access controls.
+
+eBPF is a kernel sub-system that uses user-supplied program
+to execute JITed untrusted byte code inside the kernel. eBPF is used
+for manipulating and examining network packets, examining system call
+parameters for sand boxes and other uses.
+
+A malicious local process could upload and trigger an malicious
+eBPF script to the kernel, with the script attacking the kernel
+using variant 1 or 2 and reading memory.
+
+Necessary Prerequisites:
+1. Malicious local process
+2. eBPF JIT enabled for unprivileged users, attacking kernel with secrets
+on the same machine.
+
+5. Virtualization guest attacking host
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+An untrusted guest might attack the host through a hyper call
+or other virtualization exit.
+
+Necessary Prerequisites:
+1. Untrusted guest attacking host
+2. Host has secrets on local machine.
+
+For variant 1 VM exits use appropriate mitigations
+("bounds clipping") to prevent speculation leaking data
+in kernel code. For variant 2 the kernel flushes the branch buffer.
+
+6. Virtualization guest attacking other guest
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+An untrusted guest attacking another guest containing
+secrets. Mitigations are similar to when a guest attack
+the host.
+
+Runtime vulnerability information
+---------------------------------
+
+The kernel reports the vulnerability and mitigation status in
+/sys/devices/system/cpu/vulnerabilities/*
+
+The spectre_v1 file describes the always enabled variant 1
+mitigation:
+
+/sys/devices/system/cpu/vulnerabilities/spectre_v1
+
+The value in this file:
+
+ ======================================= =================================
+ 'Mitigation: __user pointer sanitation' Protection in kernel on a case by
+ case base with explicit pointer
+ sanitation.
+ ======================================= =================================
+
+The spectre_v2 kernel file reports if the kernel has been compiled with a
+retpoline aware compiler, if the CPU has hardware mitigation, and if the
+CPU has microcode support for additional process specific mitigations.
+
+It also reports CPU features enabled by microcode to mitigate attack
+between user processes:
+
+1. Indirect Branch Prediction Barrier (IBPB) to add additional
+ isolation between processes of different users
+2. Single Thread Indirect Branch Prediction (STIBP) to additional
+ isolation between CPU threads running on the same core.
+
+These CPU features may impact performance when used and can
+be enabled per process on a case-by-case base.
+
+/sys/devices/system/cpu/vulnerabilities/spectre_v2
+
+The values in this file:
+
+ - Kernel status:
+
+ ==================================== =================================
+ 'Not affected' The processor is not vulnerable
+ 'Vulnerable' Vulnerable, no mitigation
+ 'Mitigation: Full generic retpoline' Software-focused mitigation
+ 'Mitigation: Full AMD retpoline' AMD-specific software mitigation
+ 'Mitigation: Enhanced IBRS' Hardware-focused mitigation
+ ==================================== =================================
+
+ - Firmware status:
+
+ ========== =============================================================
+ 'IBRS_FW' Protection against user program attacks when calling firmware
+ ========== =============================================================
+
+ - Indirect branch prediction barrier (IBPB) status for protection between
+ processes of different users. This feature can be controlled through
+ prctl per process, or through kernel command line options. For more details
+ see below.
+
+ =================== ========================================================
+ 'IBPB: disabled' IBPB unused
+ 'IBPB: always-on' Use IBPB on all tasks
+ 'IBPB: conditional' Use IBPB on SECCOMP or indirect branch restricted tasks
+ =================== ========================================================
+
+ - Single threaded indirect branch prediction (STIBP) status for protection
+ between different hyper threads. This feature can be controlled through
+ prctl per process, or through kernel command line options. For more details
+ see below.
+
+ ==================== ========================================================
+ 'STIBP: disabled' STIBP unused
+ 'STIBP: forced' Use STIBP on all tasks
+ 'STIBP: conditional' Use STIBP on SECCOMP or indirect branch restricted tasks
+ ==================== ========================================================
+
+ - Return stack buffer (RSB) protection status:
+
+ ============= ===========================================
+ 'RSB filling' Protection of RSB on context switch enabled
+ ============= ===========================================
+
+Full mitigations might require an microcode update from the CPU
+vendor. When the necessary microcode is not available the kernel
+will report vulnerability.
+
+Kernel mitigation
+-----------------
+
+The kernel has default on mitigations for Variant 1 and Variant 2
+against attacks from user programs or guests. For variant 1 it
+annotates vulnerable kernel code (as determined by the sparse code
+scanning tool and code audits) to use "bounds clipping" to avoid any
+usable disclosure gadgets.
+
+For variant 2 the kernel employs "retpoline" with compiler help to secure
+the indirect branches inside the kernel, when CONFIG_RETPOLINE is enabled
+and the compiler supports retpoline. On Intel Skylake-era systems the
+mitigation covers most, but not all, cases, see [1] for more details.
+
+On CPUs with hardware mitigations for variant 2, retpoline is
+automatically disabled at runtime.
+
+Using kernel address space randomization (CONFIG_RANDOMIZE_SLAB=y
+and CONFIG_SLAB_FREELIST_RANDOM=y in the kernel configuration)
+makes attacks on the kernel generally more difficult.
+
+Host mitigation
+---------------
+
+The Linux kernel uses retpoline to eliminate attacks on indirect
+branches. It also flushes the Return Branch Stack on every VM exit to
+prevent guests from attacking the host kernel when retpoline is
+enabled.
+
+Variant 1 attacks are mitigated unconditionally.
+
+The kernel also allows guests to use any microcode based mitigations
+they chose to use (such as IBPB or STIBP), assuming the
+host has an updated microcode and reports the feature in
+/sys/devices/system/cpu/vulnerabilities/spectre_v2.
+
+Mitigation control at kernel build time
+---------------------------------------
+
+When the CONFIG_RETPOLINE option is enabled the kernel uses special
+code sequences to avoid attacks on indirect branches through
+Variant 2 attacks.
+
+The compiler also needs to support retpoline and support the
+-mindirect-branch=thunk-extern -mindirect-branch-register options
+for gcc, or -mretpoline-external-thunk option for clang.
+
+When the compiler doesn't support these options the kernel
+will report that it is vulnerable.
+
+Variant 1 mitigations and other side channel related user APIs are
+enabled unconditionally.
+
+Hardware mitigation
+-------------------
+
+Some CPUs have hardware mitigations (e.g. enhanced IBRS) for Spectre
+variant 2. The 4.19 kernel has support for detecting this capability
+and automatically disable any unnecessary workarounds at runtime.
+
+User program mitigation
+-----------------------
+
+For variant 1 user programs can use LFENCE or bounds clipping. For more
+details see [3].
+
+For variant 2 user programs can be compiled with retpoline or
+restricting its indirect branch speculation via prctl. (See
+Documenation/speculation.txt for detailed API.)
+
+User programs should use address space randomization
+(/proc/sys/kernel/randomize_va_space = 1 or 2) to make any attacks
+more difficult.
+
+Mitigation control on the kernel command line
+---------------------------------------------
+
+Spectre v2 mitigations can be disabled and force enabled at the kernel
+command line.
+
+ nospectre_v2 [X86] 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.
+
+
+ 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.
+
+For user space mitigation:
+
+ 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.
+
+ In general the kernel by default selects
+ reasonable mitigations for the current CPU. To
+ disable Spectre v2 mitigations boot with
+ spectre_v2=off. Spectre v1 mitigations cannot
+ be disabled.
+
+APIs for mitigation control of user process
+-------------------------------------------
+
+When enabling the "prctl" option for spectre_v2_user boot parameter,
+prctl can be used to restrict indirect branch speculation on a process.
+See Documenation/speculation.txt for detailed API.
+
+Processes containing secrets, such as cryptographic keys, may invoke
+this prctl for extra protection against Spectre v2.
+
+Before running untrusted processes, restricting their indirect branch
+speculation will prevent such processes from launching Spectre v2 attacks.
+
+Restricting indirect branch speuclation on a process should be only used
+as needed, as restricting speculation reduces both performance of the
+process, and also process running on the sibling CPU thread.
+
+Under the "seccomp" option, the processes sandboxed with SECCOMP will
+have indirect branch speculation restricted automatically.
+
+References
+----------
+
+Intel white papers and documents on Spectre:
+
+https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-of-Speculative-Execution-Side-Channels.pdf
+
+[1]
+https://software.intel.com/security-software-guidance/api-app/sites/default/files/Retpoline-A-Branch-Target-Injection-Mitigation.pdf
+
+https://www.intel.com/content/www/us/en/architecture-and-technology/facts-about-side-channel-analysis-and-intel-products.html
+
+[3] https://software.intel.com/security-software-guidance/
+
+https://software.intel.com/security-software-guidance/insights/deep-dive-single-thread-indirect-branch-predictors
+
+AMD white papers:
+
+https://developer.amd.com/wp-content/resources/90343-B_SoftwareTechniquesforManagingSpeculation_WP_7-18Update_FNL.pdf
+
+https://www.amd.com/en/corporate/security-updates
+
+ARM white papers:
+
+https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/download-the-whitepaper
+
+https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/latest-updates/cache-speculation-issues-update
+
+MIPS:
+
+https://www.mips.com/blog/mips-response-on-speculative-execution-and-side-channel-vulnerabilities/
+
+Academic papers:
+
+https://spectreattack.com/spectre.pdf [original spectre paper]
+
+[2] https://arxiv.org/abs/1807.10535 [NetSpectre]
+
+https://arxiv.org/abs/1811.05441 [generalization of Spectre]
+
+https://arxiv.org/abs/1807.07940 [Spectre RSB, a variant of Spectre v2]
--
2.9.4
On 2019/2/12 9:28 下午, Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
>
> The bot has tested the following trees: v4.20.7, v4.19.20, v4.14.98, v4.9.155, v4.4.173, v3.18.134.
>
> v4.20.7: Build OK!
> v4.19.20: Failed to apply! Possible dependencies:
> 752f66a75aba ("bcache: use REQ_PRIO to indicate bio for metadata")
>
> v4.14.98: Failed to apply! Possible dependencies:
> 752f66a75aba ("bcache: use REQ_PRIO to indicate bio for metadata")
> b41c9b0266e8 ("bcache: update bio->bi_opf bypass/writeback REQ_ flag hints")
>
> v4.9.155: Failed to apply! Possible dependencies:
> 752f66a75aba ("bcache: use REQ_PRIO to indicate bio for metadata")
> 83b5df67c509 ("bcache: use op_is_sync to check for synchronous requests")
> b41c9b0266e8 ("bcache: update bio->bi_opf bypass/writeback REQ_ flag hints")
>
> v4.4.173: Failed to apply! Possible dependencies:
> 09cbfeaf1a5a ("mm, fs: get rid of PAGE_CACHE_* and page_cache_{get,release} macros")
> 1c2e54e1ed6f ("dm thin: bump thin and thin-pool target versions")
> 1eff9d322a44 ("block: rename bio bi_rw to bi_opf")
> 202bae52934d ("dm thin: unroll issue_discard() to create longer discard bio chains")
> 38f252553300 ("block: add __blkdev_issue_discard")
> 3dba53a958a7 ("dm thin: use __blkdev_issue_discard for async discard support")
> 4e49ea4a3d27 ("block/fs/drivers: remove rw argument from submit_bio")
> 83b5df67c509 ("bcache: use op_is_sync to check for synchronous requests")
> 9082e87bfbf8 ("block: remove struct bio_batch")
> a6111d11b8b5 ("btrfs: raid56: Use raid_write_end_io for scrub")
> b41c9b0266e8 ("bcache: update bio->bi_opf bypass/writeback REQ_ flag hints")
> bbd848e0fade ("block: reinstate early return of -EOPNOTSUPP from blkdev_issue_discard")
> c3667cc61904 ("dm thin: consistently return -ENOSPC if pool has run out of data space")
> c8d93247f1d0 ("bcache: use op_is_write instead of checking for REQ_WRITE")
> d57d611505d9 ("kernel/fs: fix I/O wait not accounted for RW O_DSYNC")
>
> v3.18.134: Failed to apply! Possible dependencies:
> 1b94b5567e9c ("Btrfs, raid56: use a variant to record the operation type")
> 1eff9d322a44 ("block: rename bio bi_rw to bi_opf")
> 2c8cdd6ee4e7 ("Btrfs, replace: write dirty pages into the replace target device")
> 326e1dbb5736 ("block: remove management of bi_remaining when restoring original bi_end_io")
> 4245215d6a8d ("Btrfs, raid56: fix use-after-free problem in the final device replace procedure on raid56")
> 5a6ac9eacb49 ("Btrfs, raid56: support parity scrub on raid56")
> 6e9606d2a2dc ("Btrfs: add ref_count and free function for btrfs_bio")
> 83b5df67c509 ("bcache: use op_is_sync to check for synchronous requests")
> 8e5cfb55d3f7 ("Btrfs: Make raid_map array be inlined in btrfs_bio structure")
> af8e2d1df984 ("Btrfs, scrub: repair the common data on RAID5/6 if it is corrupted")
> b41c9b0266e8 ("bcache: update bio->bi_opf bypass/writeback REQ_ flag hints")
> b7c44ed9d2fc ("block: manipulate bio->bi_flags through helpers")
> b89e1b012c7f ("Btrfs, raid56: don't change bbio and raid_map")
> c4cf5261f8bf ("bio: skip atomic inc/dec of ->bi_remaining for non-chains")
> c8d93247f1d0 ("bcache: use op_is_write instead of checking for REQ_WRITE")
> f90523d1aa3c ("Btrfs: remove noused bbio_ret in __btrfs_map_block in condition")
>
>
> How should we proceed with this patch?
Can I rebase this patch for each stable kernel, and send the patch to
stable(a)vger.kernel.org ?
Thanks.
--
Coly Li
On 2019/2/12 9:28 下午, Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
>
> The bot has tested the following trees: v4.20.7, v4.19.20, v4.14.98, v4.9.155, v4.4.173, v3.18.134.
>
> v4.20.7: Build OK!
> v4.19.20: Failed to apply! Possible dependencies:
> 149d0efada77 ("bcache: replace hard coded number with BUCKET_GC_GEN_MAX")
>
> v4.14.98: Failed to apply! Possible dependencies:
> 1d316e658374 ("bcache: implement PI controller for writeback rate")
> 25d8be77e192 ("block: move bio_alloc_pages() to bcache")
> 27a40ab9269e ("bcache: add backing_request_endio() for bi_end_io")
> 2831231d4c3f ("bcache: reduce cache_set devices iteration by devices_max_used")
> 3b304d24a718 ("bcache: convert cached_dev.count from atomic_t to refcount_t")
> 3fd47bfe55b0 ("bcache: stop dc->writeback_rate_update properly")
> 5138ac6748e3 ("bcache: fix misleading error message in bch_count_io_errors()")
> 539d39eb2708 ("bcache: fix wrong return value in bch_debug_init()")
> 5fa89fb9a86b ("bcache: don't write back data if reading it failed")
> 6f10f7d1b02b ("bcache: style fix to replace 'unsigned' by 'unsigned int'")
> 771f393e8ffc ("bcache: add CACHE_SET_IO_DISABLE to struct cache_set flags")
> 7ba0d830dc0e ("bcache: set error_limit correctly")
> 7e027ca4b534 ("bcache: add stop_when_cache_set_failed option to backing device")
> 804f3c6981f5 ("bcache: fix cached_dev->count usage for bch_cache_set_error()")
> a8500fc816b1 ("bcache: rearrange writeback main thread ratelimit")
> b1092c9af9ed ("bcache: allow quick writeback when backing idle")
> bc082a55d25c ("bcache: fix inaccurate io state for detached bcache devices")
> c7b7bd07404c ("bcache: add io_disable to struct cached_dev")
>
> v4.9.155: Failed to apply! Possible dependencies:
> 1d316e658374 ("bcache: implement PI controller for writeback rate")
> 2831231d4c3f ("bcache: reduce cache_set devices iteration by devices_max_used")
> 297e3d854784 ("blk-throttle: make throtl_slice tunable")
> 3fd47bfe55b0 ("bcache: stop dc->writeback_rate_update properly")
> 4e4cbee93d56 ("block: switch bios to blk_status_t")
> 5138ac6748e3 ("bcache: fix misleading error message in bch_count_io_errors()")
> 6f10f7d1b02b ("bcache: style fix to replace 'unsigned' by 'unsigned int'")
> 7e027ca4b534 ("bcache: add stop_when_cache_set_failed option to backing device")
> 87760e5eef35 ("block: hook up writeback throttling")
> 9e234eeafbe1 ("blk-throttle: add a simple idle detection")
> c7b7bd07404c ("bcache: add io_disable to struct cached_dev")
> cf43e6be865a ("block: add scalable completion tracking of requests")
> e806402130c9 ("block: split out request-only flags into a new namespace")
> fbbaf700e7b1 ("block: trace completion of all bios.")
>
> v4.4.173: Failed to apply! Possible dependencies:
> 005411ea7ee7 ("doc: update block/queue-sysfs.txt entries")
> 1d316e658374 ("bcache: implement PI controller for writeback rate")
> 27489a3c827b ("blk-mq: turn hctx->run_work into a regular work struct")
> 2831231d4c3f ("bcache: reduce cache_set devices iteration by devices_max_used")
> 297e3d854784 ("blk-throttle: make throtl_slice tunable")
> 38f8baae8905 ("block: factor out chained bio completion")
> 3fd47bfe55b0 ("bcache: stop dc->writeback_rate_update properly")
> 4e4cbee93d56 ("block: switch bios to blk_status_t")
> 511cbce2ff8b ("irq_poll: make blk-iopoll available outside the block layer")
> 5138ac6748e3 ("bcache: fix misleading error message in bch_count_io_errors()")
> 6f10f7d1b02b ("bcache: style fix to replace 'unsigned' by 'unsigned int'")
> 7e027ca4b534 ("bcache: add stop_when_cache_set_failed option to backing device")
> 87760e5eef35 ("block: hook up writeback throttling")
> 8d354f133e86 ("blk-mq: improve layout of blk_mq_hw_ctx")
> 9467f85960a3 ("blk-mq/cpu-notif: Convert to new hotplug state machine")
> 9e234eeafbe1 ("blk-throttle: add a simple idle detection")
> af3e3a5259e3 ("block: don't unecessarily clobber bi_error for chained bios")
> ba8c6967b739 ("block: cleanup bio_endio")
> c7b7bd07404c ("bcache: add io_disable to struct cached_dev")
> cf43e6be865a ("block: add scalable completion tracking of requests")
> e57690fe009b ("blk-mq: don't overwrite rq->mq_ctx")
> fbbaf700e7b1 ("block: trace completion of all bios.")
>
> v3.18.134: Failed to apply! Possible dependencies:
> 0f8087ecdeac ("block: Consolidate static integrity profile properties")
> 1b94b5567e9c ("Btrfs, raid56: use a variant to record the operation type")
> 1d316e658374 ("bcache: implement PI controller for writeback rate")
> 2831231d4c3f ("bcache: reduce cache_set devices iteration by devices_max_used")
> 2c8cdd6ee4e7 ("Btrfs, replace: write dirty pages into the replace target device")
> 326e1dbb5736 ("block: remove management of bi_remaining when restoring original bi_end_io")
> 3fd47bfe55b0 ("bcache: stop dc->writeback_rate_update properly")
> 4246a0b63bd8 ("block: add a bi_error field to struct bio")
> 4e4cbee93d56 ("block: switch bios to blk_status_t")
> 5138ac6748e3 ("bcache: fix misleading error message in bch_count_io_errors()")
> 5a6ac9eacb49 ("Btrfs, raid56: support parity scrub on raid56")
> 6e9606d2a2dc ("Btrfs: add ref_count and free function for btrfs_bio")
> 6f10f7d1b02b ("bcache: style fix to replace 'unsigned' by 'unsigned int'")
> 7e027ca4b534 ("bcache: add stop_when_cache_set_failed option to backing device")
> 8e5cfb55d3f7 ("Btrfs: Make raid_map array be inlined in btrfs_bio structure")
> af8e2d1df984 ("Btrfs, scrub: repair the common data on RAID5/6 if it is corrupted")
> b89e1b012c7f ("Btrfs, raid56: don't change bbio and raid_map")
> c4cf5261f8bf ("bio: skip atomic inc/dec of ->bi_remaining for non-chains")
> c7b7bd07404c ("bcache: add io_disable to struct cached_dev")
> f90523d1aa3c ("Btrfs: remove noused bbio_ret in __btrfs_map_block in condition")
>
>
> How should we proceed with this patch?
Can we rebase this patch for stable kernels, and send them to stable
kernel maintainers separately? If this behavior is accepted for stable
kernel maintenance, I would suggest Junhui Tang to think about to rebase
for these stable kernels.
Thanks.
--
Coly Li
The patch
regulator: s2mps11: Fix steps for buck7, buck8 and LDO35
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 56b5d4ea778c1b0989c5cdb5406d4a488144c416 Mon Sep 17 00:00:00 2001
From: Krzysztof Kozlowski <krzk(a)kernel.org>
Date: Sat, 9 Feb 2019 18:14:14 +0100
Subject: [PATCH] regulator: s2mps11: Fix steps for buck7, buck8 and LDO35
LDO35 uses 25 mV step, not 50 mV. Bucks 7 and 8 use 12.5 mV step
instead of 6.25 mV. Wrong step caused over-voltage (LDO35) or
under-voltage (buck7 and 8) if regulators were used (e.g. on Exynos5420
Arndale Octa board).
Cc: <stable(a)vger.kernel.org>
Fixes: cb74685ecb39 ("regulator: s2mps11: Add samsung s2mps11 regulator driver")
Signed-off-by: Krzysztof Kozlowski <krzk(a)kernel.org>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
---
drivers/regulator/s2mps11.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index ee4a23ab0663..134c62db36c5 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -362,7 +362,7 @@ static const struct regulator_desc s2mps11_regulators[] = {
regulator_desc_s2mps11_ldo(32, STEP_50_MV),
regulator_desc_s2mps11_ldo(33, STEP_50_MV),
regulator_desc_s2mps11_ldo(34, STEP_50_MV),
- regulator_desc_s2mps11_ldo(35, STEP_50_MV),
+ regulator_desc_s2mps11_ldo(35, STEP_25_MV),
regulator_desc_s2mps11_ldo(36, STEP_50_MV),
regulator_desc_s2mps11_ldo(37, STEP_50_MV),
regulator_desc_s2mps11_ldo(38, STEP_50_MV),
@@ -372,8 +372,8 @@ static const struct regulator_desc s2mps11_regulators[] = {
regulator_desc_s2mps11_buck1_4(4),
regulator_desc_s2mps11_buck5,
regulator_desc_s2mps11_buck67810(6, MIN_600_MV, STEP_6_25_MV),
- regulator_desc_s2mps11_buck67810(7, MIN_600_MV, STEP_6_25_MV),
- regulator_desc_s2mps11_buck67810(8, MIN_600_MV, STEP_6_25_MV),
+ regulator_desc_s2mps11_buck67810(7, MIN_600_MV, STEP_12_5_MV),
+ regulator_desc_s2mps11_buck67810(8, MIN_600_MV, STEP_12_5_MV),
regulator_desc_s2mps11_buck9,
regulator_desc_s2mps11_buck67810(10, MIN_750_MV, STEP_12_5_MV),
};
--
2.20.1
11.02.2019 20:26, Sasha Levin пишет:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
>
> The bot has tested the following trees: v4.20.7, v4.19.20, v4.14.98, v4.9.155, v4.4.173, v3.18.134.
>
> v4.20.7: Failed to apply! Possible dependencies:
> 0604ee4aefa2 ("i2c: tegra: Add missing kerneldoc for some fields")
> b67d4530cdad ("i2c: tegra: Fix Maximum transfer size")
> c990bbafdb11 ("i2c: tegra: Cleanup kerneldoc comments")
>
> v4.19.20: Failed to apply! Possible dependencies:
> 0604ee4aefa2 ("i2c: tegra: Add missing kerneldoc for some fields")
> b67d4530cdad ("i2c: tegra: Fix Maximum transfer size")
> c96c0f268380 ("i2c: tegra: use core to detect 'no zero length' quirk")
> c990bbafdb11 ("i2c: tegra: Cleanup kerneldoc comments")
>
> v4.14.98: Failed to apply! Possible dependencies:
> 0604ee4aefa2 ("i2c: tegra: Add missing kerneldoc for some fields")
> b67d4530cdad ("i2c: tegra: Fix Maximum transfer size")
> c5907c6b96f1 ("i2c: tegra: Add support for Tegra194")
> c96c0f268380 ("i2c: tegra: use core to detect 'no zero length' quirk")
> c990bbafdb11 ("i2c: tegra: Cleanup kerneldoc comments")
>
> v4.9.155: Failed to apply! Possible dependencies:
> 0604ee4aefa2 ("i2c: tegra: Add missing kerneldoc for some fields")
> 6bec23bff914 ("i2c: mlxcpld: add master driver for mellanox systems")
> ae3923a284cc ("i2c: busses: make i2c_adapter_quirks const")
> b67d4530cdad ("i2c: tegra: Fix Maximum transfer size")
> c02b7bf532f7 ("i2c: mux: mellanox: add driver")
> c5907c6b96f1 ("i2c: tegra: Add support for Tegra194")
> c96c0f268380 ("i2c: tegra: use core to detect 'no zero length' quirk")
> c990bbafdb11 ("i2c: tegra: Cleanup kerneldoc comments")
>
> v4.4.173: Failed to apply! Possible dependencies:
> 0194621b2253 ("IB/rdmavt: Create module framework and handle driver registration")
> 0604ee4aefa2 ("i2c: tegra: Add missing kerneldoc for some fields")
> 1f50ad2c86cd ("i2c: tegra: Add runtime power-management support")
> 21e9efd92bb5 ("i2c: tegra: disable clock before returning error")
> 497fbe24987b ("i2c: tegra: enable multi master mode for tegra210")
> 50a5ba876908 ("i2c: mux: demux-pinctrl: add driver")
> 685143a1598b ("i2c: tegra: use readl_poll_timeout after config_load reg programmed")
> 6bec23bff914 ("i2c: mlxcpld: add master driver for mellanox systems")
> 7f866986e705 ("leds: add PM8058 LEDs driver")
> 8700e3e7c485 ("Soft RoCE driver")
> 9d7cffaf99f5 ("leds: Add driver for the ISSI IS31FL32xx family of LED controllers")
> ae3923a284cc ("i2c: busses: make i2c_adapter_quirks const")
> b67d4530cdad ("i2c: tegra: Fix Maximum transfer size")
> be4fdf99fa4d ("leds: add driver for Mellanox systems LEDs")
> c02b7bf532f7 ("i2c: mux: mellanox: add driver")
> c5907c6b96f1 ("i2c: tegra: Add support for Tegra194")
> c96c0f268380 ("i2c: tegra: use core to detect 'no zero length' quirk")
> c990bbafdb11 ("i2c: tegra: Cleanup kerneldoc comments")
> f5076685b3aa ("i2c: tegra: Fix missing blank lines after declarations")
>
> v3.18.134: Failed to apply! Possible dependencies:
> 1f50ad2c86cd ("i2c: tegra: Add runtime power-management support")
> 21e9efd92bb5 ("i2c: tegra: disable clock before returning error")
> 497fbe24987b ("i2c: tegra: enable multi master mode for tegra210")
> 5b25b13ab08f ("sys_membarrier(): system-wide memory barrier (generic, x86)")
> 685143a1598b ("i2c: tegra: use readl_poll_timeout after config_load reg programmed")
> 6bec23bff914 ("i2c: mlxcpld: add master driver for mellanox systems")
> 6f4664b2e2c2 ("i2c: tegra: update CONFIG_LOAD for new conifiguration")
> 8700e3e7c485 ("Soft RoCE driver")
> 93c1edb27f9e ("mlxsw: Introduce Mellanox switch driver core")
> a7405844da1c ("i2c: at91: make use of the new infrastructure for quirks")
> ae3923a284cc ("i2c: busses: make i2c_adapter_quirks const")
> b94c820f3780 ("i2c: cpm: make use of the new infrastructure for quirks")
> be4fdf99fa4d ("leds: add driver for Mellanox systems LEDs")
> c02b7bf532f7 ("i2c: mux: mellanox: add driver")
> c5907c6b96f1 ("i2c: tegra: Add support for Tegra194")
> c96c0f268380 ("i2c: tegra: use core to detect 'no zero length' quirk")
> d57f5dedde18 ("i2c: tegra: add support for fast plus (FM+) mode clock rate")
> d64a818859af ("i2c: at91: add support for runtime PM")
> f5076685b3aa ("i2c: tegra: Fix missing blank lines after declarations")
>
>
> How should we proceed with this patch?
I guess it will be fine to either limit backporting down to just 5.0 or 4.20 (taking the kerneldoc dependency). Though probably most ideal variant will be to split the fix into two patches: first fixes the max transfer for older Tegra's and second for T194 specifically. Either way should be good enough since realistically none of upstream-supported devices should ever hit the bug (but that's not 100% of course).
On Mon, Feb 11, 2019 at 11:26 AM Sasha Levin <sashal(a)kernel.org> wrote:
>
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a "Fixes:" tag,
> fixing commit: 5118ccd34780 intel_th: pci: Add Denverton SOC support.
>
> The bot has tested the following trees: v4.20.7, v4.19.20, v4.14.98.
>
> v4.20.7: Build OK!
> v4.19.20: Build OK!
> v4.14.98: Failed to apply! Possible dependencies:
> fa564ad96366 ("x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 00-1f, 30-3f, 60-7f)")
>
>
> How should we proceed with this patch?
This patch should be applied to all stable kernels. There is no
dependency on any other patch. There will be trivial conflicts on
kernels older than v4.15, but those are easy to resolve.
Bjorn