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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8AB2CC4332F for ; Tue, 7 Nov 2023 20:37:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C0E3A8D0056; Tue, 7 Nov 2023 15:37:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BBE0C8D0001; Tue, 7 Nov 2023 15:37:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A867C8D0056; Tue, 7 Nov 2023 15:37:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 951CB8D0001 for ; Tue, 7 Nov 2023 15:37:25 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 673D8160549 for ; Tue, 7 Nov 2023 20:37:25 +0000 (UTC) X-FDA: 81432318450.11.A9FF97D Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) by imf03.hostedemail.com (Postfix) with ESMTP id 9041C20013 for ; Tue, 7 Nov 2023 20:37:23 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=hiSHkq9K; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf03.hostedemail.com: domain of keescook@chromium.org designates 209.85.210.179 as permitted sender) smtp.mailfrom=keescook@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699389443; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=vaEivRGYQgWty+lkiDpJ6XgknaKLFgZ+tZbiPi4ULqE=; b=sGA3ci2azI3MoCrMBI3Uc0+GWCsFphmiGpPuEXN82YQpo6gbdQTkMP09J4RXUoz1S89uS8 Brb2OJRvquqr+YKfuX5WZ2MQClII/kURRe5kAoUO4tHadvbCfXe//EzFfV2EgNyuy+tlof IyvCNQREMl5hnqYo+PW30wJMI527F6E= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=hiSHkq9K; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf03.hostedemail.com: domain of keescook@chromium.org designates 209.85.210.179 as permitted sender) smtp.mailfrom=keescook@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699389443; a=rsa-sha256; cv=none; b=SPM8uUTMSrwPraeR1Ds3JLogRj0dctkjTQS5CgvSFjpjhoeH4l32KndYBWN+wM8mQdaHUU QlNKZ87wSaXuuBol+uheWYWQUP9wkfl5GyHuY7/E8KleegMT0oDvUsg7vcScGLx3M4okOL g0jCfNcgXONl+3qgpwbRum99G87Yg0w= Received: by mail-pf1-f179.google.com with SMTP id d2e1a72fcca58-6b709048d8eso5237410b3a.2 for ; Tue, 07 Nov 2023 12:37:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1699389442; x=1699994242; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=vaEivRGYQgWty+lkiDpJ6XgknaKLFgZ+tZbiPi4ULqE=; b=hiSHkq9KcZvaZ2ge2pcc8VTvTZXl+Nb/a4uQwKj4BweYa8uuIJOSzHcltpzZCGZIdG NZUM/bXuNGfH+MyL6RJcTieYSTRB/lBJaO7cq15PLhjd3wXakr6hnKvUw2ZZQLPuKgNc Hv/Mb6NGgljrN+kFw3pGU2Ws+j69D8nBhK+VU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699389442; x=1699994242; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=vaEivRGYQgWty+lkiDpJ6XgknaKLFgZ+tZbiPi4ULqE=; b=jgeCKOZoh3qL6p0JHd6e1x6EWZ0cpnWpLWf6mH3yOzZHfCT0ESohyvMRRapYsopv7D 4b1Wfo2vWlYzqYIsDRsKFQfVvF4tfSClWPezWZWKaSpZmDqPA3dZv/hxpARJuVm2KduA pHETacILdMdoUclSSjHEjJqaBfgyuxjspZprAQBZcxo8rXU1BLV27qm5uHxsKO4k1lXN NK0F9AvecC6DYloFBU2KRL1h6vUATjTVGEex0BUTPSkLLpwKiuTeb/mnd0/VBENdHeg3 dKAIaSdnjafVqQdny137LjamCmtdAeKqfmi4KNYC4NEIU6SJSASemsWXG5JNvi65Zx2n JzEw== X-Gm-Message-State: AOJu0YyfQgyjyAPrrialjFJjQWrAFgCYxMan14VTbuA9tar4IOw3PY3S 0exE421/7Efi2vmbMuSvmUsxZA== X-Google-Smtp-Source: AGHT+IE+1gfPggREs0LKHC4iwp9aPM5a+Hkng8JZERX1SSzCn3TpDE0hw34nJeMnxNX73PXMAinopw== X-Received: by 2002:a05:6a21:9988:b0:181:98d6:6afd with SMTP id ve8-20020a056a21998800b0018198d66afdmr126141pzb.41.1699389442297; Tue, 07 Nov 2023 12:37:22 -0800 (PST) Received: from www.outflux.net (198-0-35-241-static.hfc.comcastbusiness.net. [198.0.35.241]) by smtp.gmail.com with ESMTPSA id a8-20020a17090a740800b0026801e06ac1sm219553pjg.30.2023.11.07.12.37.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Nov 2023 12:37:21 -0800 (PST) Date: Tue, 7 Nov 2023 12:37:21 -0800 From: Kees Cook To: Josh Triplett Cc: Eric Biederman , Alexander Viro , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fs/exec.c: Add fast path for ENOENT on PATH search before allocating mm Message-ID: <202311071236.71CDE62@keescook> References: <5c7333ea4bec2fad1b47a8fa2db7c31e4ffc4f14.1663334978.git.josh@joshtriplett.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5c7333ea4bec2fad1b47a8fa2db7c31e4ffc4f14.1663334978.git.josh@joshtriplett.org> X-Rspamd-Queue-Id: 9041C20013 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: i5kedktn7hu5kty7nk76if3as9k46gig X-HE-Tag: 1699389443-840282 X-HE-Meta: U2FsdGVkX1+JAKEbYJnOI6IUrgnBB3WuI4O0EQloK7ng7haBD08rYO1qjKk/u8YhNuslbS7+0pdNkOvyTvzTwPEFVzK8a2FQO3Y/OxDkEmbHXmw3HQ/Fqa33fE6TElviHyI0nsaBamRr9K7qGA4yWw2dZjeRznwpACayYZnFJbIMt17rA+gQkjNh+LtDHLfPKZJjyaCBJ0nSlzWC5i73IbVeHBiSbaJUyDOfTY6YJsVHTadxupDgYCCfhNKf9NMs1XAdMSpk8J1SBC51n50V5EJN/qVWIaVtgXht9Y2HrPtttJd62xODjv+WHo6phuWIMrVRpwhDJYRPXlhrMmxqXO09PFaV6BuhgmzBcs4qKuIA+bZYHBjleNBLm05KKIB74LF9oKFSq/0fRR0448w09pgH8+GnWFGpD5lLODeQpVLbUonGq2CBbP9EWMzhCgTvZvcG173qkeU+Az2VwUPkLAIifQ8kcctf3VUK70Bkuqf7WnBZLO+6sXJHzS9Mxaa4mHftyUCzxjP/8TtE3Ugj3xc7YQe1Jk+sCpNAEHOzQAFtDxI0BV/ora69m99pB1PoGiLq6dDhswTkEKi0V/noqcRW1Wm9addC56Pcf+7DrZpebby1L6cGtkDBQjcGJkI9jGdeOlKtXKxOLqdlmdLxvHXYhanNosWesBcs2F98L8N3DHzWVcCEgunbZR4+RQAgMHVaiQRsD2DJtbm58AFqMD+jJNiZ98Nx+JnbabxeugttMiM4wgO7HEacOZznkyqnsSztmCkvEyxV/5L+Xx/dy1cpWKY3YP4Aa76t7dqA6xUrevdIG6ucP4R8/fG3lcGREMQtfU6b4ioyoYZvlyan5vZYw1StCV1BLjYLx4sptY8NxJeYhQmZveG9+cvS6hAjxo9UA+N6vg9h+8AQRJdh3Q1i4yZqCfTqTU7rZyaIxkgsgLxB6XwSzplRxH8QHdF9gJo3wSPROrFiwd5xm+1 Mc1N/B8S 1yF6kEWyVSizVr8Sybd0pX+IgAwJmaSIG6Q8XS5D2nJYlhnV1D5lQfWIg8A6jY8kzz519IteEy3ZmS2gIsoEChdl4CVdhWTJxNvmQfx8+gXtP09r0Kuh3NOVSO8C8SrV6LfHKEJ4AEJT8VDB9smdDLhXynaVACL5XJTrubjHsFU1sZpCEUTZqKZ07VyuqqL7cCvp0KF5LmCRwpmHr0HnsQr8ptF4oZkvwThZlj3UYLUQVNmsHkWGod+wH2l0OdohbLNUPPlZA0FOQZU0TlEkxnY2UY2kAMw8UgtQgNEICFaLuZzY53dh6i/nClLapVj2WTg6Hl6730ZSzrRNKrUcRvWcx/cotuinicPqJqdL0VuftWi1jZQVrGPOa2O3WYJ22E+0YynyMZWHp+57+C2NIPTk92g== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Sep 16, 2022 at 02:41:30PM +0100, Josh Triplett wrote: > Currently, execve allocates an mm and parses argv and envp before > checking if the path exists. However, the common case of a $PATH search > may have several failed calls to exec before a single success. Do a > filename lookup for the purposes of returning ENOENT before doing more > expensive operations. > > This does not create a TOCTTOU race, because this can only happen if the > file didn't exist at some point during the exec call, and that point is > permitted to be when we did our lookup. > > To measure performance, I ran 2000 fork and execvpe calls with a > seven-element PATH in which the file was found in the seventh directory > (representative of the common case as /usr/bin is the seventh directory > on my $PATH), as well as 2000 fork and execve calls with an absolute > path to an existing binary. I recorded the minimum time for each, to > eliminate noise from context switches and similar. > > Without fast-path: > fork/execvpe: 49876ns > fork/execve: 32773ns > > With fast-path: > fork/execvpe: 36890ns > fork/execve: 32069ns > > The cost of the additional lookup seems to be in the noise for a > successful exec, but it provides a 26% improvement for the path search > case by speeding up the six failed execs. > > Signed-off-by: Josh Triplett > --- > > Discussed this at Plumbers with Kees Cook; turned out to be even more of > a win than anticipated. > > fs/exec.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/fs/exec.c b/fs/exec.c > index 9a5ca7b82bfc..fe786aeb2f1b 100644 > --- a/fs/exec.c > +++ b/fs/exec.c > @@ -1881,6 +1881,16 @@ static int do_execveat_common(int fd, struct filename *filename, > if (IS_ERR(filename)) > return PTR_ERR(filename); > > + /* Fast-path ENOENT for $PATH search failures, before we alloc an mm or > + * parse arguments. */ > + if (fd == AT_FDCWD && flags == 0 && filename->name[0] == '/') { > + struct path path; > + retval = filename_lookup(AT_FDCWD, filename, 0, &path, NULL); > + if (retval == -ENOENT) Oh, actually, I see the 0-day problem. This should be: if (retval < 0) > + goto out_ret; > + path_put(&path); Otherwise this put will happen for an non-successful lookup that wans't ENOENT. I've fixed this in my tree. -Kees > + } > + > /* > * We move the actual failure in case of RLIMIT_NPROC excess from > * set*uid() to execve() because too many poorly written programs > -- > 2.37.2 > -- Kees Cook