From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) by sourceware.org (Postfix) with ESMTPS id EE26E383442F for ; Thu, 18 Feb 2021 22:33:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org EE26E383442F Received: by mail-oi1-x232.google.com with SMTP id q186so3783994oig.12 for ; Thu, 18 Feb 2021 14:33:33 -0800 (PST) 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=hsF9luU1kkaVQ4oKg1sqgmi3aa36M4fAF6dviPu+0io=; b=QKBZncUfiXjgpHi2h+qnUojfEVy371djo9zJ2KC+WrsWjQaqB//UqF5xFwtzyj0/NO df6qDEz/h+GtiliAGgq+7irbrMsRdm0F2FzCziVjUTlZeNv6yj0D0Zkw5dyI502NULup hfTP0b6EyGPuPxR68V2Zg19ZWe+Wnc6z57kRMzYq8qUVjT2YGLLokiIL9JADz+2WVbg1 Qkct3avCMoHwp3XtggLeri/QDTvxCQP4piNI5CQmUR8qjqj56eEgv3UAE71w8LFfA7IE Jg5a/cpMoQjO/n4bPRHfqjUW68uG0yKW0zGn8BMp0rXV44uBed6EGFHOB1CBORWpBd4P 2Rmg== X-Gm-Message-State: AOAM531Xrfhz500wmcb2Ra8lPwXK0iN6r7RmG1ectxaFqO1n5jpXCYgV 2vIF+CtPVaFDUTrp4vDXLnIxsoFf+cV/5C0JkR0= X-Google-Smtp-Source: ABdhPJxeTnKrKCvbMcAPkrx3sfz6Re+Y1S6JpPu5hz0fhGFnPq92iDMHvSsIDBi1I9Eh+8i+Lq0AJobvqgGzFbkNxNU= X-Received: by 2002:a54:468f:: with SMTP id k15mr4493595oic.58.1613687613375; Thu, 18 Feb 2021 14:33:33 -0800 (PST) MIME-Version: 1.0 References: <20210211173711.71736-1-hjl.tools@gmail.com> <877dndmxj3.fsf@oldenburg.str.redhat.com> <20210218132419.GD12795@arm.com> <874ki9mrn4.fsf@oldenburg.str.redhat.com> <20210218135035.GE12795@arm.com> In-Reply-To: <20210218135035.GE12795@arm.com> From: "H.J. Lu" Date: Thu, 18 Feb 2021 14:32:57 -0800 Message-ID: Subject: Re: [RFC] : An API for tagged address To: Szabolcs Nagy Cc: Florian Weimer , "Kirill A. Shutemov" , "Shanbhogue, Vedvyas" , "H.J. Lu via Libc-alpha" , Joseph Myers Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3028.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, URIBL_BLACK autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2021 22:33:35 -0000 On Thu, Feb 18, 2021 at 5:50 AM Szabolcs Nagy wrote: > > The 02/18/2021 14:28, Florian Weimer wrote: > > * Szabolcs Nagy: > > >> was called in a thread. It won't work when 2 threads have different address > > >> masks. I think set_tagged_address_mask should be disallowed in child > > >> threads and in parent thread when there are any active child threads. > > > > > > i think this is the wrong api. currently the libc should set > > > things up early. api for user code is too late. > > > > > > user code does not know if it runs single threaded or not > > > (although we have __libc_single_threaded now, i'm not sure if > > > we can use that for this purpose) > > > > We could, but it's possible to launch threads from ELF constructors (and > > I think some libraries do that). So you could avoid the call or > > diagnose a failure if single-threaded, but the tagged address feature > > wouldn't compose well. > > > > Some kernel interfaces have this problem (e.g., unshare), but they are > > less general-purpose than tagged addresses. > > it is possible to have a prctl flag that requests the abi > change for the entire process. (and then the kernel has > to do the sync across threads.) > > the semantics is not entirely obvious wrt memory model > if we want to do this for e.g. MTE tag checks, but for > syscall abi it should be possible to define reasonably. > > e.g. a use-case for changing mte/tag abi settings for an > entire process is a custom allocator that wants to use > heap tagging. by the time it can call the prctl the > process may be already multi-threaded. > > there is also a problem with coordination between > concurrent callers. this is simple with the tagged > address abi which is a 1 bit state and we can say that > it always goes one way: no tag -> tag, but more complex > state like mte checking mode or mte tag exclusion set, > requires coordination, which tells me that there should > be a single owner: the libc. > > but i don't know what requirements intel LAM has. We are working to enable LAM in glibc and GCC (HWASAN). 0. LAM is disabled when the process starts. 1. Define GNU property markers for LAM compatibility. 2. Update ld.so to support LAM. 3. Make libc.so LAM compatible (memmove). 4. Provide an API to enable LAM. We noticed a few issues: 1. HWASAN should use the glibc API to enable tagged address since glibc must track the tagged address mask. 2. set_tagged_address_mask shouldn't be allowed after pthread_create is called. 3. After set_tagged_address_mask is called, can it be called again to change tagged address mask. -- H.J.