From: "H. Peter Anvin" <hpa@zytor.com> To: Linus Torvalds <torvalds@linux-foundation.org> Cc: Nadav Amit <nadav.amit@gmail.com>, Joerg Roedel <joro@8bytes.org>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>, the arch/x86 maintainers <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>, "open list:MEMORY MANAGEMENT" <linux-mm@kvack.org>, Andy Lutomirski <luto@kernel.org>, Dave Hansen <dave.hansen@intel.com>, Josh Poimboeuf <jpoimboe@redhat.com>, Juergen Gross <jgross@suse.com>, Peter Zijlstra <peterz@infradead.org>, Borislav Petkov <bp@alien8.de>, Jiri Kosina <jkosina@suse.cz>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, Brian Gerst <brgerst@gmail.com>, David Laight <David.Laight@aculab.com>, Denys Vlasenko <dvlasenk@redhat.com>, Eduardo Valentin <eduval@amazon.com>, Greg KH <gregkh@linuxfoundation.org>, Will Deacon <will.deacon@arm.com>, "Liguori, Anthony" <aliguori@amazon.com>, Daniel Gruss <daniel.gruss@iaik.tugraz.at>, Hugh Dickins <hughd@google.com>, Kees Cook <keescook@google.com>, Andrea Arcangeli <aarcange@redhat.com>, Waiman Long <llong@redhat.com>, Joerg Roedel <jroedel@suse.de> Subject: Re: [RFC PATCH 00/16] PTI support for x86-32 Date: Mon, 22 Jan 2018 13:10:19 -0800 [thread overview] Message-ID: <aedcd5b4-f054-0579-d9e2-8439b982a5dd@zytor.com> (raw) In-Reply-To: <CA+55aFxg5H38Ef4DUgMQ7KrsUtWdaKYKCRFZ8rangUrZ=OgCEw@mail.gmail.com> On 01/22/18 12:14, Linus Torvalds wrote: > On Sun, Jan 21, 2018 at 6:20 PM, <hpa@zytor.com> wrote: >> >> No idea about Intel, but at least on Transmeta CPUs the limit check was asynchronous with the access. > > Yes, but TMTA had a really odd uarch and didn't check segment limits natively. > Only on TM3000 ("Wilma") and TM5000 ("Fred"), not on TM8000 ("Astro"). Astro might in fact have been more synchronous than most modern machines (see below.) > When you do it in hardware. the limit check is actually fairly natural > to do early rather than late (since it acts on the linear address > _before_ base add and TLB lookup). > > So it's not like it can't be done late, but there are reasons why a > traditional microarchitecture might always end up doing the limit > check early and so segmentation might be a good defense against > meltdown on 32-bit Intel. I will try to investigate, but as you can imagine the amount of bandwidth I might be able to get on this is definitely going to be limited. All of the below is generic discussion that almost certainly can be found in some form in Hennesey & Patterson, and so I don't have to worry about giving away Intel secrets: It isn't really true that it is natural to check this early. One of the most fundamental frequency limiters in a modern CPU architecture (meaning anything from the last 20 years or so) has been the data-dependent AGU-D$-AGU loop. Note that this doesn't even include the TLB: the TLB is looked up in parallel with the D$, and if the result was *either* a cache-TLB mismatch or a TLB miss the result is prevented from committing. In the case of the x86, the AGU receives up to three sources plus the segment base, and if possible given the target process and gates available might be designed to have a unified 4-input adder, with the 3-input case for limit checks being done separately. Misses and even more so exceptions (which are far less frequent than misses) are demoted to a slower where the goal is to prevent commit rather than trying to race to be in the data path. So although it is natural to *issue* the load and the limit check at the same time, the limit check is still going to be deferred. Whether or not it is permitted to be fully asynchronous with the load is probably a tradeoff of timing requirements vs complexity. At least theoretically one could imagine a machine which would take the trap after the speculative machine had already chased the pointer loop several levels down; this would most likely mean separate uops to allow for the existing out-of-order machine to do the bookkeeping. -hpa
WARNING: multiple messages have this Message-ID (diff)
From: "H. Peter Anvin" <hpa@zytor.com> To: Linus Torvalds <torvalds@linux-foundation.org> Cc: Nadav Amit <nadav.amit@gmail.com>, Joerg Roedel <joro@8bytes.org>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>, the arch/x86 maintainers <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>, "open list:MEMORY MANAGEMENT" <linux-mm@kvack.org>, Andy Lutomirski <luto@kernel.org>, Dave Hansen <dave.hansen@intel.com>, Josh Poimboeuf <jpoimboe@redhat.com>, Juergen Gross <jgross@suse.com>, Peter Zijlstra <peterz@infradead.org>, Borislav Petkov <bp@alien8.de>, Jiri Kosina <jkosina@suse.cz>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, Brian Gerst <brgerst@gmail.com>, David Laight <David.Laight@aculab.com>, Denys Vlasenko <dvlasenk@redhat.com>, Eduardo Valentin <eduval@amazon.com>, Greg KH <gregkh@linuxfoundation.org>, Will Deacon <will.deacon@arm.com>, "Liguori, Anthony" <aliguori@amazon.com>, Daniel Gruss <daniel.gruss@iaik.tugraz.at>, Hugh Dickins <hughd@google.com>, Kees Cook <keescook@google.com>, Andrea Arcangeli <aarcange@redhat.com>, Waiman Long <llong@redhat.com>, Joerg Roedel <jroedel@suse.de> Subject: Re: [RFC PATCH 00/16] PTI support for x86-32 Date: Mon, 22 Jan 2018 13:10:19 -0800 [thread overview] Message-ID: <aedcd5b4-f054-0579-d9e2-8439b982a5dd@zytor.com> (raw) In-Reply-To: <CA+55aFxg5H38Ef4DUgMQ7KrsUtWdaKYKCRFZ8rangUrZ=OgCEw@mail.gmail.com> On 01/22/18 12:14, Linus Torvalds wrote: > On Sun, Jan 21, 2018 at 6:20 PM, <hpa@zytor.com> wrote: >> >> No idea about Intel, but at least on Transmeta CPUs the limit check was asynchronous with the access. > > Yes, but TMTA had a really odd uarch and didn't check segment limits natively. > Only on TM3000 ("Wilma") and TM5000 ("Fred"), not on TM8000 ("Astro"). Astro might in fact have been more synchronous than most modern machines (see below.) > When you do it in hardware. the limit check is actually fairly natural > to do early rather than late (since it acts on the linear address > _before_ base add and TLB lookup). > > So it's not like it can't be done late, but there are reasons why a > traditional microarchitecture might always end up doing the limit > check early and so segmentation might be a good defense against > meltdown on 32-bit Intel. I will try to investigate, but as you can imagine the amount of bandwidth I might be able to get on this is definitely going to be limited. All of the below is generic discussion that almost certainly can be found in some form in Hennesey & Patterson, and so I don't have to worry about giving away Intel secrets: It isn't really true that it is natural to check this early. One of the most fundamental frequency limiters in a modern CPU architecture (meaning anything from the last 20 years or so) has been the data-dependent AGU-D$-AGU loop. Note that this doesn't even include the TLB: the TLB is looked up in parallel with the D$, and if the result was *either* a cache-TLB mismatch or a TLB miss the result is prevented from committing. In the case of the x86, the AGU receives up to three sources plus the segment base, and if possible given the target process and gates available might be designed to have a unified 4-input adder, with the 3-input case for limit checks being done separately. Misses and even more so exceptions (which are far less frequent than misses) are demoted to a slower where the goal is to prevent commit rather than trying to race to be in the data path. So although it is natural to *issue* the load and the limit check at the same time, the limit check is still going to be deferred. Whether or not it is permitted to be fully asynchronous with the load is probably a tradeoff of timing requirements vs complexity. At least theoretically one could imagine a machine which would take the trap after the speculative machine had already chased the pointer loop several levels down; this would most likely mean separate uops to allow for the existing out-of-order machine to do the bookkeeping. -hpa -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2018-01-22 21:10 UTC|newest] Thread overview: 183+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-01-16 16:36 [RFC PATCH 00/16] PTI support for x86-32 Joerg Roedel 2018-01-16 16:36 ` Joerg Roedel 2018-01-16 16:36 ` [PATCH 01/16] x86/entry/32: Rename TSS_sysenter_sp0 to TSS_sysenter_stack Joerg Roedel 2018-01-16 16:36 ` Joerg Roedel 2018-01-16 18:35 ` Thomas Gleixner 2018-01-16 18:35 ` Thomas Gleixner 2018-01-16 16:36 ` [PATCH 02/16] x86/entry/32: Enter the kernel via trampoline stack Joerg Roedel 2018-01-16 16:36 ` Joerg Roedel 2018-01-16 20:30 ` Thomas Gleixner 2018-01-16 20:30 ` Thomas Gleixner 2018-01-16 22:37 ` Andy Lutomirski 2018-01-16 22:37 ` Andy Lutomirski 2018-01-16 22:45 ` Andy Lutomirski 2018-01-16 22:45 ` Andy Lutomirski 2018-01-17 9:18 ` Joerg Roedel 2018-01-17 9:18 ` Joerg Roedel 2018-01-17 18:10 ` Andy Lutomirski 2018-01-17 18:10 ` Andy Lutomirski 2018-01-19 9:55 ` Joerg Roedel 2018-01-19 9:55 ` Joerg Roedel 2018-01-19 16:30 ` Andy Lutomirski 2018-01-19 16:30 ` Andy Lutomirski 2018-01-22 10:11 ` Joerg Roedel 2018-01-22 10:11 ` Joerg Roedel 2018-01-22 17:46 ` Andy Lutomirski 2018-01-22 17:46 ` Andy Lutomirski 2018-01-17 2:47 ` Boris Ostrovsky 2018-01-17 2:47 ` Boris Ostrovsky 2018-01-17 9:02 ` Joerg Roedel 2018-01-17 9:02 ` Joerg Roedel 2018-01-17 14:04 ` Andrew Cooper 2018-01-17 14:04 ` Andrew Cooper 2018-01-17 15:22 ` Boris Ostrovsky 2018-01-17 15:22 ` Boris Ostrovsky 2018-01-16 16:36 ` [PATCH 03/16] x86/entry/32: Leave the kernel via the " Joerg Roedel 2018-01-16 16:36 ` Joerg Roedel 2018-01-16 22:48 ` Andy Lutomirski 2018-01-16 22:48 ` Andy Lutomirski 2018-01-17 9:24 ` Joerg Roedel 2018-01-17 9:24 ` Joerg Roedel 2018-01-17 13:57 ` Brian Gerst 2018-01-17 13:57 ` Brian Gerst 2018-01-17 14:00 ` Brian Gerst 2018-01-17 14:00 ` Brian Gerst 2018-01-17 14:14 ` Joerg Roedel 2018-01-17 14:14 ` Joerg Roedel 2018-01-17 14:45 ` Josh Poimboeuf 2018-01-17 14:45 ` Josh Poimboeuf 2018-01-17 14:10 ` Joerg Roedel 2018-01-17 14:10 ` Joerg Roedel 2018-01-17 18:12 ` Andy Lutomirski 2018-01-17 18:12 ` Andy Lutomirski 2018-01-19 9:57 ` Joerg Roedel 2018-01-19 9:57 ` Joerg Roedel 2018-01-16 16:36 ` [PATCH 04/16] x86/pti: Define X86_CR3_PTI_PCID_USER_BIT on x86_32 Joerg Roedel 2018-01-16 16:36 ` Joerg Roedel 2018-01-16 22:46 ` Andy Lutomirski 2018-01-16 22:46 ` Andy Lutomirski 2018-01-17 9:26 ` Joerg Roedel 2018-01-17 9:26 ` Joerg Roedel 2018-01-16 16:36 ` [PATCH 05/16] x86/pgtable: Move pgdp kernel/user conversion functions to pgtable.h Joerg Roedel 2018-01-16 16:36 ` Joerg Roedel 2018-01-16 16:36 ` [PATCH 06/16] x86/mm/ldt: Reserve high address-space range for the LDT Joerg Roedel 2018-01-16 16:36 ` Joerg Roedel 2018-01-16 16:52 ` Peter Zijlstra 2018-01-16 16:52 ` Peter Zijlstra 2018-01-16 17:13 ` Joerg Roedel 2018-01-16 17:13 ` Joerg Roedel 2018-01-16 17:31 ` Peter Zijlstra 2018-01-16 17:31 ` Peter Zijlstra 2018-01-16 17:34 ` Waiman Long 2018-01-16 17:34 ` Waiman Long 2018-01-16 22:51 ` Andy Lutomirski 2018-01-16 22:51 ` Andy Lutomirski 2018-01-17 7:59 ` Peter Zijlstra 2018-01-17 7:59 ` Peter Zijlstra 2018-01-16 16:36 ` [PATCH 07/16] x86/mm: Move two more functions from pgtable_64.h to pgtable.h Joerg Roedel 2018-01-16 16:36 ` Joerg Roedel 2018-01-16 18:03 ` Dave Hansen 2018-01-16 18:03 ` Dave Hansen 2018-01-16 19:11 ` Joerg Roedel 2018-01-16 19:11 ` Joerg Roedel 2018-01-16 19:34 ` Thomas Gleixner 2018-01-16 19:34 ` Thomas Gleixner 2018-01-16 16:36 ` [PATCH 08/16] x86/pgtable/32: Allocate 8k page-tables when PTI is enabled Joerg Roedel 2018-01-16 16:36 ` Joerg Roedel 2018-01-17 23:43 ` Andy Lutomirski 2018-01-17 23:43 ` Andy Lutomirski 2018-01-19 9:57 ` Joerg Roedel 2018-01-19 9:57 ` Joerg Roedel 2018-01-16 16:36 ` [PATCH 09/16] x86/mm/pti: Clone CPU_ENTRY_AREA on PMD level on x86_32 Joerg Roedel 2018-01-16 16:36 ` Joerg Roedel 2018-01-16 21:03 ` Thomas Gleixner 2018-01-16 21:03 ` Thomas Gleixner 2018-01-16 16:36 ` [PATCH 10/16] x86/mm/pti: Populate valid user pud entries Joerg Roedel 2018-01-16 16:36 ` Joerg Roedel 2018-01-16 18:06 ` Dave Hansen 2018-01-16 18:06 ` Dave Hansen 2018-01-16 19:41 ` Joerg Roedel 2018-01-16 19:41 ` Joerg Roedel 2018-01-16 21:06 ` Thomas Gleixner 2018-01-16 21:06 ` Thomas Gleixner 2018-01-16 16:36 ` [PATCH 11/16] x86/mm/pgtable: Move pti_set_user_pgd() to pgtable.h Joerg Roedel 2018-01-16 16:36 ` Joerg Roedel 2018-01-16 16:36 ` [PATCH 12/16] x86/mm/pae: Populate the user page-table with user pgd's Joerg Roedel 2018-01-16 16:36 ` Joerg Roedel 2018-01-16 18:11 ` Dave Hansen 2018-01-16 18:11 ` Dave Hansen 2018-01-16 19:44 ` Joerg Roedel 2018-01-16 19:44 ` Joerg Roedel 2018-01-16 21:10 ` Thomas Gleixner 2018-01-16 21:10 ` Thomas Gleixner 2018-01-16 21:15 ` Dave Hansen 2018-01-16 21:15 ` Dave Hansen 2018-01-16 16:36 ` [PATCH 13/16] x86/mm/pti: Add an overflow check to pti_clone_pmds() Joerg Roedel 2018-01-16 16:36 ` Joerg Roedel 2018-01-16 16:36 ` [PATCH 14/16] x86/mm/legacy: Populate the user page-table with user pgd's Joerg Roedel 2018-01-16 16:36 ` Joerg Roedel 2018-01-17 23:41 ` Andy Lutomirski 2018-01-17 23:41 ` Andy Lutomirski 2018-01-16 16:36 ` [PATCH 15/16] x86/entry/32: Switch between kernel and user cr3 on entry/exit Joerg Roedel 2018-01-16 16:36 ` Joerg Roedel 2018-01-16 16:36 ` [PATCH 16/16] x86/pti: Allow CONFIG_PAGE_TABLE_ISOLATION for x86_32 Joerg Roedel 2018-01-16 16:36 ` Joerg Roedel 2018-01-16 18:14 ` [RFC PATCH 00/16] PTI support for x86-32 Dave Hansen 2018-01-16 18:14 ` Dave Hansen 2018-01-16 19:46 ` Joerg Roedel 2018-01-16 19:46 ` Joerg Roedel 2018-01-16 18:59 ` Linus Torvalds 2018-01-16 18:59 ` Linus Torvalds 2018-01-16 19:02 ` Dave Hansen 2018-01-16 19:02 ` Dave Hansen 2018-01-16 19:21 ` Andrew Cooper 2018-01-16 19:21 ` Andrew Cooper 2018-01-16 19:55 ` Joerg Roedel 2018-01-16 19:55 ` Joerg Roedel 2018-01-16 21:20 ` Thomas Gleixner 2018-01-16 21:20 ` Thomas Gleixner 2018-01-17 9:55 ` Joerg Roedel 2018-01-17 9:55 ` Joerg Roedel 2018-01-16 22:26 ` Andy Lutomirski 2018-01-16 22:26 ` Andy Lutomirski 2018-01-17 9:33 ` Joerg Roedel 2018-01-17 9:33 ` Joerg Roedel 2018-01-19 10:55 ` Pavel Machek 2018-01-19 11:07 ` Joerg Roedel 2018-01-19 11:07 ` Joerg Roedel 2018-01-19 12:58 ` Pavel Machek 2018-01-21 20:13 ` Nadav Amit 2018-01-21 20:13 ` Nadav Amit 2018-01-21 20:44 ` Nadav Amit 2018-01-21 20:44 ` Nadav Amit 2018-01-21 23:46 ` Nadav Amit 2018-01-21 23:46 ` Nadav Amit 2018-01-22 2:11 ` Linus Torvalds 2018-01-22 2:11 ` Linus Torvalds 2018-01-22 2:20 ` hpa 2018-01-22 2:20 ` hpa 2018-01-22 20:14 ` Linus Torvalds 2018-01-22 20:14 ` Linus Torvalds 2018-01-22 21:10 ` H. Peter Anvin [this message] 2018-01-22 21:10 ` H. Peter Anvin 2018-01-23 14:38 ` Alan Cox 2018-01-23 14:38 ` Alan Cox 2018-01-22 2:27 ` Nadav Amit 2018-01-22 2:27 ` Nadav Amit 2018-01-22 8:56 ` Joerg Roedel 2018-01-22 8:56 ` Joerg Roedel 2018-01-23 14:57 ` Alan Cox 2018-01-23 14:57 ` Alan Cox 2018-01-25 17:09 ` Alan Cox 2018-01-25 17:09 ` Alan Cox 2018-01-26 12:36 ` Joerg Roedel 2018-01-26 12:36 ` Joerg Roedel 2018-01-22 9:55 ` David Laight 2018-01-22 10:04 ` Joerg Roedel 2018-01-22 10:04 ` Joerg Roedel 2018-01-24 18:58 ` Krzysztof Mazur 2018-01-24 18:58 ` Krzysztof Mazur 2018-01-25 22:09 ` Nadav Amit 2018-01-25 22:09 ` Nadav Amit 2018-01-26 9:28 ` Krzysztof Mazur 2018-01-26 9:28 ` Krzysztof Mazur
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=aedcd5b4-f054-0579-d9e2-8439b982a5dd@zytor.com \ --to=hpa@zytor.com \ --cc=David.Laight@aculab.com \ --cc=aarcange@redhat.com \ --cc=aliguori@amazon.com \ --cc=boris.ostrovsky@oracle.com \ --cc=bp@alien8.de \ --cc=brgerst@gmail.com \ --cc=daniel.gruss@iaik.tugraz.at \ --cc=dave.hansen@intel.com \ --cc=dvlasenk@redhat.com \ --cc=eduval@amazon.com \ --cc=gregkh@linuxfoundation.org \ --cc=hughd@google.com \ --cc=jgross@suse.com \ --cc=jkosina@suse.cz \ --cc=joro@8bytes.org \ --cc=jpoimboe@redhat.com \ --cc=jroedel@suse.de \ --cc=keescook@google.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=llong@redhat.com \ --cc=luto@kernel.org \ --cc=mingo@kernel.org \ --cc=nadav.amit@gmail.com \ --cc=peterz@infradead.org \ --cc=tglx@linutronix.de \ --cc=torvalds@linux-foundation.org \ --cc=will.deacon@arm.com \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.