From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) by sourceware.org (Postfix) with ESMTPS id DA60B386F454 for ; Mon, 11 May 2020 18:38:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org DA60B386F454 Received: by mail-qt1-x842.google.com with SMTP id x8so8778606qtr.2 for ; Mon, 11 May 2020 11:38:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:autocrypt:subject :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=LWnWw1S5hNYWWrpykgqL2NMAKQRhTHpTpcgK865zBxk=; b=g4YzA7//tP6P7bYpTFdbjrNXo+TYIx9Bts4hUE/q3JAcW4B9hGTVazMjTdlhNm7gDF 95UAEPDcBnNq2lXhvdSWzZy3eGiFLFafRZnXwOLYYcz6FCYfF38LjPC888rQmJLlj7+5 0Fn7NbWp4pUgdD4SnU52WnrI2RwNNMFrdgYHzBMYw9xHM8+zBdnZpqxaLSxq4xczQUc7 aVJ5JAat/2/i/hIgXbb2VAJriJmQyj3WjKb+2vGUoBDUp4RF6t1akkX/e58FJa/QaIAF 6pPnx7eT7b0homcIlDPuONdFUnxAdDTjJJqAzUvh5ZKkYPtwjwY+tRVa+IfTcWC+zB6H yTtQ== X-Gm-Message-State: AGi0PubIhQVHaMKq2zU4UcrwXi8J7axjfGsKA4Nw9Vnbx/B5/vFuLaUI 5DAE9Xsmi4UXM2jwJFmfDvK7JA== X-Google-Smtp-Source: APiQypLKSj5c2dW6gqdt0hJaWEvOfYdiDT4auFkSSFpxkjgqohuIhNetgcPU2IXCCBY3n0U9goroIg== X-Received: by 2002:ac8:5210:: with SMTP id r16mr7328836qtn.215.1589222287369; Mon, 11 May 2020 11:38:07 -0700 (PDT) Received: from [192.168.1.4] ([177.194.48.209]) by smtp.googlemail.com with ESMTPSA id e206sm8958101qkb.94.2020.05.11.11.38.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 May 2020 11:38:06 -0700 (PDT) To: Szabolcs Nagy Cc: libc-alpha@sourceware.org, Sudakshina Das References: <20200430173458.GV29015@arm.com> <20200430174407.GE29015@arm.com> <6ceb0ca3-2d71-907c-0a91-0b28d20b94fa@linaro.org> <20200511110449.GF7649@arm.com> From: Adhemerval Zanella Autocrypt: addr=adhemerval.zanella@linaro.org; prefer-encrypt=mutual; keydata= mQINBFcVGkoBEADiQU2x/cBBmAVf5C2d1xgz6zCnlCefbqaflUBw4hB/bEME40QsrVzWZ5Nq 8kxkEczZzAOKkkvv4pRVLlLn/zDtFXhlcvQRJ3yFMGqzBjofucOrmdYkOGo0uCaoJKPT186L NWp53SACXguFJpnw4ODI64ziInzXQs/rUJqrFoVIlrPDmNv/LUv1OVPKz20ETjgfpg8MNwG6 iMizMefCl+RbtXbIEZ3TE/IaDT/jcOirjv96lBKrc/pAL0h/O71Kwbbp43fimW80GhjiaN2y WGByepnkAVP7FyNarhdDpJhoDmUk9yfwNuIuESaCQtfd3vgKKuo6grcKZ8bHy7IXX1XJj2X/ BgRVhVgMHAnDPFIkXtP+SiarkUaLjGzCz7XkUn4XAGDskBNfbizFqYUQCaL2FdbW3DeZqNIa nSzKAZK7Dm9+0VVSRZXP89w71Y7JUV56xL/PlOE+YKKFdEw+gQjQi0e+DZILAtFjJLoCrkEX w4LluMhYX/X8XP6/C3xW0yOZhvHYyn72sV4yJ1uyc/qz3OY32CRy+bwPzAMAkhdwcORA3JPb kPTlimhQqVgvca8m+MQ/JFZ6D+K7QPyvEv7bQ7M+IzFmTkOCwCJ3xqOD6GjX3aphk8Sr0dq3 4Awlf5xFDAG8dn8Uuutb7naGBd/fEv6t8dfkNyzj6yvc4jpVxwARAQABtElBZGhlbWVydmFs IFphbmVsbGEgTmV0dG8gKExpbmFybyBWUE4gS2V5KSA8YWRoZW1lcnZhbC56YW5lbGxhQGxp bmFyby5vcmc+iQI3BBMBCAAhBQJXFRpKAhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJ EKqx7BSnlIjv0e8P/1YOYoNkvJ+AJcNUaM5a2SA9oAKjSJ/M/EN4Id5Ow41ZJS4lUA0apSXW NjQg3VeVc2RiHab2LIB4MxdJhaWTuzfLkYnBeoy4u6njYcaoSwf3g9dSsvsl3mhtuzm6aXFH /Qsauav77enJh99tI4T+58rp0EuLhDsQbnBic/ukYNv7sQV8dy9KxA54yLnYUFqH6pfH8Lly sTVAMyi5Fg5O5/hVV+Z0Kpr+ZocC1YFJkTsNLAW5EIYSP9ftniqaVsim7MNmodv/zqK0IyDB GLLH1kjhvb5+6ySGlWbMTomt/or/uvMgulz0bRS+LUyOmlfXDdT+t38VPKBBVwFMarNuREU2 69M3a3jdTfScboDd2ck1u7l+QbaGoHZQ8ZNUrzgObltjohiIsazqkgYDQzXIMrD9H19E+8fw kCNUlXxjEgH/Kg8DlpoYJXSJCX0fjMWfXywL6ZXc2xyG/hbl5hvsLNmqDpLpc1CfKcA0BkK+ k8R57fr91mTCppSwwKJYO9T+8J+o4ho/CJnK/jBy1pWKMYJPvvrpdBCWq3MfzVpXYdahRKHI ypk8m4QlRlbOXWJ3TDd/SKNfSSrWgwRSg7XCjSlR7PNzNFXTULLB34sZhjrN6Q8NQZsZnMNs TX8nlGOVrKolnQPjKCLwCyu8PhllU8OwbSMKskcD1PSkG6h3r0AquQINBFcVGkoBEACgAdbR Ck+fsfOVwT8zowMiL3l9a2DP3Eeak23ifdZG+8Avb/SImpv0UMSbRfnw/N81IWwlbjkjbGTu oT37iZHLRwYUFmA8fZX0wNDNKQUUTjN6XalJmvhdz9l71H3WnE0wneEM5ahu5V1L1utUWTyh VUwzX1lwJeV3vyrNgI1kYOaeuNVvq7npNR6t6XxEpqPsNc6O77I12XELic2+36YibyqlTJIQ V1SZEbIy26AbC2zH9WqaKyGyQnr/IPbTJ2Lv0dM3RaXoVf+CeK7gB2B+w1hZummD21c1Laua +VIMPCUQ+EM8W9EtX+0iJXxI+wsztLT6vltQcm+5Q7tY+HFUucizJkAOAz98YFucwKefbkTp eKvCfCwiM1bGatZEFFKIlvJ2QNMQNiUrqJBlW9nZp/k7pbG3oStOjvawD9ZbP9e0fnlWJIsj 6c7pX354Yi7kxIk/6gREidHLLqEb/otuwt1aoMPg97iUgDV5mlNef77lWE8vxmlY0FBWIXuZ yv0XYxf1WF6dRizwFFbxvUZzIJp3spAao7jLsQj1DbD2s5+S1BW09A0mI/1DjB6EhNN+4bDB SJCOv/ReK3tFJXuj/HbyDrOdoMt8aIFbe7YFLEExHpSk+HgN05Lg5TyTro8oW7TSMTk+8a5M kzaH4UGXTTBDP/g5cfL3RFPl79ubXwARAQABiQIfBBgBCAAJBQJXFRpKAhsMAAoJEKqx7BSn lIjvI/8P/jg0jl4Tbvg3B5kT6PxJOXHYu9OoyaHLcay6Cd+ZrOd1VQQCbOcgLFbf4Yr+rE9l mYsY67AUgq2QKmVVbn9pjvGsEaz8UmfDnz5epUhDxC6yRRvY4hreMXZhPZ1pbMa6A0a/WOSt AgFj5V6Z4dXGTM/lNManr0HjXxbUYv2WfbNt3/07Db9T+GZkpUotC6iknsTA4rJi6u2ls0W9 1UIvW4o01vb4nZRCj4rni0g6eWoQCGoVDk/xFfy7ZliR5B+3Z3EWRJcQskip/QAHjbLa3pml xAZ484fVxgeESOoaeC9TiBIp0NfH8akWOI0HpBCiBD5xaCTvR7ujUWMvhsX2n881r/hNlR9g fcE6q00qHSPAEgGr1bnFv74/1vbKtjeXLCcRKk3Ulw0bY1OoDxWQr86T2fZGJ/HIZuVVBf3+ gaYJF92GXFynHnea14nFFuFgOni0Mi1zDxYH/8yGGBXvo14KWd8JOW0NJPaCDFJkdS5hu0VY 7vJwKcyHJGxsCLU+Et0mryX8qZwqibJIzu7kUJQdQDljbRPDFd/xmGUFCQiQAncSilYOcxNU EMVCXPAQTteqkvA+gNqSaK1NM9tY0eQ4iJpo+aoX8HAcn4sZzt2pfUB9vQMTBJ2d4+m/qO6+ cFTAceXmIoFsN8+gFN3i8Is3u12u8xGudcBPvpoy4OoG Subject: Re: [PATCH 09/12] aarch64: support BTI enabled binaries Message-ID: <6fc763ad-99ed-3533-2343-9701408e13cb@linaro.org> Date: Mon, 11 May 2020 15:38:04 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200511110449.GF7649@arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-16.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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: Mon, 11 May 2020 18:38:18 -0000 On 11/05/2020 08:04, Szabolcs Nagy wrote: > The 05/07/2020 18:07, Adhemerval Zanella wrote: >> On 30/04/2020 14:44, Szabolcs Nagy wrote: >>> From 45c6bce5a691ecec9bba52785bd1f3a4cbc76fd4 Mon Sep 17 00:00:00 2001 >>> From: Sudakshina Das >>> Date: Tue, 17 Mar 2020 15:54:12 +0000 >>> Subject: [PATCH 09/12] aarch64: support BTI enabled binaries >>> >>> Binaries can opt-in to using BTI via an ELF property marking. >>> The dynamic linker has to then mprotect the executable segments >>> with PROT_BTI. In case of static linked executables or in case >>> of the dynamic linker itself, PROT_BTI protection is done by the >>> operating system. >>> >>> On AArch64 glibc uses PT_GNU_PROPERTY instead of PT_NOTE to check >>> the properties of a binary because PT_NOTE can be unreliable with >>> old linkers. >>> >>> Co-authored-by: Szabolcs Nagy >>> --- >>> elf/dl-load.c | 2 + >>> elf/rtld.c | 2 + >>> sysdeps/aarch64/Makefile | 4 + >>> sysdeps/aarch64/dl-bti.c | 54 ++++++ >>> sysdeps/aarch64/dl-prop.h | 170 ++++++++++++++++++ >>> sysdeps/aarch64/linkmap.h | 1 + >>> sysdeps/unix/sysv/linux/aarch64/bits/hwcap.h | 1 + >>> sysdeps/unix/sysv/linux/aarch64/bits/mman.h | 31 ++++ >>> .../unix/sysv/linux/aarch64/cpu-features.c | 3 + >>> .../unix/sysv/linux/aarch64/cpu-features.h | 1 + >>> 10 files changed, 269 insertions(+) >>> create mode 100644 sysdeps/aarch64/dl-bti.c >>> create mode 100644 sysdeps/aarch64/dl-prop.h >>> create mode 100644 sysdeps/unix/sysv/linux/aarch64/bits/mman.h >>> >>> diff --git a/elf/dl-load.c b/elf/dl-load.c >>> index a6b80f9395..0930250619 100644 >>> --- a/elf/dl-load.c >>> +++ b/elf/dl-load.c >>> @@ -1145,6 +1145,8 @@ _dl_map_object_from_fd (const char *name, const char *origname, int fd, >>> l->l_relro_size = ph->p_memsz; >>> break; >>> >>> + case PT_GNU_PROPERTY: >>> + /* Fall through. PT_GNU_PROPERTY holds property notes. */ >>> case PT_NOTE: >>> if (_dl_process_pt_note (l, ph, fd, fbp)) >>> { >> >> This will print the same error message for a failure in _dl_process_pt_note >> ("cannot process note segment"). Wouldn't be better to use a more specific >> error message, like "cannot process GNU property segment"? > > i was struggling to deal with this, i'm happy > to create a new hook for pt_gnu_property > (that's actually cleaner in aarch64, but x86 > will have to continue to look at PT_NOTE for > the same). > > it requires more generic changes though and > related code repetitions. I think it might be worth, specially since the _dl_process_pt_note stills used the __MAX_ALLOCA_CUTOFF (which I think we should replace with a scratch_buffer). > >>> + do >>> + { >>> + unsigned int type = *(unsigned int *) ptr; >>> + unsigned int datasz = *(unsigned int *) (ptr + 4); >>> + >>> + /* Property type must be in ascending order. */ >>> + if (type < last_type) >>> + return; >>> + >>> + ptr += 8; >>> + if ((ptr + datasz) > ptr_end) >>> + return; >>> + >>> + last_type = type; >> >> The logic to parse the PT_GNU_PROPERTY is quite similar to the one >> at sysdeps/x86/dl-prop.h to parse PT_NOTE. Would it be possible to >> maybe try to consolidate the logic somewhere to avoid this code >> duplication? > > yes it's similar but not the same. > > x86 tries to deal with multiple property notes > which does not happen on aarch64. > > i can try to refactor the code and see if > that works. Maybe parametrize the logic of number of property notes? > >>> + if (ph->p_offset + size <= (size_t) fbp->len) >>> + note = (const void *) (fbp->buf + ph->p_offset); >>> + else >>> + { >>> + if (size < __MAX_ALLOCA_CUTOFF) >>> + note = alloca (size); >>> + else >>> + note = note_malloced = malloc (size); >>> + if (note == NULL) >>> + return -1; >>> + if (__pread64_nocancel (fd, (void *) note, size, ph->p_offset) != size) >>> + { >>> + if (note_malloced) >>> + free (note_malloced); >>> + return -1; >> >> I wonder if we should use a scratch_buffer here instead. > > this logic is copied from x86, on aarch64 local buffer > should work with current linkers (since they will only > add at most one gnu property note to PT_GNU_PROPERTY), > but we don't know what happens in the future so the > malloc fallback is probably required. > > i think ideally the segment is mmaped into memory and > we can just use that, but i assumed the logic is there > for a reason on x86. Would mmap/unmap the segment a better strategy than use a small stack allocation for most of cases with a malloc fallback (which I think won't be used unless a ill formatted note)? > >>> +++ b/sysdeps/aarch64/linkmap.h >>> @@ -20,4 +20,5 @@ struct link_map_machine >>> { >>> ElfW(Addr) plt; /* Address of .plt */ >>> void *tlsdesc_table; /* Address of TLS descriptor hash table. */ >>> + int bti_guarded; /* Branch Target Identification mechanism enabled. */ >> >> Maybe bool here? > > ok. > >>> +++ b/sysdeps/unix/sysv/linux/aarch64/bits/hwcap.h >>> @@ -72,3 +72,4 @@ >>> #define HWCAP2_BF16 (1 << 14) >>> #define HWCAP2_DGH (1 << 15) >>> #define HWCAP2_RNG (1 << 16) >>> +#define HWCAP2_BTI (1 << 17) >> >> This it not yet upstream on Linus tree (6e7f2eacf098), but follows >> the arm64/for-next/bti branch (8ef8f360cf30be12). > > yes, now renamed to bti-user (because the kernel > code can also use bti protection) it is scheduled > for next linux, this patchset depends on that work, > but they have to be tested together. Ack, we just need to avoid another BZ#25971. > >>> +/* AArch64 specific definitions, should be in sync with >>> + arch/arm64/include/uapi/asm/mman.h. */ >>> + >>> +#define PROT_BTI 0x10 >> >> Linux specific flags should be protected by __USE_MISC. > > in posix the PROT_ prefix is reserved for sys/mman.h > so there is no namespace issue with this. > http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html > > see also PROT_SAO on powerpc. > MMAP_ as well, but we still protect Linux ones with __USE_MISC. The conform/data/sys/mman.h-data does not trigger a namespace issue for neither MMAP_ nor PROT_, so I am not sure which would be the best policy here. >>> +++ b/sysdeps/unix/sysv/linux/aarch64/cpu-features.h >>> @@ -64,6 +64,7 @@ struct cpu_features >>> { >>> uint64_t midr_el1; >>> unsigned zva_size; >>> + int bti; >> >> Maybe bool here? > > ok. >