Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp431494pxb; Sat, 6 Mar 2021 04:37:36 -0800 (PST) X-Google-Smtp-Source: ABdhPJxggYPyA/JxFORBVlVTBhyW9bbhep+yoSD1YB1baeYFjR7BcPw8z4VMOLHuRtML6a07qAGn X-Received: by 2002:a17:906:1907:: with SMTP id a7mr6882191eje.142.1615034256593; Sat, 06 Mar 2021 04:37:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615034256; cv=none; d=google.com; s=arc-20160816; b=NMqwpBAueBcuigcC+dbY9aolJ9hx+E+jXm1nr/vsrjn5UTHhKxYnvAKDWa1eHv/fMq 44/asQldUKwzegXjBSvIjUg3m1+bAzeHB6XBJvE8MoUvZkySxAhz4v4oBn2kxNliVfdG geUPHOylzLHDO3nNuedKD/JKJBkdVxJnczcz1DlOPlNafyOKK9QCkPpXuVREVIxbBFJh AmwMOYWIZe+UL+HWQlDkVJolDzSWCzVpeTl+zqudobKsncmPxlwmanc3+xKritMqhrQh OGyWf8ul1HqvDqONEqn1IOAOJwgpP7vRxTrEd0qfSJJRYjn74qqcCqUWmg077/in2VJ0 8bBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=JRTQ//F7vNrpXNh19Edx5ubUS+rURU5261q44/OgIzo=; b=z/vh+oQlANIoMCtmgSBG/xN8Ac7vHOYrUPVJi1O7s+WltKUCd0zBWLOuldOHfgAdpC cErMFV48bt6qj3Xj2swwDm5dnv3IjYKWeggF5j0gtqfPdd1MenVxMjrcQ07Tqw5QRuME +DI0Q7N3CVtl30oGoZ7+PK3KN2gXq/I+4+tNaLokZXPb5Ni2yCmJS0tuXCgFsJ79Cz77 A3lFOZQo6yTYeIuEecUOhBs5UZf5V25w9I5ue7Q6fJLrChZj7jpm/A6hSvgvbzR4dXhN Qyxmca9u3Rf5WNxJs+VClxuWsIl82bQj/y7QkYVRkkIFvDpo+MqG5Or5tRsky2qyvPxn Zk8A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=KvukWuCf; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e2si3434312edl.307.2021.03.06.04.37.14; Sat, 06 Mar 2021 04:37:36 -0800 (PST) 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=@linaro.org header.s=google header.b=KvukWuCf; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230242AbhCFM2c (ORCPT + 99 others); Sat, 6 Mar 2021 07:28:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34288 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230259AbhCFM2H (ORCPT ); Sat, 6 Mar 2021 07:28:07 -0500 Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2E224C06175F for ; Sat, 6 Mar 2021 04:28:07 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id p21so10530271lfu.11 for ; Sat, 06 Mar 2021 04:28:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JRTQ//F7vNrpXNh19Edx5ubUS+rURU5261q44/OgIzo=; b=KvukWuCfw83vo46oTWeRvFRZJgMeXNa9R0A/STP7d8ctuY79MRLKWQhVOxJJIqoCYX tMH6Q/wxfEi7I7xqcQlIkgsmSiZ0CdG9/v9qWJ4nLwDqK+O1I5nBWRZG9N1bsGk40V3a +SEg3EO45uAs7SODjiHGH7Z0PtjnAflKuDcz0D//DOA/Mttjxb8uHpeVW1JnfajBBktZ 9cBU6cMH3nRcJE2Cnb5nJJmCA0ciQyBDxNBsgGuJSLCSBWmeXMyy8EE/7PxTnV5cQZFs 8DOYjK+SXog/ZIYmXtUBNTRuUa1Os82J1UA6imBqvE8XasbNntNtFLazG2jCjPY9x++h 0KaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JRTQ//F7vNrpXNh19Edx5ubUS+rURU5261q44/OgIzo=; b=LVoHP9IY8MIX3g4HicoKxpqff0QsEkfwt3XBBiFTi8h+1LYRzc0+7twlQIGGS61/R5 SbKv3dVFVEPNwpYinWSoaYBv7Oy7RrMEmZ/iWWZDV7DbFNccUYjXYb1gF3QJz5njfgI3 JH1IMzodHcP3Hor1QOiQKeOCyujDBAf/UxG40vUjxyn0bLpD6sCZHpkdy/+zy9PMZzKz rkzhuz4IbVZtlKK7qGj4LKQMHa0jIdIrdzBCmvuiF6qXYvt/eGs27KRDOw3PC7SQJEZg Pr7wcJO8RH9o8w2GawzlUgKhSxXNKCegmPx7RrLmPhBlqQ+MR8fPQFdJyWC0xul+ozpp qs3Q== X-Gm-Message-State: AOAM5311tDMIwHu3Y8w8aN6wuwEiypx0NKLWFmQjBFI8dRiR1CCzcVI0 V98HKip5gwyvonO9PX7E+TKOIXGq5OUjvEVIP7UK1Q== X-Received: by 2002:ac2:4d95:: with SMTP id g21mr9045702lfe.29.1615033685580; Sat, 06 Mar 2021 04:28:05 -0800 (PST) MIME-Version: 1.0 References: <20210223023542.2287529-1-jiancai@google.com> <20210305005327.405365-1-jiancai@google.com> <20210305095256.GA22536@willie-the-truck> In-Reply-To: <20210305095256.GA22536@willie-the-truck> From: Linus Walleij Date: Sat, 6 Mar 2021 13:27:54 +0100 Message-ID: Subject: Re: [PATCH v6] ARM: Implement SLS mitigation To: Will Deacon Cc: Jian Cai , Nick Desaulniers , Manoj Gupta , Luis Lozano , clang-built-linux , Nathan Chancellor , David Laight , Russell King , Russell King , Catalin Marinas , James Morris , "Serge E. Hallyn" , Arnd Bergmann , Masahiro Yamada , Kees Cook , =?UTF-8?Q?Andreas_F=C3=A4rber?= , Daniel Palmer , Ard Biesheuvel , Ingo Molnar , Vladimir Murzin , Marc Zyngier , Andrew Morton , Mike Rapoport , =?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= , Mark Rutland , David Brazdil , Joey Gouly , James Morse , Linux ARM , "linux-kernel@vger.kernel.org" , linux-security-module@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 5, 2021 at 10:53 AM Will Deacon wrote: > I still don't see why SLS is worth a compiler mitigation which will affect > all CPUs that run the kernel binary, but Spectre-v1 is not. In other words, > the big thing missing from this is a justification as to why SLS is a > problem worth working around for general C code. I might be on the Dunning Kruger-scale of a little knowledge is dangerous here, but AFAICT it is because it is mitigating all branches that result from the compilation. I think the people who devised this approach didn't think about the kernel problem per se but about "any code". They would have to go back to the compilers, have them introduce a marker instead for each branch or return, and then emit symbols that the kernel can run-time patch to mitigate the vulnerability. Something like that. (I guess.) Notice that these symbols/pointers would first have a footprint impact, though maybe they could be discarded if not applicable. The patch says: It inserts speculation barrier sequences (SB or DSB+ISB depending on the target architecture) after RET and BR, and replacing BLR with BL+BR sequence. How would you do that at runtime? If you slot in NOPs around the branch for mitigating, there will still be impact. If you want to make the code look the same unless vulnerable, you would have to patch the branch with a branch to another place to do the barriers... that patched branch in turn could be speculated? I feel stupid here. But I guess someone could come up with something? So instead of a simple straight-forward solution that becomes a really complicated awkward solution that generate a few thousand more man-hours and delays the mitigations. So I understand if the authors would want to try the simple approach first. It may however be our job to say "no, go do the really complicated thing", I guess that is what you're saying. :) Yours, Linus Walleij