From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-4.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 5F1621F5AE for ; Wed, 21 Apr 2021 23:21:47 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 43529383302E; Wed, 21 Apr 2021 23:21:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 43529383302E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1619047306; bh=3qEOrx6h8rvgUKHQzDW4IJEx37UZ5MwC0aXtaZvzuGU=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=AwyzBPCHJJPvUg9aOPcRs/87N8xEln89WzWt2rIQwNdWmFnVXcK54YIJ4B8YloBDD AvGRtWJbB7BFPySzyTkC+xybY/OuLxgDM5jWljcjRyDkDWHzeUuxbaFh57/sz20abz h8jfafXAm7zuSaJNzadifDaVrBrgBI/aX+kc0jQ8= Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) by sourceware.org (Postfix) with ESMTPS id 807363844026 for ; Wed, 21 Apr 2021 23:21:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 807363844026 Received: by mail-ot1-x332.google.com with SMTP id 92-20020a9d02e50000b029028fcc3d2c9eso17986109otl.0 for ; Wed, 21 Apr 2021 16:21:43 -0700 (PDT) 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=3qEOrx6h8rvgUKHQzDW4IJEx37UZ5MwC0aXtaZvzuGU=; b=uOJPo0dMwmQUxdDT4iE3rpOSMsTzVyAtSuf/nptZ91r1sFnjlk8H+R6KnS9xlV68mU Xh0bhheQ1ghY4QslxilaaK9oJEzjGQLsiR807pAzHfZ/HTpbPkarjT2ohzJWelQLGULj Gex/rOKzebnh8Wt71i3LsDYJWrOX9eHIl5QlEiNaOXyqssFFjr9s9ogklFTnkmJwCCJa 6nAEHOQBEknlG36bEf5Pog9glffJ/TY9YNCSXE8hz+tzpUC42Qw5W8gFsyq0oY2fpc+R jVRUjK6A7AUjIQBFWkvHUuNEnc3J5oJt8jffMV+e62r2Ka84mdItzNKgC1tyI1ICiNHR RyxA== X-Gm-Message-State: AOAM532I9KnFiar/z69IctyEULLUw0vEDa/A+OtwEZN6VygD6S0a3mDz 7geqqqk/M1052d74aZ9W7KikowwJj29iWMF7zyM= X-Google-Smtp-Source: ABdhPJy/wd5c898P7cP9yB7OvfUS7RIhXZEajFZD1MA0zAMr+46VwpeBX/ak2eW6lV42YVJZPUbtiF5tHep9UGkWzQo= X-Received: by 2002:a05:6830:1515:: with SMTP id k21mr437817otp.269.1619047302789; Wed, 21 Apr 2021 16:21:42 -0700 (PDT) MIME-Version: 1.0 References: <20210420021819.765779-1-hjl.tools@gmail.com> <20210420021819.765779-2-hjl.tools@gmail.com> <8735vkqh38.fsf@oldenburg.str.redhat.com> In-Reply-To: <8735vkqh38.fsf@oldenburg.str.redhat.com> Date: Wed, 21 Apr 2021 16:21:06 -0700 Message-ID: Subject: Re: [PATCH v4 1/2] : An API for tagged address To: Florian Weimer Content-Type: multipart/mixed; boundary="0000000000005b9a7405c083d354" 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: , From: "H.J. Lu via Libc-alpha" Reply-To: "H.J. Lu" Cc: Szabolcs Nagy , libc-alpha@sourceware.org, "Kirill A . Shutemov" , Joseph Myers , Vedvyas Shanbhogue Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" --0000000000005b9a7405c083d354 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 20, 2021 at 11:36 PM Florian Weimer wrote: > > * H. J. Lu: > > > diff --git a/manual/tagged-address.texi b/manual/tagged-address.texi > > new file mode 100644 > > index 0000000000..ce10f7e752 > > --- /dev/null > > +++ b/manual/tagged-address.texi > > @@ -0,0 +1,59 @@ > > +@node Tagged Address, Character Handling, Memory, Top > > +@c %MENU% Tagged address functions and macros > > +@chapter Tagged Address > > + > > +By default, the number of the address bits used in address translation > > +is the number of address bits. But it can be changed by ARM Top-byte > > +Ignore (TBI) or Intel Linear Address Masking (LAM). > > + > > +@Theglibc{} provides several functions and macros in the header file > > +@file{sys/tagged-address.h} to manipulate tagged address bits, which i= s > > +the number of the address bits used in address translation. > > +@pindex sys/tagged-address.h > > I don't under stand the =E2=80=9Cwhich is the number of address bits=E2= =80=9D part. For tagged addresses, not all bits are used in address translation. For TBI, only the lower 48 bits are used in address translation. For LAM, it can be either the lower 48 bits or 57 bits. > This section needs to describe under which circumstances it is valid to > alter the tag bits in pointers returned from glibc functions (including Tagged address is enabled only when get_tagged_address_mask () !=3D -1. > system call wrappers). I think at least historically, the kernel > required masking tag bits in user space for TBI. I believe this has been fixed in the recent kernel. > > +@deftypefun {unsigned int} get_tagged_address_bits (void) > > +@standards{GNU, sys/tagged-address.h} > > +@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}} > > +Get the current address bits used in address translation. The return > > +value is @code{0} if tag bits are not the highest bits in address. > > +@end deftypefun > > =E2=80=9Cin addresses=E2=80=9D? Fixed. > What is the return value if there are no tag bits available? The word > width? I am adding: The return value is the number of address bits when tagged address is unsupported. > > > +@deftypefun uintptr_t get_tagged_address_mask (void) > > +@standards{GNU, sys/tagged-address.h} > > +@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}} > > +Get the current mask for address bits used in address translation. > > +@end deftypefun > > Mask is ambiguous in this context. If a bit is set in the return value, > will this bit take part in address translation or not? Please be > explicit here. Fixed. > > +@deftypefun int set_tagged_address_mask (uintptr_t @var{mask}) > > +@standards{GNU, sys/tagged-address.h} > > +@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}} > > +Set the mask for address bits used in address translation to @var{mask= }. > > +The return value is @code{0} on success and @code{-1} on failure. Thi= s > > +function can be called only once before @code{main}. The possible > > +@code{errno} error conditions are @code{ENODEV}, @code{EPERM}, > > +@code{EINVAL}, and @code{ENOSYS}. > > +@end deftypefun > > Likewise, please clarify if bits set in MASK participate in address > translation or not. Fixed. > Why before main? Do you mean it can only be called once per process? The feedback is that it should be called as early as possible: https://sourceware.org/pipermail/libc-alpha/2021-February/122795.html > I think this limitation suggests we should use ELF markup for this. > There are definitely compatibility issues to work out here. See: https://gitlab.com/x86-psABIs/x86-64-ABI/-/commits/usr/hjl/lam > Historically, the x86-64 psABI supplement implied that the top 16 bits > are available for application use (without hardware masking obviously). > If e.g. malloc starts returning tagged addresses, that assumption > breaks. These applications must be changed to support LAM. > Should glibc allocate tag bits to different libraries within the same > process? For example, so that malloc could get 2 tag bits, the main > program 3 and some other library 1 bit? My API proposal doesn't prevent this scheme. > For glibc malloc, it would be a simple enhancement to move the > IS_MMAPPED to a tag bit, and eliminate the malloc header for mmap'ed > chunks, replacing it with a separate data structure. This would allow > us to preserve page alignment for mmap'ed chunks without wasting an > entire page for each allocation, just to store the malloc header. > > > +@deftypefun {void *} tag_address (void *@var{addr}, unsigned int @var{= tag}) > > +@standards{GNU, sys/tagged-address.h} > > +@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}} > > +Return the address of @var{addr} with the tag value @var{tag} stored > > +in the untranslated bits. Overflow of @var{tag} in the untranslated > > +bits are ignored. > > +@end deftypefun > > + > > +@deftypefun {void *} untag_address (void *@var{addr}) > > +@standards{GNU, sys/tagged-address.h} > > +@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}} > > +Return the address of @var{addr} with all zero untranslated bits. > > +@end deftypefun > > This should reference the earlier discussion about when it is safe to > tag and untag addresses. > > > +@deftypefn Macro int TAGGED_ADDRESS_VALID_BITS (@var{bits}) > > +This macro returns a nonzero value (true) if @var{bits} a valid tagged > > +address bits. > > +@end deftypefn > > =E2=80=9Care valid tagged=E2=80=9D? > > Does =E2=80=9Cvalid=E2=80=9D mean in this context that =E2=80=9Cthe CPU c= an be configured to > ignore bits set in BITS during address translation using > set_tagged_address_mask=E2=80=9D? > > > +@deftypefn Macro {const uintptr_t} TAGGED_ADDRESS_MASK (@var{bits}) > > +This macro returns a nonzero value if it can be used as mask for const= ant > > +address @var{bits} used in address translation. > > +@end deftypefn > > I do not understand the description. Fixed. I am enclosing the updated tagged-address.texi here. Thanks. --=20 H.J. --0000000000005b9a7405c083d354 Content-Type: text/x-texinfo; charset="US-ASCII"; name="tagged-address.texi" Content-Disposition: attachment; filename="tagged-address.texi" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kns2xnut0 QG5vZGUgVGFnZ2VkIEFkZHJlc3MsIENoYXJhY3RlciBIYW5kbGluZywgTWVtb3J5LCBUb3AKQGMg JU1FTlUlIFRhZ2dlZCBhZGRyZXNzIGZ1bmN0aW9ucyBhbmQgbWFjcm9zCkBjaGFwdGVyIFRhZ2dl ZCBBZGRyZXNzCgpCeSBkZWZhdWx0LCB0aGUgbnVtYmVyIG9mIHRoZSBhZGRyZXNzIGJpdHMgdXNl ZCBpbiBhZGRyZXNzIHRyYW5zbGF0aW9uCmlzIHRoZSBudW1iZXIgb2YgYWRkcmVzcyBiaXRzLiAg QnV0IGl0IGNhbiBiZSBjaGFuZ2VkIGJ5IEFSTSBUb3AtYnl0ZQpJZ25vcmUgKFRCSSkgb3IgSW50 ZWwgTGluZWFyIEFkZHJlc3MgTWFza2luZyAoTEFNKS4KCkBUaGVnbGliY3t9IHByb3ZpZGVzIHNl dmVyYWwgZnVuY3Rpb25zIGFuZCBtYWNyb3MgaW4gdGhlIGhlYWRlciBmaWxlCkBmaWxle3N5cy90 YWdnZWQtYWRkcmVzcy5ofSB0byBtYW5pcHVsYXRlIHRhZ2dlZCBhZGRyZXNzIGJpdHMsIHdoaWNo IGlzCnRoZSBudW1iZXIgb2YgdGhlIGFkZHJlc3MgYml0cyB1c2VkIGluIGFkZHJlc3MgdHJhbnNs YXRpb24uCkBwaW5kZXggc3lzL3RhZ2dlZC1hZGRyZXNzLmgKCkBkZWZ0eXBlZnVuIHt1bnNpZ25l ZCBpbnR9IGdldF90YWdnZWRfYWRkcmVzc19iaXRzICh2b2lkKQpAc3RhbmRhcmRze0dOVSwgc3lz L3RhZ2dlZC1hZGRyZXNzLmh9CkBzYWZldHl7QHByZWxpbXt9QG10c2FmZXt9QGFzc2FmZXt9QGFj c2FmZXt9fQpHZXQgdGhlIGN1cnJlbnQgYWRkcmVzcyBiaXRzIHVzZWQgaW4gYWRkcmVzcyB0cmFu c2xhdGlvbi4gIFRoZSByZXR1cm4KdmFsdWUgaXMgQGNvZGV7MH0gaWYgdGFnIGJpdHMgYXJlIG5v dCB0aGUgaGlnaGVzdCBiaXRzIGluIGFkZHJlc3Nlcy4gIFRoZQpyZXR1cm4gdmFsdWUgaXMgdGhl IG51bWJlciBvZiBhZGRyZXNzIGJpdHMgd2hlbiB0YWdnZWQgYWRkcmVzcyBpcwp1bnN1cHBvcnRl ZC4KQGVuZCBkZWZ0eXBlZnVuCgpAZGVmdHlwZWZ1biB1aW50cHRyX3QgZ2V0X3RhZ2dlZF9hZGRy ZXNzX21hc2sgKHZvaWQpCkBzdGFuZGFyZHN7R05VLCBzeXMvdGFnZ2VkLWFkZHJlc3MuaH0KQHNh ZmV0eXtAcHJlbGlte31AbXRzYWZle31AYXNzYWZle31AYWNzYWZle319CkdldCB0aGUgY3VycmVu dCBtYXNrIGZvciBhZGRyZXNzIGJpdHMgdXNlZCBpbiBhZGRyZXNzIHRyYW5zbGF0aW9uLiAgSWYg YQpiaXQgaXMgc2V0IGluIHRoZSByZXR1cm4gdmFsdWUsIHRoaXMgYml0IGlzIHVzZWQgaW4gYWRk cmVzcyB0cmFuc2xhdGlvbi4KVGhlIHJldHVybiB2YWx1ZSBpcyBAY29kZXstMX0gd2hlbiBhbGwg Yml0cyBhcmUgdXNlZCBpbiBhZGRyZXNzCnRyYW5zbGF0aW9uLgpAZW5kIGRlZnR5cGVmdW4KCkBk ZWZ0eXBlZnVuIGludCBzZXRfdGFnZ2VkX2FkZHJlc3NfbWFzayAodWludHB0cl90IEB2YXJ7bWFz a30pCkBzdGFuZGFyZHN7R05VLCBzeXMvdGFnZ2VkLWFkZHJlc3MuaH0KQHNhZmV0eXtAcHJlbGlt e31AbXRzYWZle31AYXNzYWZle31AYWNzYWZle319ClNldCB0aGUgbWFzayBmb3IgYWRkcmVzcyBi aXRzIHVzZWQgaW4gYWRkcmVzcyB0cmFuc2xhdGlvbiB0byBAdmFye21hc2t9LgpPbmx5IGJpdHMg c2V0IGluIEB2YXJ7bWFza30gd2lsbCBiZSB1c2VkIGluIGFkZHJlc3MgdHJhbnNsYXRpb24uICBU aGUKcmV0dXJuIHZhbHVlIGlzIEBjb2RlezB9IG9uIHN1Y2Nlc3MgYW5kIEBjb2Rley0xfSBvbiBm YWlsdXJlLiAgVGhpcwpmdW5jdGlvbiBjYW4gYmUgY2FsbGVkIG9ubHkgb25jZSBiZWZvcmUgQGNv ZGV7bWFpbn0uICBUaGUgcG9zc2libGUKQGNvZGV7ZXJybm99IGVycm9yIGNvbmRpdGlvbnMgYXJl IEBjb2Rle0VOT0RFVn0sIEBjb2Rle0VQRVJNfSwKQGNvZGV7RUlOVkFMfSwgYW5kIEBjb2Rle0VO T1NZU30uCkBlbmQgZGVmdHlwZWZ1bgoKQGRlZnR5cGVmdW4ge3ZvaWQgKn0gdGFnX2FkZHJlc3Mg KHZvaWQgKkB2YXJ7YWRkcn0sIHVuc2lnbmVkIGludCBAdmFye3RhZ30pCkBzdGFuZGFyZHN7R05V LCBzeXMvdGFnZ2VkLWFkZHJlc3MuaH0KQHNhZmV0eXtAcHJlbGlte31AbXRzYWZle31AYXNzYWZl e31AYWNzYWZle319ClJldHVybiB0aGUgYWRkcmVzcyBvZiBAdmFye2FkZHJ9IHdpdGggdGhlIHRh ZyB2YWx1ZSBAdmFye3RhZ30gc3RvcmVkCmluIHRoZSB1bnRyYW5zbGF0ZWQgYml0cy4gIE92ZXJm bG93IG9mIEB2YXJ7dGFnfSBpbiB0aGUgdW50cmFuc2xhdGVkCmJpdHMgYXJlIGlnbm9yZWQuCkBl bmQgZGVmdHlwZWZ1bgoKQGRlZnR5cGVmdW4ge3ZvaWQgKn0gdW50YWdfYWRkcmVzcyAodm9pZCAq QHZhcnthZGRyfSkKQHN0YW5kYXJkc3tHTlUsIHN5cy90YWdnZWQtYWRkcmVzcy5ofQpAc2FmZXR5 e0BwcmVsaW17fUBtdHNhZmV7fUBhc3NhZmV7fUBhY3NhZmV7fX0KUmV0dXJuIHRoZSBhZGRyZXNz IG9mIEB2YXJ7YWRkcn0gd2l0aCBhbGwgemVybyB1bnRyYW5zbGF0ZWQgYml0cy4KQGVuZCBkZWZ0 eXBlZnVuCgpAZGVmdHlwZWZuIE1hY3JvIGludCBUQUdHRURfQUREUkVTU19WQUxJRF9CSVRTIChA dmFye2JpdHN9KQpUaGlzIG1hY3JvIHJldHVybnMgYSBub256ZXJvIHZhbHVlICh0cnVlKSBpZiBA dmFye2JpdHN9IGlzIGEgdmFsaWQKY29uc3RhbnQgbnVtYmVyIG9mIHRoZSBsb3dlciBhZGRyZXNz IGJpdHMgd2hpY2ggY2FuIGJlIHVzZWQgaW4gYWRkcmVzcwp0cmFuc2xhdGlvbi4KQGVuZCBkZWZ0 eXBlZm4KCkBkZWZ0eXBlZm4gTWFjcm8ge2NvbnN0IHVpbnRwdHJfdH0gVEFHR0VEX0FERFJFU1Nf TUFTSyAoQHZhcntiaXRzfSkKVGhpcyBtYWNybyByZXR1cm5zIGEgbm9uemVybyB2YWx1ZSB3aGlj aCBjYW4gYmUgcGFzc2VkIHRvCkBjb2Rle3NldF90YWdnZWRfYWRkcmVzc19tYXNrfSB0byBzcGVj aWZ5IHRoZSBsb3dlciBhZGRyZXNzIEB2YXJ7Yml0c30KZm9yIGFkZHJlc3MgdHJhbnNsYXRpb24u CkBlbmQgZGVmdHlwZWZuCg== --0000000000005b9a7405c083d354--