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 X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 84B30C433DF for ; Tue, 28 Jul 2020 20:01:25 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4C9E22065C for ; Tue, 28 Jul 2020 20:01:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="I0xSo06J" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4C9E22065C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=IQTeXgx348d9CnzmsncE4ToFoPvZv/ou4gbWcxaAeyU=; b=I0xSo06JeAmU6v2RC6yXRlbVG DlUccfbKiTdrdlqXPrShjd6FrIaQeJ3++WHmjqTaj5DM9Ojoa20n+9hDsYwKBQAQs6DzBFCvdRE4u TaQpDMBnGC5t3WQ5l8jR4N/2fp9fxV93WDX+CbUnyYQXuB969PxEvhObCK+tneAG7sw9IKoyiTjJe 8zBe3V2NEuB02+BAjwuJ/bX4huxYHCEeE57EcJPprHb/FNTrzZ4eTp7MREvKuzlJUyOwdeNeMbGh7 Mos+aMoS2TpM6W1O0zjyL3HCCSasf18VAmxIqgBMIb4OiD1ssrZN5shvKWvonICiVlPM8b0dwslpp VYI4H0bBA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k0Vle-0003XP-2U; Tue, 28 Jul 2020 20:00:06 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k0Vlb-0003We-6t for linux-arm-kernel@lists.infradead.org; Tue, 28 Jul 2020 20:00:04 +0000 Received: from gaia (unknown [95.146.230.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 8D1352070A; Tue, 28 Jul 2020 20:00:00 +0000 (UTC) Date: Tue, 28 Jul 2020 20:59:57 +0100 From: Catalin Marinas To: Szabolcs Nagy Subject: Re: [PATCH v7 29/29] arm64: mte: Add Memory Tagging Extension documentation Message-ID: <20200728195957.GA31698@gaia> References: <20200715170844.30064-1-catalin.marinas@arm.com> <20200715170844.30064-30-catalin.marinas@arm.com> <20200727163634.GO7127@arm.com> <20200728110758.GA21941@arm.com> <20200728145350.GR7127@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200728145350.GR7127@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200728_160003_357527_E9CD43F4 X-CRM114-Status: GOOD ( 30.14 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arch@vger.kernel.org, nd@arm.com, Will Deacon , Andrey Konovalov , Kevin Brodsky , linux-mm@kvack.org, Andrew Morton , Vincenzo Frascino , Peter Collingbourne , Dave Martin , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Jul 28, 2020 at 03:53:51PM +0100, Szabolcs Nagy wrote: > The 07/28/2020 12:08, Dave Martin wrote: > > On Mon, Jul 27, 2020 at 05:36:35PM +0100, Szabolcs Nagy wrote: > > > a solution is to introduce a flag like SECCOMP_FILTER_FLAG_TSYNC > > > that means the prctl is for all threads in the process not just > > > for the current one. however the exact semantics is not obvious > > > if there are inconsistent settings in different threads or user > > > code tries to use the prctl concurrently: first checking then > > > setting the mte state via separate prctl calls is racy. but if > > > the userspace contract for enabling mte limits who and when can > > > call the prctl then i think the simple sync flag approach works. > > > > > > (the sync flag should apply to all prctl settings: tagged addr > > > syscall abi, mte check fault mode, irg tag excludes. ideally it > > > would work for getting the process wide state and it would fail > > > in case of inconsistent settings.) > > > > If going down this route, perhaps we could have sets of settings: > > so for each setting we have a process-wide value and a per-thread > > value, with defines rules about how they combine. > > > > Since MTE is a debugging feature, we might be able to be less aggressive > > about synchronisation than in the SECCOMP case. > > separate process-wide and per-thread value > works for me and i expect most uses will > be process wide settings. The problem with the thread synchronisation is, unlike SECCOMP, that we need to update the SCTLR_EL1.TCF0 field across all the CPUs that may run threads of the current process. I haven't convinced myself that this is race-free without heavy locking. If we go for some heavy mechanism like stop_machine(), that opens the kernel to DoS attacks from user. Still investigating if something like membarrier() would be sufficient. SECCOMP gets away with this as it only needs to set some variable without IPI'ing the other CPUs. > i don't think mte is less of a security > feature than seccomp. Well, MTE is probabilistic, SECCOMP seems to be more precise ;). > if linux does not want to add a per process > setting then only libc will be able to opt-in > to mte and only at very early in the startup > process (before executing any user code that > may start threads). this is not out of question, > but i think it limits the usage and deployment > options. There is also the risk that we try to be too flexible at this stage without a real use-case. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel