Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 27e14ecb authored by Linux Build Service Account's avatar Linux Build Service Account Committed by Gerrit - the friendly Code Review server
Browse files

Merge "Merge remote-tracking branch 'remotes/origin/tmp-6150ee7b' into msm-4.14"

parents 0582afba 680fa500
Loading
Loading
Loading
Loading
+0 −2
Original line number Diff line number Diff line
@@ -2733,8 +2733,6 @@
	norandmaps	Don't use address space randomization.  Equivalent to
			echo 0 > /proc/sys/kernel/randomize_va_space

	noreplace-paravirt	[X86,IA-64,PV_OPS] Don't patch paravirt_ops

	noreplace-smp	[X86-32,SMP] Don't replace SMP instructions
			with UP alternatives

+90 −0
Original line number Diff line number Diff line
This document explains potential effects of speculation, and how undesirable
effects can be mitigated portably using common APIs.

===========
Speculation
===========

To improve performance and minimize average latencies, many contemporary CPUs
employ speculative execution techniques such as branch prediction, performing
work which may be discarded at a later stage.

Typically speculative execution cannot be observed from architectural state,
such as the contents of registers. However, in some cases it is possible to
observe its impact on microarchitectural state, such as the presence or
absence of data in caches. Such state may form side-channels which can be
observed to extract secret information.

For example, in the presence of branch prediction, it is possible for bounds
checks to be ignored by code which is speculatively executed. Consider the
following code:

	int load_array(int *array, unsigned int index)
	{
		if (index >= MAX_ARRAY_ELEMS)
			return 0;
		else
			return array[index];
	}

Which, on arm64, may be compiled to an assembly sequence such as:

	CMP	<index>, #MAX_ARRAY_ELEMS
	B.LT	less
	MOV	<returnval>, #0
	RET
  less:
	LDR	<returnval>, [<array>, <index>]
	RET

It is possible that a CPU mis-predicts the conditional branch, and
speculatively loads array[index], even if index >= MAX_ARRAY_ELEMS. This
value will subsequently be discarded, but the speculated load may affect
microarchitectural state which can be subsequently measured.

More complex sequences involving multiple dependent memory accesses may
result in sensitive information being leaked. Consider the following
code, building on the prior example:

	int load_dependent_arrays(int *arr1, int *arr2, int index)
	{
		int val1, val2,

		val1 = load_array(arr1, index);
		val2 = load_array(arr2, val1);

		return val2;
	}

Under speculation, the first call to load_array() may return the value
of an out-of-bounds address, while the second call will influence
microarchitectural state dependent on this value. This may provide an
arbitrary read primitive.

====================================
Mitigating speculation side-channels
====================================

The kernel provides a generic API to ensure that bounds checks are
respected even under speculation. Architectures which are affected by
speculation-based side-channels are expected to implement these
primitives.

The array_index_nospec() helper in <linux/nospec.h> can be used to
prevent information from being leaked via side-channels.

A call to array_index_nospec(index, size) returns a sanitized index
value that is bounded to [0, size) even under cpu speculation
conditions.

This can be used to protect the earlier load_array() example:

	int load_array(int *array, unsigned int index)
	{
		if (index >= MAX_ARRAY_ELEMS)
			return 0;
		else {
			index = array_index_nospec(index, MAX_ARRAY_ELEMS);
			return array[index];
		}
	}
+1 −1
Original line number Diff line number Diff line
# SPDX-License-Identifier: GPL-2.0
VERSION = 4
PATCHLEVEL = 14
SUBLEVEL = 17
SUBLEVEL = 18
EXTRAVERSION =
NAME = Petit Gorille

+1 −0
Original line number Diff line number Diff line
@@ -164,6 +164,7 @@ config PPC
	select GENERIC_CLOCKEVENTS_BROADCAST	if SMP
	select GENERIC_CMOS_UPDATE
	select GENERIC_CPU_AUTOPROBE
	select GENERIC_CPU_VULNERABILITIES	if PPC_BOOK3S_64
	select GENERIC_IRQ_SHOW
	select GENERIC_IRQ_SHOW_LEVEL
	select GENERIC_SMP_IDLE_THREAD
+38 −0
Original line number Diff line number Diff line
@@ -38,6 +38,7 @@
#include <linux/memory.h>
#include <linux/nmi.h>

#include <asm/debugfs.h>
#include <asm/io.h>
#include <asm/kdump.h>
#include <asm/prom.h>
@@ -884,4 +885,41 @@ void __init setup_rfi_flush(enum l1d_flush_type types, bool enable)
	if (!no_rfi_flush)
		rfi_flush_enable(enable);
}

#ifdef CONFIG_DEBUG_FS
static int rfi_flush_set(void *data, u64 val)
{
	if (val == 1)
		rfi_flush_enable(true);
	else if (val == 0)
		rfi_flush_enable(false);
	else
		return -EINVAL;

	return 0;
}

static int rfi_flush_get(void *data, u64 *val)
{
	*val = rfi_flush ? 1 : 0;
	return 0;
}

DEFINE_SIMPLE_ATTRIBUTE(fops_rfi_flush, rfi_flush_get, rfi_flush_set, "%llu\n");

static __init int rfi_flush_debugfs_init(void)
{
	debugfs_create_file("rfi_flush", 0600, powerpc_debugfs_root, NULL, &fops_rfi_flush);
	return 0;
}
device_initcall(rfi_flush_debugfs_init);
#endif

ssize_t cpu_show_meltdown(struct device *dev, struct device_attribute *attr, char *buf)
{
	if (rfi_flush)
		return sprintf(buf, "Mitigation: RFI Flush\n");

	return sprintf(buf, "Vulnerable\n");
}
#endif /* CONFIG_PPC_BOOK3S_64 */
Loading