From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x224uCgH93wAwNfXHG3CJ72ytQa3jbPbee/ITjOkw0PmE53T35Qvbn51V45ULY6/09ZcvA0BP ARC-Seal: i=1; a=rsa-sha256; t=1516656453; cv=none; d=google.com; s=arc-20160816; b=QCcY7j7JV5JfMVf4z/vrYWpG0YXX4f0j6VQjJVFd7ZB/mhwPRM9TmaFs2t5Mks7Dg8 F1a1z/VpwVjJEzOOqaZNU+eJzdqFV0KuOFzEsz70Ly5Au4WXULdAQdLaoipPrHe7k7m+ GaRGkNXHktG4wAHEmnp9uEYfBKjlpbGIN0QY69NzM6rLd0AKLPGTsCwmX6Blp5sJBNYy WyOEIZEY6+UoJBMcpNV4Hi30CDUMs12wCM7aO5GETeEBP6t6hTkxnBHr7Oo+UkoHLBtG 2Zf10BOppBf8bYXJJWuUQhLdnX3YovhHYbS5Qrm3llKUgbfIMOxox8pvLn2s10x5ajyA jBNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject :arc-authentication-results; bh=bCHiYnTXy31KZBLKyJLs2VwoeM66e7Q/EGoBgNo9ZH4=; b=vXeo8corl0yEuOtt9W4kawnwPlGgqTxs0PdgbnIIskMev/Ip9FjcEQ8NEF0pAIwP1D JdoiWos3fhhrBFzJ1AobjbQESfTuf9AOZhwzcwfW6M7lJ+o/Y2Wnyy+hBQ0W13c6Nok3 5/jaztpLYjAZm2NPYrB5HjSqsySfO3I6UZtUdhizPKYJxooOzxkSqqjLiAJYMWW7bv9c XBUlhW13SnpQksPV5/MT3J8cLAuoA9M9ahkCOdHPH2CjZ11QhM1a8LrHjZXMUhPKBXGR tzq823PMzrlClilZ4qH6E47Ps5mfx3S+44yWL9JKVVopyB5Om4TwS9i3auqv8TbU1cym QSzw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of hpa@zytor.com designates 65.50.211.136 as permitted sender) smtp.mailfrom=hpa@zytor.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of hpa@zytor.com designates 65.50.211.136 as permitted sender) smtp.mailfrom=hpa@zytor.com Subject: Re: [RFC PATCH 00/16] PTI support for x86-32 To: Linus Torvalds Cc: Nadav Amit , Joerg Roedel , Thomas Gleixner , Ingo Molnar , the arch/x86 maintainers , LKML , "open list:MEMORY MANAGEMENT" , Andy Lutomirski , Dave Hansen , Josh Poimboeuf , Juergen Gross , Peter Zijlstra , Borislav Petkov , Jiri Kosina , Boris Ostrovsky , Brian Gerst , David Laight , Denys Vlasenko , Eduardo Valentin , Greg KH , Will Deacon , "Liguori, Anthony" , Daniel Gruss , Hugh Dickins , Kees Cook , Andrea Arcangeli , Waiman Long , Joerg Roedel References: <1516120619-1159-1-git-send-email-joro@8bytes.org> <5D89F55C-902A-4464-A64E-7157FF55FAD0@gmail.com> <886C924D-668F-4007-98CA-555DB6279E4F@gmail.com> <9CF1DD34-7C66-4F11-856D-B5E896988E16@gmail.com> <143DE376-A8A4-4A91-B4FF-E258D578242D@zytor.com> From: "H. Peter Anvin" Message-ID: Date: Mon, 22 Jan 2018 13:10:19 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1589767841591470697?= X-GMAIL-MSGID: =?utf-8?q?1590329558010384616?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On 01/22/18 12:14, Linus Torvalds wrote: > On Sun, Jan 21, 2018 at 6:20 PM, 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