Thanks a lot, Michael! On Fri, Nov 15, 2019 at 3:41 AM Michael Ellerman <mpe@xxxxxxxxxxxxxx> wrote: > > 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
