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=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=unavailable 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 73A03C282CE for ; Wed, 22 May 2019 20:47:49 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 136D820821 for ; Wed, 22 May 2019 20:47:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="AhM+SoI8"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="Y8j7WD6z" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 136D820821 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-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=bombadil.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=eJCDkNRdb0NUMTQ6I4grz7YsMfV55DGVhHqFGRi6jAc=; b=AhM+SoI8nvrXav +UhIOj1AW3+bVq7b2dZjv84L/V87BCwaUN4H4iwSPdi9mdAgmGyYG5bCjnThYo1iTEALopsjXqaCC dcojGcMDa+/8eO8XH8cqPh1Eb54QBxTi4ljuXduIl2A1nndtdlNIpD4t2rmJj4CSgPkJDf1RvixJj Ol4mor9p9HB6kEoYELZc06aAgmKyanHlNTUMokZS2QrjrB/SLeT89qS0/jPCiYXoXx1MWnnDAG1eM RiRXdhaB7TrBW2rh0UXfM6A5eBa5oafeS+arHt2BV4VAFSFBIlDvpbqrXJ6dFEndd8Ol0CTva8Ttr ZZpK6EsyVXxFSRnSy/wg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hTY9G-0002QA-8U; Wed, 22 May 2019 20:47:42 +0000 Received: from mail-pl1-x641.google.com ([2607:f8b0:4864:20::641]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hTY9D-0002Pc-GF for linux-arm-kernel@lists.infradead.org; Wed, 22 May 2019 20:47:40 +0000 Received: by mail-pl1-x641.google.com with SMTP id go2so1626702plb.9 for ; Wed, 22 May 2019 13:47:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=zy3PazUIRm9Jc9PdJuB2u+ElFTk96lbYpo+oNBJZGCM=; b=Y8j7WD6zpcc/2sEpj8EY6NRT1Dc510C1spsir21/hkUeu4mUUaoDDgjLww0pivEwF/ z6iJ0+f+gBw8re6q5xM6Dar0lLD7YYS2gJO3KPMVbNBtZ3Id3RkPfmb6s3Yr3rdRIcuf rTPZw7otg9Z5O5b4Ojw+hEe7n4misMdps/iC8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=zy3PazUIRm9Jc9PdJuB2u+ElFTk96lbYpo+oNBJZGCM=; b=BXCbbKIP9jDQx4+y+4jmuv48CHF0JEP2LQNr1VcZd6US1LiHs4r/uh1H9tHfBT6drS L3x4lpHJt7jDecDPJ7MOAQTqS04X1hOgM/QCefDybuS/oLQHtVZeB1NY251jrT89iNp0 aL2vYp1DxnyfQfIZ9v9LQmsDoUhtQWJTjAuAoBkrSOsERLpP6MldKKu5NHIvchuIcoLb N5669vjIck7kYR7u1OUeEi7oPADk0X4WxRILp+jOMQa/APCTi1EbO2buul2pep4UIxyy REDFQl0cScaBnmsJP9mvUNoio+COmrs9dDCk/Tk6106djrHi3JMHJh0XF+QZBkd39RwL 0XSw== X-Gm-Message-State: APjAAAXTSdnE37w89Bpjnl08TA9+20OR+2UX4O1KX0JBOWqGJeoYwjLk wM4n98DV2QKHBP1P6j2r6z+Zxg== X-Google-Smtp-Source: APXvYqxzAX+RobICkloaWYce4rx4oMkBv2QD394+NKxfoEao6LHAAvOlkD0rcjglQVK68ClP6ctquQ== X-Received: by 2002:a17:902:15c5:: with SMTP id a5mr93624265plh.39.1558558058259; Wed, 22 May 2019 13:47:38 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id d13sm23312074pfh.113.2019.05.22.13.47.36 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 22 May 2019 13:47:37 -0700 (PDT) Date: Wed, 22 May 2019 13:47:36 -0700 From: Kees Cook To: Catalin Marinas Subject: Re: [PATCH v15 00/17] arm64: untag user pointers passed to the kernel Message-ID: <201905221316.865581CF@keescook> References: <20190517144931.GA56186@arrakis.emea.arm.com> <20190521182932.sm4vxweuwo5ermyd@mbp> <201905211633.6C0BF0C2@keescook> <20190522101110.m2stmpaj7seezveq@mbp> <20190522163527.rnnc6t4tll7tk5zw@mbp> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20190522163527.rnnc6t4tll7tk5zw@mbp> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190522_134739_543358_8F24321F X-CRM114-Status: GOOD ( 24.52 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , kvm@vger.kernel.org, Szabolcs Nagy , Will Deacon , dri-devel@lists.freedesktop.org, Linux Memory Management List , Khalid Aziz , "open list:KERNEL SELFTEST FRAMEWORK" , Vincenzo Frascino , Jacob Bramley , Leon Romanovsky , linux-rdma@vger.kernel.org, amd-gfx@lists.freedesktop.org, Dmitry Vyukov , Dave Martin , Evgenii Stepanov , linux-media@vger.kernel.org, Kevin Brodsky , Ruben Ayrapetyan , Andrey Konovalov , Ramana Radhakrishnan , Alex Williamson , Yishai Hadas , Mauro Carvalho Chehab , Linux ARM , Kostya Serebryany , Greg Kroah-Hartman , Felix Kuehling , LKML , Jens Wiklander , Lee Smith , Alexander Deucher , Andrew Morton , enh , Robin Murphy , Christian Koenig , Luc Van Oostenryck Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, May 22, 2019 at 05:35:27PM +0100, Catalin Marinas wrote: > The two hard requirements I have for supporting any new hardware feature > in Linux are (1) a single kernel image binary continues to run on old > hardware while making use of the new feature if available and (2) old > user space continues to run on new hardware while new user space can > take advantage of the new feature. Agreed! And I think the series meets these requirements, yes? > For MTE, we just can't enable it by default since there are applications > who use the top byte of a pointer and expect it to be ignored rather > than failing with a mismatched tag. Just think of a hwasan compiled > binary where TBI is expected to work and you try to run it with MTE > turned on. Ah! Okay, here's the use-case I wasn't thinking of: the concern is TBI conflicting with MTE. And anything that starts using TBI suddenly can't run in the future because it's being interpreted as MTE bits? (Is that the ABI concern? I feel like we got into the weeds about ioctl()s and one-off bugs...) So there needs to be some way to let the kernel know which of three things it should be doing: 1- leaving userspace addresses as-is (present) 2- wiping the top bits before using (this series) 3- wiping the top bits for most things, but retaining them for MTE as needed (the future) I expect MTE to be the "default" in the future. Once a system's libc has grown support for it, everything will be trying to use MTE. TBI will be the special case (but TBI is effectively a prerequisite). AFAICT, the only difference I see between 2 and 3 will be the tag handling in usercopy (all other places will continue to ignore the top bits). Is that accurate? Is "1" a per-process state we want to keep? (I assume not, but rather it is available via no TBI/MTE CONFIG or a boot-time option, if at all?) To choose between "2" and "3", it seems we need a per-process flag to opt into TBI (and out of MTE). For userspace, how would a future binary choose TBI over MTE? If it's a library issue, we can't use an ELF bit, since the choice may be "late" after ELF load (this implies the need for a prctl().) If it's binary-only ("built with HWKASan") then an ELF bit seems sufficient. And without the marking, I'd expect the kernel to enforce MTE when there are high bits. > I would also expect the C library or dynamic loader to check for the > presence of a HWCAP_MTE bit before starting to tag memory allocations, > otherwise it would get SIGILL on the first MTE instruction it tries to > execute. I've got the same question as Elliot: aren't MTE instructions just NOP to older CPUs? I.e. if the CPU (or kernel) don't support it, it just gets entirely ignored: checking is only needed to satisfy curiosity or behavioral expectations. To me, the conflict seems to be using TBI in the face of expecting MTE to be the default state of the future. (But the internal changes needed for TBI -- this series -- is a prereq for MTE.) -- Kees Cook _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel