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=-8.6 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 84006C433E1 for ; Mon, 22 Jun 2020 19:01:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3B3D620768 for ; Mon, 22 Jun 2020 19:01:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="qi30Gs6I" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3B3D620768 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8F50D6B0008; Mon, 22 Jun 2020 15:01:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8AC766B0025; Mon, 22 Jun 2020 15:01:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7440B6B0026; Mon, 22 Jun 2020 15:01:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0245.hostedemail.com [216.40.44.245]) by kanga.kvack.org (Postfix) with ESMTP id 5A34A6B0008 for ; Mon, 22 Jun 2020 15:01:34 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 1E9F2211A9 for ; Mon, 22 Jun 2020 19:01:34 +0000 (UTC) X-FDA: 76957766508.12.glove37_1b0563b26e35 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin12.hostedemail.com (Postfix) with ESMTP id 354321863B4DA for ; Mon, 22 Jun 2020 19:01:02 +0000 (UTC) X-HE-Tag: glove37_1b0563b26e35 X-Filterd-Recvd-Size: 8201 Received: from mail-vs1-f67.google.com (mail-vs1-f67.google.com [209.85.217.67]) by imf41.hostedemail.com (Postfix) with ESMTP for ; Mon, 22 Jun 2020 19:01:01 +0000 (UTC) Received: by mail-vs1-f67.google.com with SMTP id m62so2380223vsd.4 for ; Mon, 22 Jun 2020 12:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=f/64wMp0V9meZEtKgaDR20F6s2d5MyfXMXxe7Mp6vXQ=; b=qi30Gs6Ir6O5NjA3TAb1E3BACdlzOgEXtHLV5n1JbpUFDebrCiDjm/zA1dgR+IYLZi 8vudaKN2OAMa9yC4zca10vWX/rSZ970qTXiW9hJPS6CJXYyloKRlO+DRTXQkiwNYFyvK FvK8vZppwmXSOgPfhuhcuptIIjSs/3t3bakmWiTelSzswozYjinqwQB9N6V0YheiHW7L QDZNZ32GL1iPl3XlhFH7wR31pv3ypoSKTUNjkVMW/jGPyodY62qio7MAfdbwe5pVpgKp eohJ9Sua6WEAKVMGmSByHGYIqgiTuorjRgs152VZFGPck8DdjTfIQ4LG8NP9hbeBH38U JcAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=f/64wMp0V9meZEtKgaDR20F6s2d5MyfXMXxe7Mp6vXQ=; b=tpt+pjOBsypvZHHRXv47r7/MMCAFmjoiz1tfYwiBSeKwxoOzfR6aROvS6D2PvWcYzZ UP+Mrf8uKPCEC9YwEGqkT98tXwzROE2dxyNrgyxK+rJsZ6OgR+TKLnPwYa/uSSkfyKzb WTUdtEpYPbAspIWS5CJpwNP8afNg5daTGIhc04ytqQvN6Me+7h84I23eM7NwAQRosGD1 cqi6zyRn1l4tQcqW3RGJbb/f3QA7+rJoCJHddLof9UHLJ04jj6MjOzS+sH/SAqArqIGh z3ZFt/vBkTnCczOy8QdOXIeaqgUC825HJJo+YugXDZKnKWErOPbd6okCDPt49EyfP/iu osug== X-Gm-Message-State: AOAM533YlaRMUdwqGxEKFt1hLPfnteYSy9vbn1HMdJ81JWs/VUFpqqy8 Ut/To7Ayf6WBjTNovn6zJwBw3fP3kTOK+iC/b7zObQ== X-Google-Smtp-Source: ABdhPJyW0K87CHnldkSTFwRFf5MB1bwDtF64tqTcDCXikcxkB3CPil9kvucAAh6TuvehsGzdKWLc/l8rYSOfG1vkAfk= X-Received: by 2002:a67:79cf:: with SMTP id u198mr17465862vsc.240.1592852460665; Mon, 22 Jun 2020 12:01:00 -0700 (PDT) MIME-Version: 1.0 References: <20191211184027.20130-1-catalin.marinas@arm.com> <20191211184027.20130-21-catalin.marinas@arm.com> <20200622171716.GC10226@gaia> In-Reply-To: <20200622171716.GC10226@gaia> From: Peter Collingbourne Date: Mon, 22 Jun 2020 12:00:48 -0700 Message-ID: Subject: Re: [PATCH 20/22] arm64: mte: Allow user control of the excluded tags via prctl() To: Catalin Marinas Cc: Kevin Brodsky , Linux ARM , Will Deacon , Marc Zyngier , Vincenzo Frascino , Szabolcs Nagy , Richard Earnshaw , Andrey Konovalov , linux-mm@kvack.org, linux-arch@vger.kernel.org, Branislav Rankov , Dave P Martin Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 354321863B4DA X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Jun 22, 2020 at 10:17 AM Catalin Marinas wrote: > > Hi Peter, > > Revisiting the gcr_excl vs gcr_incl decision, so reviving an old thread. > > On Mon, Dec 16, 2019 at 09:30:36AM -0800, Peter Collingbourne wrote: > > On Mon, Dec 16, 2019 at 6:20 AM Kevin Brodsky wrote: > > > In this patch, the default exclusion mask remains 0 (i.e. all tags can be generated). > > > After some more discussions, Branislav and I think that it would be better to start > > > with the reverse, i.e. all tags but 0 excluded (mask = 0xfe or 0xff). > > > > > > This should simplify the MTE setup in the early C runtime quite a bit. Indeed, if all > > > tags can be generated, doing any heap or stack tagging before the > > > PR_SET_TAGGED_ADDR_CTRL prctl() is issued can cause problems, notably because tagged > > > addresses could end up being passed to syscalls. Conversely, if IRG and ADDG never > > > set the top byte by default, then tagging operations should be no-ops until the > > > prctl() is issued. This would be particularly useful given that it may not be > > > straightforward for the C runtime to issue the prctl() before doing anything else. > > > > > > Additionally, since the default tag checking mode is PR_MTE_TCF_NONE, it would make > > > perfect sense not to generate tags by default. > > > > This would indeed allow the early C runtime startup code to pass > > tagged addresses to syscalls, > > I guess you meant that early C runtime code won't get tagged stack > addresses, hence they can be passed to syscalls. Prior to the prctl(), > the kernel doesn't accept tagged addresses anyway. Right. > > but I don't think it would entirely free > > the code from the burden of worrying about stack tagging. Either way, > > any stack frames that are active at the point when the prctl() is > > issued would need to be compiled without stack tagging, because > > otherwise those stack frames may use ADDG to rematerialize a stack > > object address, which may produce a different address post-prctl. > > If you want to guarantee that ADDG always returns tag 0, I guess that's > only possible with a default exclude mask of 0xffff (or if you are > careful enough with the start tag and offset passed). > > > Setting the exclude mask to 0xffff would at least make it more likely > > for this problem to be detected, though. > > I thought it would be detected if we didn't have a 0xffff default > exclude mask. With only tag 0 generated, any such problem could be > hidden. I don't think that's the case, as long as you aren't using 0 as a catch-all tag. Imagine that you have some hypothetical startup code that looks like this: void init() { bool called_prctl = false; prctl(PR_SET_TAGGED_ADDR_CTRL, ...); // effect is to change GCR_EL1.Excl from 0xffff to 1 called_prctl = true; } This may be compiled as something like (well, a real compiler wouldn't compile it like this but rather use sp-relative stores or eliminate the dead stores entirely, but imagine that the stores to called_prctl are obfuscated somehow, e.g. in another translation unit): sub x19, sp, #16 irg x19, x19 // compute a tag base for the function addg x0, x19, #0, #1 // add tag offset for "called_prctl" stzg x0, [x0] bl prctl addg x0, x19, #0, #1 // rematerialize "called_prctl" address mov w1, #1 strb w1, [x0] ret The first addg will materialize a tag of 0 due to the default Excl value, so the stzg will set the memory tag to 0. However, the second addg will materialize a tag of 1 because of the new Excl value, which will result in a tag fault in the strb instruction. This problem is less likely to be detected if we transition Excl from 0 to 1. It will only be detected in the case where the irg instruction produces a tag of 0xf, which would be incremented to 0 by the first addg but to 1 by the second one. > > If we change the default in this way, maybe it would be worth > > considering flipping the meaning of the tag mask and have it be a mask > > of tags to allow. That would be consistent with the existing behaviour > > where userspace sets bits in tagged_addr_ctrl in order to enable > > tagging features. > > The first question is whether the C runtime requires a default > GCR_EL1.Excl mask of 0xffff (or 0xfffe) so that IRG, ADDG, SUBG always > generate tag 0. If the runtime is fine with a default exclude mask of 0, > I'm tempted to go back to an exclude mask for prctl(). > > (to me it feels more natural to use an exclude mask as it matches the > ARM ARM definition but maybe I stare too much at the hardware specs ;)) I think that would be fine with me. With the transition from 0 to 1 the above problem would still be detected, but only 1/16 of the time. But if the problem exists in the early startup code which will be executed many times during a typical system boot, it makes it likely that the problem will be detected eventually. Peter