Hi,
I just realized I replied to this off-list.
On 01/30/2019 12:02 PM, Andre Przywara wrote:
On Fri, 25 Jan 2019 12:07:00 -0600
Jeremy Linton <jeremy.linton@xxxxxxx> wrote:
Hi,
For a while Arm64 has been capable of force enabling
or disabling the kpti mitigations. Lets make sure the
documentation reflects that.
Signed-off-by: Jeremy Linton <jeremy.linton@xxxxxxx>
Cc: Jonathan Corbet <corbet@xxxxxxx>
Cc: linux-doc@xxxxxxxxxxxxxxx
---
Documentation/admin-guide/kernel-parameters.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt index
b799bcf67d7b..9475f02c79da 100644 ---
a/Documentation/admin-guide/kernel-parameters.txt +++
b/Documentation/admin-guide/kernel-parameters.txt @@ -1982,6 +1982,12
@@ Built with CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF=y,
the default is off.
+ kpti= [ARM64] Control page table isolation of
user
+ and kernel address spaces.
+ Default: enabled on cores which need
mitigation.
Would this be a good place to mention that we enable it when
CONFIG_RANDOMIZE_BASE is enabled and we have a valid kaslr_offset? I
found this somewhat surprising, also it's unrelated to the
vulnerability.
Maybe, but I tend to think since this command line forces it on/off
regardless of RANDOMIZE_BASE, that a better place to mention that
RANDOMIZE_BASE forces kpti on is the Kconfig option.
BTW: Thanks for reviewing this.
Cheers,
Andre
+ 0: force disabled
+ 1: force enabled
+
kvm.ignore_msrs=[KVM] Ignore guest accesses to unhandled
MSRs. Default is 0 (don't ignore, but inject #GP)
