From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1F69AC433F5 for ; Wed, 13 Oct 2021 14:24:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 09BED610C8 for ; Wed, 13 Oct 2021 14:24:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236683AbhJMO0u (ORCPT ); Wed, 13 Oct 2021 10:26:50 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:44247 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237322AbhJMO0q (ORCPT ); Wed, 13 Oct 2021 10:26:46 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 19DEOXi9008637; Wed, 13 Oct 2021 16:24:33 +0200 Date: Wed, 13 Oct 2021 16:24:33 +0200 From: Willy Tarreau To: Borislav Petkov Cc: Ammar Faizi , Paul Walmsley , Palmer Dabbelt , Albert Ou , Linux Kernel Mailing List , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , x86@kernel.org, "H. Peter Anvin" , Michael Matz Subject: Re: [PATCH] tools/nolibc: x86: Remove `r8`, `r9` and `r10` from the clobber list Message-ID: <20211013142433.GB8557@1wt.eu> References: <20211012222311.578581-1-ammar.faizi@students.amikom.ac.id> <20211013125142.GD5485@1wt.eu> <20211013140723.GE5485@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 13, 2021 at 04:20:55PM +0200, Borislav Petkov wrote: > On Wed, Oct 13, 2021 at 04:07:23PM +0200, Willy Tarreau wrote: > > Yes I agree with the "potentially" here. If it can potentially be (i.e. > > the kernel is allowed by contract to later change the way it's currently > > done) then we have to save them even if it means lower code efficiency. > > > > If, however, the kernel performs such savings on purpose because it is > > willing to observe a stricter saving than the AMD64 ABI, we can follow > > it but only once it's written down somewhere that it is by contract and > > will not change. > > Right, and Micha noted that such a change to the document can be done. great. > And we're basically doing that registers restoring anyway, in POP_REGS. That's what I based my analysis on when I wanted to verify Ammar's finding. I would tend to think that if we're burning cycles popping plenty of registers it's probably for a reason, maybe at least a good one, which is that it's the only way to make sure we're not leaking internal kernel data! This is not a concern for kernel->kernel nor user->user calls but for user->kernel calls it definitely is one, and I don't think we could relax that series of pop without causing leaks anyway. Willy