Received: by 2002:a05:6a10:9e8c:0:0:0:0 with SMTP id y12csp201323pxx; Wed, 28 Oct 2020 02:35:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwtBJomxKiGfPL9xk45qjIePXsSFOYVaLjkz34JGnL8JugFDLrBCNNvxXFbNVOPBG6uZv4H X-Received: by 2002:a17:906:3146:: with SMTP id e6mr6296195eje.363.1603877733329; Wed, 28 Oct 2020 02:35:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603877733; cv=none; d=google.com; s=arc-20160816; b=jmQzC/l64TDJOfeWLfrRQ8lh//Wkf5LCfMty+iiXpn+CMVl5xf+9BLeiVKMqK7Pu6w FAQaFVSVRe6FWwkE6+sCPkaWO2fFP3Z8DSgUlnTADxgJeVG9QByQFEVcmjG5FAlYO1A9 D0fowGDnV/ap+71oMxTYMslt4PGyPYNcJqqf9cYhUhAXXpfifzy1WDdTiRCGU7b5cdST Z5ZjehOE7D1jfNQaxtBOC8iqWfIHGrKnWMDcUcIqEE3Ps2TmIOhQ7PjjEJMn6MvY88JV VsjkRKoYS5DDAKOLxt9ogkXicI54mh409L2Z1Vb7ugIDaTONwB68U6h5FLz3bA8J54eE V2WA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=IufjDjQub+Dwyey7d8tgnxZNddAPiwknKYBvIBAroNM=; b=NsYZofO33wfj58PQBP8oP+9enOjbqP4IefEyHOIckeaIU1jdwZft3Z6PkmQo84tAv6 v5ABOUBlu9pY0VRDm/geaUGp+SN4vbPcgSvYn4veFkUtuAzP83LxsINdjwLOY1I0ilFA OoPf+twk4XFLUudM0JrfJ2no4hhNmtYJD8PEBuGGejZrMXefNwvxbg2PL8GUcQaLT+nq TXhPC1lXvm3h9R+6Rpf7lSdf+C9CW79tpqsoF71+dwi3dy5y1+pXYlWiXFvapfsfRi47 qlc53vC5hLIwl2mrI7i9fEjbfj5KGIJcJKF3eeViJvGhQS1elF+gKFrvOoQFPB55JWo1 1XRg== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dk22si2709939edb.258.2020.10.28.02.35.11; Wed, 28 Oct 2020 02:35:33 -0700 (PDT) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758731AbgJ0OXN (ORCPT + 99 others); Tue, 27 Oct 2020 10:23:13 -0400 Received: from foss.arm.com ([217.140.110.172]:41606 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758711AbgJ0OWY (ORCPT ); Tue, 27 Oct 2020 10:22:24 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D98BC13D5; Tue, 27 Oct 2020 07:22:23 -0700 (PDT) Received: from arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 542CD3F719; Tue, 27 Oct 2020 07:22:22 -0700 (PDT) Date: Tue, 27 Oct 2020 14:22:19 +0000 From: Dave Martin To: Florian Weimer Cc: Dave Martin via Libc-alpha , Mark Rutland , systemd-devel@lists.freedesktop.org, Kees Cook , Catalin Marinas , Will Deacon , "linux-kernel@vger.kernel.org" , Jeremy Linton , Mark Brown , toiwoton@gmail.com, "linux-arm-kernel@lists.infradead.org" Subject: Re: BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures Message-ID: <20201027142218.GE27285@arm.com> References: <8584c14f-5c28-9d70-c054-7c78127d84ea@arm.com> <20201026162410.GB27285@arm.com> <87r1pl9brd.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87r1pl9brd.fsf@oldenburg2.str.redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 26, 2020 at 05:45:42PM +0100, Florian Weimer via Libc-alpha wrote: > * Dave Martin via Libc-alpha: > > > Would it now help to add something like: > > > > int mchangeprot(void *addr, size_t len, int old_flags, int new_flags) > > { > > int ret = -EINVAL; > > mmap_write_lock(current->mm); > > if (all vmas in [addr .. addr + len) have > > their mprotect flags set to old_flags) { > > > > ret = mprotect(addr, len, new_flags); > > } > > > > mmap_write_unlock(current->mm); > > return ret; > > } > > I suggested something similar as well. Ideally, the interface would > subsume pkey_mprotect, though, and have a separate flags argument from > the protection flags. But then we run into argument list length limits. > > Thanks, > Florian I suppose. Assuming that a syscall filter can inspect memory, we might be able to bundle arguments into a struct if necessary. [...] Cheers ---Dave