Anthony Steinhauser <asteinhauser@xxxxxxxxxx> writes: > OK, I don't intend to work on it to that extent, so you can consider > this abandoned. I or someone else at IBM will pick this up and get it massaged into a form that Thomas is happy with. cheers > On Thu, Nov 14, 2019 at 2:55 PM Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: >> >> Anthony, >> >> On Thu, 14 Nov 2019, asteinhauser@xxxxxxxxxx wrote: >> >> > From: Anthony Steinhauser <asteinhauser@xxxxxxxxxx> >> > >> > There is a false negative that L1TF is Intel specific while it affects >> > also PowerPC: >> > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=8e6b6da91ac9b9ec5a925b6cb13f287a54bd547d >> >> Please use the regular >> >> commit 12-char-sha ("powerpc: .......") >> >> notation. These links are horrible. >> >> > Another false negative is that the kernel is unconditionally protected >> > against L1TF attacks from userspace. That's true only on x86 but not on >> > PowerPC where you can turn the protection off by nopti. >> >> Missing newline between body and SOB >> >> > Signed-off-by: Anthony Steinhauser <asteinhauser@xxxxxxxxxx> >> > --- >> > Documentation/admin-guide/hw-vuln/l1tf.rst | 15 +++++++++------ >> > 1 file changed, 9 insertions(+), 6 deletions(-) >> > >> > diff --git a/Documentation/admin-guide/hw-vuln/l1tf.rst b/Documentation/admin-guide/hw-vuln/l1tf.rst >> > index f83212fae4d5..243e494b337a 100644 >> > --- a/Documentation/admin-guide/hw-vuln/l1tf.rst >> > +++ b/Documentation/admin-guide/hw-vuln/l1tf.rst >> > @@ -9,10 +9,11 @@ for the access, has the Present bit cleared or other reserved bits set. >> > Affected processors >> > ------------------- >> > >> > -This vulnerability affects a wide range of Intel processors. The >> > -vulnerability is not present on: >> > +This vulnerability affects a wide range of Intel and PowerPC processors. >> > +The vulnerability is not present on: >> > >> > - - Processors from AMD, Centaur and other non Intel vendors >> > + - Processors from AMD, Centaur and other non Intel vendors except for >> > + PowerPC >> >> No. This needs restructuring. The non Intel vendor means vendors which >> produce x86 machines (not really clear TBH), but adding these two PPC parts >> above and here does not make it any better. >> >> > - Older processor models, where the CPU family is < 6 >> >> Also this suggest that _ALL_ PowerPC processors are affected as there is >> no exception list. >> >> So I suggest to structure this like this: >> >> Affected processors >> ------------------- >> >> 1) Intel processors >> >> Move the existing list here >> >> 2) PowerPC processors >> >> Add some meat >> >> Whether a processor is affected or not... >> >> > @@ -125,7 +126,7 @@ mitigations are active. The relevant sysfs file is: >> > >> > /sys/devices/system/cpu/vulnerabilities/l1tf >> > >> > -The possible values in this file are: >> > +The possible values in this file on x86 are: >> >> That commit you referenced added the sysfs output for powerpc. So that >> should be documented properly here as well, right? >> >> > =========================== =============================== >> > 'Not affected' The processor is not vulnerable >> > @@ -158,8 +159,10 @@ The resulting grade of protection is discussed in the following sections. >> > Host mitigation mechanism >> > ------------------------- >> > >> > -The kernel is unconditionally protected against L1TF attacks from malicious >> > -user space running on the host. >> > +On x86 the kernel is unconditionally protected against L1TF attacks from >> > +malicious user space running on the host. On PowerPC the kernel is >> > +protected by flushing the L1D cache on each transition from kernel to >> > +userspace unless the 'nopti' boot argument turns this mitigation off. >> >> Please make this clearly visually separated. Just glueing this together is >> hard to read. >> >> What about the l1tf boot param? Is it x86 only? If so, then this wants to >> be added to the the documentation as well. >> >> What about the guest to host issue on PPC? Not affected or same mitigation >> or what? >> >> We really spent a lot of time to write understandable and useful >> documentation. Just sprinkling a few powerpc'isms into it is really not >> cutting it. >> >> This needs proper structuring so that it's obvious for the intended >> audience (administrators, users) which part is applicable to which >> architecture or to both. >> >> Thanks, >> >> tglx
