From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751974AbeAWTEH (ORCPT ); Tue, 23 Jan 2018 14:04:07 -0500 Received: from smtp.ctxuk.citrix.com ([185.25.65.24]:15408 "EHLO SMTP.EU.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751897AbeAWTEG (ORCPT ); Tue, 23 Jan 2018 14:04:06 -0500 X-IronPort-AV: E=Sophos;i="5.46,402,1511827200"; d="scan'208";a="66545111" Subject: Re: [PATCH v2 5/5] x86/pti: Do not enable PTI on fixed Intel processors To: Alan Cox , David Woodhouse CC: References: <1516726375-25168-1-git-send-email-dwmw@amazon.co.uk> <1516726375-25168-6-git-send-email-dwmw@amazon.co.uk> <20180123173312.1d8cf02f@alans-desktop> From: Andrew Cooper Message-ID: Date: Tue, 23 Jan 2018 19:02:51 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180123173312.1d8cf02f@alans-desktop> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 23/01/18 18:45, Alan Cox wrote: > On Tue, 23 Jan 2018 16:52:55 +0000 > David Woodhouse wrote: > >> When they advertise the IA32_ARCH_CAPABILITIES MSR and it has the RDCL_NO >> bit set, they don't need KPTI either. > This is starting to get messy because we will eventually need to integrate > > AMD processors - no meltdown but spectre > VIA processors - probably no vulnerabilities at > least on the old ones > Intel with ND set - No meltdown > Anybody with no speculation - No meltdown, no spectre, no id bit > > > > and it expands a lot with all sorts of 32bit processors. Would it make > more sense to make it table driven or do we want a separate function so > we can do: > > if (!in_order_cpu()) { > } > > around the whole lot ? I'm guessing the latter makes sense then > somethhing like this patch I'm running on my old atom widgets in 64bit > mode > > static __initdata struct x86_cpu_id cpu_in_order[] = { > { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CEDARVIEW, X86_FEATURE_ANY }, > { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CLOVERVIEW, X86_FEATURE_ANY }, > { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_LINCROFT, X86_FEATURE_ANY }, > { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_PENWELL, X86_FEATURE_ANY }, > { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_PINEVIEW, X86_FEATURE_ANY }, > {} > }; > > static int in_order_cpu(void) > { > /* Processors with CPU id etc */ > if (x86_match_cpu(cpu_in_order)) > return 1; > /* Other rules here */ > return 0; > } Why does in-order vs out-of-order matter? There are leaky SP3 gadgets which satisfy in-order requirements, so long as the processor is capable of speculating 3 instructions past an unresolved branch. What would (at a guess) save an in-order speculative processor from being vulnerable is if memory reads are issued and resolve in program order, but in that case, it is not the in-order property of the processor which makes it safe. ~Andrew