Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp6430330ybx; Mon, 11 Nov 2019 09:01:54 -0800 (PST) X-Google-Smtp-Source: APXvYqwDPTXekAOHIi5DbMnfKMQG8ZbHf9GzlGrxbDEe+eoQLQ059y+hlxD6+mjyaYEr4KWGuoLm X-Received: by 2002:aa7:d0c1:: with SMTP id u1mr27463518edo.27.1573491714377; Mon, 11 Nov 2019 09:01:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573491714; cv=none; d=google.com; s=arc-20160816; b=zcTRtMWHBqnmzh9Tz+IVvTCc+ghKcV6Xzr3Z1o1byaCtM5b2zalnJJdu2cbECWVsPC U98uLa1EJwwkuyMJdzPE/RI/JdjFk+AXjPvMdITuWe4DCQwjL3ksqtEnyjDAPitrYlER phPMlDPyU1nQiXhOJvGf+QJXlpXdqKKcfe4xb5GvboHz1uOTCzdCI3R1WUzwjC1rmOYl oEWG9CS77l+LsApm6kjC4py+KUq7thyNb5UBt1aiZLFtgC5IhW8uBrKGAhhsoJ8Mq0FE gA7pPMHXlHTpOEDPvq++BiMUoHSrIDGVuJY5ihNinR/bW5aC68JP5isQGJPZS0ze/fVO M00Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=F4KZXMjks7vY7KcGacjQlgMF50Y6oDyGU0VkwIem05c=; b=OcJojTtpJ0WzYeGNxeDlIRHT4E/cv9+ECMnVPhz7VGjLLYhDo+BTxorCxdy85w2Iuu nRreQ2LlMdnl6o3vemYzX3C+4dEQyBUAux0yWm3geMvHOc9TmBLzZh6tdsPO+yrFegeA P0DKO74Fpd3CgKJrm7PujclNEe3baQXHfksM8No64UA03rrc1lGE0R8oD6fTnnbJcM5F WvHI0dSwMHFN1w+tqjFHxwufd0TopgU8ieZetxClRuWTVsJIZcZjCc1NmRbfNM7XR2Bp ogLIEDa2Ezmc5gDDO1yf15zSvPUSMg5iHoeXNVVP/61kZTAbvVYldqVnaV+jhHP+tEdd Qesg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y3si10516225edv.423.2019.11.11.09.01.30; Mon, 11 Nov 2019 09:01:54 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727134AbfKKQ60 (ORCPT + 99 others); Mon, 11 Nov 2019 11:58:26 -0500 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:39040 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727027AbfKKQ6Z (ORCPT ); Mon, 11 Nov 2019 11:58:25 -0500 Received: from callcc.thunk.org (guestnat-104-133-0-98.corp.google.com [104.133.0.98] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xABGw1ir031439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Nov 2019 11:58:02 -0500 Received: by callcc.thunk.org (Postfix, from userid 15806) id C0DC94202FD; Mon, 11 Nov 2019 11:58:00 -0500 (EST) Date: Mon, 11 Nov 2019 11:58:00 -0500 From: "Theodore Y. Ts'o" To: Jann Horn Cc: "Michael Kerrisk (man-pages)" , Christian Brauner , Florian Weimer , Christian Brauner , lkml , linux-man , Kees Cook , Oleg Nesterov , Arnd Bergmann , David Howells , Pavel Emelyanov , Andrew Morton , Adrian Reber , Andrei Vagin , Linux API , Ingo Molnar Subject: Re: For review: documentation of clone3() system call Message-ID: <20191111165800.GD7017@mit.edu> References: <20191107151941.dw4gtul5lrtax4se@wittgenstein> <2eb2ab4c-b177-29aa-cdc4-420b24cfd7b3@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 11, 2019 at 03:55:35PM +0100, Jann Horn wrote: > Not on Linux, but on OpenBSD, they do use MAP_STACK now AFAIK; this > was announced here: > . > Basically they periodically check whether the userspace stack pointer > points into a MAP_STACK region, and if not, they kill the process. So > even if it's a no-op on Linux... Hmm, is that something we should do in Linux? Even if we only check on syscall entry, which should be pretty inexpensive, it seems like it would be very effective in protecting various ROP techniques. - Ted