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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CA3BEC4332F for ; Thu, 13 Oct 2022 17:46:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229680AbiJMRqu (ORCPT ); Thu, 13 Oct 2022 13:46:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39750 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229751AbiJMRqr (ORCPT ); Thu, 13 Oct 2022 13:46:47 -0400 Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C8D9A144E2E for ; Thu, 13 Oct 2022 10:46:43 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id iv17so1664626wmb.4 for ; Thu, 13 Oct 2022 10:46:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8ev4pPnANTRpeGlWtdz4fwBlwIXvv8bPS1IfQVbJRl8=; b=spEOO6U76Nh6i2+6RoX9Spc8ZrWUfpMBxYdZg71DhbEAxdLbP3OZ0lxY94eUlOO1pk i/2p78lMKLurk9qO/g7dEC28Z+ovo4pr0ykuK/9l+jUciDL+RVNbU2FFSlwUzmJJWpJi 6n/1XZ/bR+uMlXdjyNGJgoejGPsh0E3kkFnJCiImPKr1thc28I3CysJL2AVoZ3b77zuP iSqg7yPPekTQ6qo03HSD5rzjLm8Th92dlmRc6Ei3QIjVrlY78jlFsP2aqAP6UwAquPLS 3ScNR52QTymv8NTo2dcKAvJPtm2LxJQKZePuwYnyjAZvhBEBou9f5vB0txfCJRDOTIR1 UEzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8ev4pPnANTRpeGlWtdz4fwBlwIXvv8bPS1IfQVbJRl8=; b=i23XniWSYBV85IaR/SEYQKBePVewoD1AjZkanul7UvL6yPvChku7IpcEU+GFSdeekc blTyRfqxs9G6K7g5NlHWDxSUwX18S+qpw6a2LeJhmz0NYqSVXp08mLfKPktjiPwbtjf+ lmJ98nFnZi/wEwa0hyC0+yHtnDjU0t1p8DlXzaBB2SWzJSNxYRZD71YUhvC+efnCsuWs pM/yYXou9uCpjNkRESImk9iK6r14Bvek7zzEoRMstvAdRtnH/9UWRxbV/8n1rL+qC4Er +KrBWaI5W4nzXgU0AZ32c6Dv1DnGp1nHBOce5QlsbaEkXZtF6PZ5hoYf+zf5zPXnndVJ yTew== X-Gm-Message-State: ACrzQf1aU5W85Gibwte/AmSEnuUuyBDVqCb4Icav1nwiIrq9miehcUF9 6o/SoBNKUVmP/DRDMx9xOxETytLX+MjULtpjJLjbzg== X-Google-Smtp-Source: AMsMyM5jTDHcnzM0bOBuCvnxWCxENWOdtk/sw+8edsqid0aaTs2MkW9UXd4iqx7XWudjfpF/TMUy0pZOq7ZpEIQYoxU= X-Received: by 2002:a05:600c:310b:b0:3b4:c618:180d with SMTP id g11-20020a05600c310b00b003b4c618180dmr705289wmo.25.1665683202009; Thu, 13 Oct 2022 10:46:42 -0700 (PDT) MIME-Version: 1.0 References: <20220921003120.209637-1-avagin@google.com> <20220921003120.209637-2-avagin@google.com> <00ffd40b257346d26dfc0f03d144ec71@ispras.ru> In-Reply-To: <00ffd40b257346d26dfc0f03d144ec71@ispras.ru> From: Andrei Vagin Date: Thu, 13 Oct 2022 10:46:30 -0700 Message-ID: Subject: Re: [PATCH 2/2] selftests/timens: add a test for vfork+exit To: Alexey Izbyshev Cc: Kees Cook , linux-kernel@vger.kernel.org, Andrei Vagin , Christian Brauner , Dmitry Safonov <0x7f454c46@gmail.com>, "Eric W. Biederman" , Florian Weimer Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Oct 9, 2022 at 9:10 AM Alexey Izbyshev wrote: > > On 2022-09-21 03:31, Andrei Vagin wrote: > > From: Andrei Vagin > > + if (pid == 0) { > > + char now_str[64]; > > + char *cargv[] = {"exec", now_str, NULL}; > > + char *cenv[] = {NULL}; > > + > > + // Check that we are still in the source timens. > > + if (check("child before exec", &now)) > > + return 1; > > I know this is just a test, but... > > Creating threads in a vfork()-child is quite dangerous (like most other > things that touch the libc state, which is shared with the parent > process). Here it works probably only because pthread_create() followed > by pthread_join() restores everything into more-or-less the original > state before returning control to the parent, but this is something that > libcs don't guarantee and that can break at any moment. > > Also, returning from a vfork()-child is explicitly forbidden by the > vfork() contract because the parent would then return to an invalid > stack frame that could be arbitrarily clobbered by code executed in the > child after main() returned. Moreover, if I'm not mistaken, on x86 with > Intel CET-enabled glibc (assuming the support for CET is ever merged > into the kernel) such return would cause the parent to always trap > because the shadow stack will become inconsistent with the normal stack. > Instead, _exit() should be used here... > Hi Alexey, You are right, it isn't a good idea to create threads from the vfork-ed process. Now, vfork isn't a special case in the kernel code, so I think we can just remove the check() call from here. I have sent an updated version of this patch, pls take a look at it. Thanks, Andrei