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;
Date:   Mon, 26 Oct 2020 17:52:31 +0000
From:   Dave Martin <Dave.Martin@arm.com>
To:     Szabolcs Nagy <szabolcs.nagy@arm.com>
Cc:     Mark Rutland <mark.rutland@arm.com>,
        systemd-devel@lists.freedesktop.org,
        Kees Cook <keescook@chromium.org>,
        Catalin Marinas <Catalin.Marinas@arm.com>,
        Will Deacon <will.deacon@arm.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Jeremy Linton <jeremy.linton@arm.com>,
        Mark Brown <broonie@kernel.org>, toiwoton@gmail.com,
        libc-alpha@sourceware.org,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>
Subject: Re: BTI interaction between seccomp filters in systemd and glibc
 mprotect calls, causing service failures
Message-ID: <20201026175230.GC27285@arm.com>
References: <8584c14f-5c28-9d70-c054-7c78127d84ea@arm.com>
 <20201026162410.GB27285@arm.com>
 <20201026165755.GV3819@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20201026165755.GV3819@arm.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Precedence: bulk

On Mon, Oct 26, 2020 at 04:57:55PM +0000, Szabolcs Nagy via Libc-alpha wrote:
> The 10/26/2020 16:24, Dave Martin via Libc-alpha wrote:
> > Unrolling this discussion a bit, this problem comes from a few sources:
> > 
> > 1) systemd is trying to implement a policy that doesn't fit SECCOMP
> > syscall filtering very well.
> > 
> > 2) The program is trying to do something not expressible through the
> > syscall interface: really the intent is to set PROT_BTI on the page,
> > with no intent to set PROT_EXEC on any page that didn't already have it
> > set.
> > 
> > 
> > This limitation of mprotect() was known when I originally added PROT_BTI,
> > but at that time we weren't aware of a clear use case that would fail.
> > 
> > 
> > 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;
> > }
> 
> if more prot flags are introduced then the exact
> match for old_flags may be restrictive and currently
> there is no way to query these flags to figure out
> how to toggle one prot flag in a future proof way,
> so i don't think this solves the issue completely.

Ack -- I illustrated this model because it makes the seccomp filter's
job easy, but it does have limitations.

> i think we might need a new api, given that aarch64
> now has PROT_BTI and PROT_MTE while existing code
> expects RWX only, but i don't know what api is best.

An alternative option would be a call that sets / clears chosen
flags and leaves others unchanged.

The trouble with that is that the MDWX policy then becomes hard to
implement again.


But policies might be best set via another route, such as a prctl,
rather than being implemented completely in a seccomp filter.

Cheers
---Dave