Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp3118498ybk; Mon, 18 May 2020 18:37:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyfpfn3OZmMRzgdJ3QgOY3TzoFa7OQiM/bmK0GsrXxbMKkk23dLmL7YYWOwrhW//l08v2uG X-Received: by 2002:a50:e84b:: with SMTP id k11mr16513545edn.204.1589852231907; Mon, 18 May 2020 18:37:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589852231; cv=none; d=google.com; s=arc-20160816; b=JxnTGG6qBT3kY6aUxzVwy5SjUBNTonDngX0vAB4nHhoNYMvOjGhlDSETl0cY1yr+Dh N35ldCOcBYcGwcgNufC2kqj4rYo0GmOtaqTh/bDk4ByYATNj6OCN4ePRkCg5wProav9J syzVP5/f9byy7VY/LRCXZhzhxWe0id0asjz0dAytBy+OLcCnoCJ9JHJ9TqD7AIZfFdO+ hOQPKI3DB/BczbNygydqcn9SX6/SzELos+xYub9xZEfYeyw0qGnVONcuMoLy//nesj+M ISTvrmvh74l0T3CV9zJSfJ0XAHGqBIm0y9EtiYXKnpaalcW7w/f/Fzj1AmOV1hg8ZlxF EPQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:in-reply-to:cc:references:message-id :date:subject:mime-version:from:content-transfer-encoding :dkim-signature; bh=eH46HFXVZAPfiSp4yenoocGuq08o9xIexbUXyqPElZM=; b=efmjiX0XR6c/HZbSpDeRrGcjq0siW8XxzRGF7NVx01EeI+5HO93dirvZa5nqI9B/CJ tMrkhrsXehXBTQSIbuQImEVRdThzCzKWCORvaEwMMwTV68//b+HJzNVcOReY/cdUjlh/ pA9t6ty/Z1FjuSZc9dO1xJjGlSgUQUwhlx7dzgBpuLiBgRljMcPSatz5a41dhMt0VRJg /CTw6zth9JatZMYpPJBetIn8yMIkwn+Z+LhYw0k7BAJMWo0ScqK+/cbvEOtUMrma976g oUTGxVciLTsGMU0NMvbNFn5d4yVvK64fJyGWjllsf+4E9Us/r8zrkQMeeA7Wi9vXe8Ke Rp8g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=MUO3gqmI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dp11si6833551ejc.463.2020.05.18.18.36.48; Mon, 18 May 2020 18:37:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=MUO3gqmI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726573AbgESBf2 (ORCPT + 99 others); Mon, 18 May 2020 21:35:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49124 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726532AbgESBf1 (ORCPT ); Mon, 18 May 2020 21:35:27 -0400 Received: from mail-pl1-x641.google.com (mail-pl1-x641.google.com [IPv6:2607:f8b0:4864:20::641]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5E9F4C061A0C for ; Mon, 18 May 2020 18:35:27 -0700 (PDT) Received: by mail-pl1-x641.google.com with SMTP id b12so4944420plz.13 for ; Mon, 18 May 2020 18:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=eH46HFXVZAPfiSp4yenoocGuq08o9xIexbUXyqPElZM=; b=MUO3gqmIH8arkfIZPDEnbj00SQROT+XbT+rDPd75eB/HjRGwYyynILINnbvrKpXwEh xjH/zddHN9oG2KUZQh2WDdjrzRHcWR924fHvxZmLPfTJdee4nGqk/TmPTpHq6UOnoSUY Nozsfy/yQQHZDuEJxIwU5re+Vw3ej5MOtr0VWeszUDlEBFOlzqSCZf1+kGB36LV8nFUS p31AewNcXmp3fgPUaHEiV6z+GZWbHK2/pYqyfvA+Oz5jvNqeI9q2Bg9FM+0TD4x/ahM5 lWrAfGLCf1+679BxrayorUF3lrsFQlGBbjKB8TlTMIVRgW1CavVzF3C1QAL1cnXt1ks1 8d/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=eH46HFXVZAPfiSp4yenoocGuq08o9xIexbUXyqPElZM=; b=eyARlfq9N2jl3sYZt6ybWn7lXFE1YZTzTndYUpOMISQnneyGfOPJnvEUXPS1M+G9qc HPEdFoRK96umAm8wfRLlQ2Ep2yFbtg8xRSSCDsLi1eziAL9cdA7LmU1AdjrQ6iBxgJin MH7VWrwaFagFNXZR0IQ//oYV3n1gpSn4eYRWwzw47yPfHZm4UK0v8YJcRxMGPEFTaYPe vK3dAvTAGc5quX6z7OnjOl1nX5qqGO826c2U1tF+VV/LeyGN3P5b7NpWMP9fdZzb64ZE Yw7D+1bY8vEPOuRu6waYurJphkM6xO7AQYwwzWPmtTcSe10vK91RGS9+GxKc3tOAnJrG xbTA== X-Gm-Message-State: AOAM532v8k0yJ3VY5aUxP+hiF73Vjvk+rbC8SpE4L4rIihnjbp5ZdHcA Tuw2dNUYgX0zQa6MaSEFrUqoig== X-Received: by 2002:a17:90a:930b:: with SMTP id p11mr2442189pjo.46.1589852126573; Mon, 18 May 2020 18:35:26 -0700 (PDT) Received: from ?IPv6:2601:646:c200:1ef2:9c3c:ad41:e2e7:d4f4? ([2601:646:c200:1ef2:9c3c:ad41:e2e7:d4f4]) by smtp.gmail.com with ESMTPSA id 206sm4735467pfy.97.2020.05.18.18.35.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 May 2020 18:35:25 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Andy Lutomirski Mime-Version: 1.0 (1.0) Subject: Re: [PATCH v10 01/26] Documentation/x86: Add CET description Date: Mon, 18 May 2020 18:35:21 -0700 Message-Id: <58319765-891D-44B9-AF18-64492B01FF36@amacapital.net> References: <2eb98637-bd2d-dda6-7729-f06ea84256ca@intel.com> Cc: Yu-cheng Yu , x86@kernel.org, "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Arnd Bergmann , Andy Lutomirski , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , "H.J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , "Ravi V. Shankar" , Vedvyas Shanbhogue , Dave Martin , Weijiang Yang In-Reply-To: <2eb98637-bd2d-dda6-7729-f06ea84256ca@intel.com> To: Dave Hansen X-Mailer: iPhone Mail (17E262) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On May 18, 2020, at 5:38 PM, Dave Hansen wrote: >=20 > =EF=BB=BFOn 5/18/20 4:47 PM, Yu-cheng Yu wrote: >>> On Fri, 2020-05-15 at 19:53 -0700, Yu-cheng Yu wrote: >>> On Fri, 2020-05-15 at 16:56 -0700, Dave Hansen wrote: >>>> On 5/15/20 4:29 PM, Yu-cheng Yu wrote: >>>>> [...] >>>>> I have run them with CET enabled. All of them pass, except for the fo= llowing: >>>>> Sigreturn from 64-bit to 32-bit fails, because shadow stack is at a 64= -bit >>>>> address. This is understandable. >>>> [...] >>>> One a separate topic: You ran the selftests and one failed. This is a >>>> *MASSIVE* warning sign. It should minimally be described in your cover= >>>> letter, and accompanied by a fix to the test case. It is absolutely >>>> unacceptable to introduce a kernel feature that causes a test to fail. >>>> You must either fix your kernel feature or you fix the test. >>>>=20 >>>> This code can not be accepted until this selftests issue is rectified. >> The x86/sigreturn test constructs 32-bit ldt entries, and does sigreturn f= rom >> 64-bit to 32-bit context. We do not have a way to construct a static 32-= bit >> shadow stack. >=20 > Why? What's the limiting factor? Hardware architecture? Something in > the kernel? >=20 >> Why do we want that? I think we can simply run the test with CET >> disabled. >=20 > The sadistic parts of selftests/x86 come from real bugs. Either bugs > where the kernel fell over, or where behavior changed that broke apps. > I'd suggest doing some research on where that particular test case came > from. Find the author of the test, look at the changelogs. >=20 > If this is something that a real app does, this is a problem. If it's a > sadistic test that Andy L added because it was an attack vector against > the entry code, it's a different story. There are quite a few tests that do these horrible things in there. IN my pe= rsonal opinion, sigreturn.c is one of the most important tests we have =E2=80= =94 it does every horrible thing to the entry code that I thought of and tha= t I could come up with a way of doing. We have been saved from regressing m= any times by these tests. CET, and especially the CPL0 version of CET, is i= ts own set of entry horror, and we need to keep these tests working. I assume the basic issue is that we call raise(), the context magically chan= ges to 32-bit, but SSP has a 64-bit value, and horrors happen. So I think t= wo things need to happen: 1. Someone needs to document what happens when IRET tries to put a 64-bit va= lue into SSP but CS is compat. Because Intel has plenty of history of doing c= olossally broken things here. IOW you could easily be hitting a hardware des= ign problem, not a software issue per se. 2. The test needs to work. Assuming the hardware doesn=E2=80=99t do somethin= g utterly broken, either the 32-bit code needs to be adjusted to avoid any C= ALL or RET, or you need to write a little raise_on_32bit_shstk() func that switc= hes to an SSP that fits in 32 bits, calls raise(), and switches back. =46rom= memory, I didn=E2=80=99t think there was a CALl or RET, so I=E2=80=99m gues= sing that SSP is getting truncated when we round trip through CPL3 compat mo= de and the result is that the kernel invoked the signal handler with the wro= ng SSP. Whoops. >=20 > I don't personally know the background, but the changelogs can help you > find the person that does.