OK, I don't intend to work on it to that extent, so you can consider this abandoned. 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
