From nobody Wed Nov 20 14:50:37 2024 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4XtknC0JPVz5dMTQ; Wed, 20 Nov 2024 14:50:39 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XtknB6yd3z45Wx; Wed, 20 Nov 2024 14:50:38 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1732114239; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=cC87lXW49STIS10//uB/hhgetMlDmUPW5Vt3ebT5KiU=; b=gtnjSXtXYW/azWOgCfCjSwDTZUrSU9CkieWl87qKmmeb3xYVFt+0EQ32M6A+gv6SzAX4vf JYVSvfKeLo+OJHlO0QoiVWkHLvWodsHt6vDRvR2bsAmGnlNJp1d2Si83Vo+/uT0L0mQubj Nx84AgxwGQGnz/SjtQdDTPrJmbGWcemJj7OjDYh8siMNm1j+QJLA4xpj4viR/VOGz7TGcn Sv3/fXtNxCX6HAurNY46hEIAzsMjzNMvXGd7Zb59jvyoBYyXjt7gdh51mBEA3wXaLL8ubk W2vZEYOvuemTl3VKPHT/U38ZZTQD4rBkOGk6dq6Ti2YvgyyH2JF3OgHJUtb4nQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1732114239; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=cC87lXW49STIS10//uB/hhgetMlDmUPW5Vt3ebT5KiU=; b=wlOpklKDax3N8qJN6bnpBpDvzGYnHmXAkdL7QLB2OWBiMYMO/JoxFYjj+kifqgM2fM2wYP FdD5Ff5Sy0N2GE+bpjDC7iIs8ZTHZEmnn/MCUI6l+4Hb+R+Up73VFZAnpZqZmD9+ws4ryX ZhqBcwCL//jnPJk4gPpQcJKvzQAlE2+1JpzagYnOjWna0htrj8X594fX6vycBHe4JsKvg6 vdzVjBrHyWYdLbwNzICsVKxZO9Lhjz/3N1faFhjeuXjBaLGaA8sSLWjpPVHvf6w11V7K4I DYlBpLiumSFwknul0xvNMTIV58S942ZabVkIyM7/meGKc/WDg0lF4db1UnWhRA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1732114239; a=rsa-sha256; cv=none; b=gr/2kSFQORE2aInTirk382/3VNlImm3ZXu7CZWczLdBgfiGC8RNiHoWf9iA3Dtci8xQ76j Qd2YyJczfBwIfnwE5yP4qaFbHMW3tDfYmYpjJuJOcXqOQGoUG3gSRVDwRem6r8++DPxtTW OH1QvpX/ndzdF3pIx0VRpez1JKDLJdCyils8dmIWFRmwPZPXWSwJ1BE1eXhjHosu11sFJ6 n1NjInD1mpFpFMevs0gbuOuI7mC2mn9uPvsxuV6bPDhtwERxpsEyH5doDWgjKSJLYZ3zfe UnTHhNZjER8TX+TQeLPXegi94w5+VmHLEwuFE5HASTz37yaeIdifNDqwrmYTLw== Received: from [IPV6:2601:5c0:4200:b830:2dc9:c321:2d58:e1d6] (unknown [IPv6:2601:5c0:4200:b830:2dc9:c321:2d58:e1d6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XtknB4h1Zz163g; Wed, 20 Nov 2024 14:50:38 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <9b7cdee1-dde4-46bf-aedd-be833fd3494d@FreeBSD.org> Date: Wed, 20 Nov 2024 09:50:37 -0500 List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: git: e85eaa930862 - main - Have rtld query the page size from the kernel Content-Language: en-US To: Konstantin Belousov Cc: Jessica Clarke , Andrew Turner , "src-committers@freebsd.org" , "dev-commits-src-all@freebsd.org" , "dev-commits-src-main@freebsd.org" References: <202204071438.237Ecn2A012737@gitrepo.freebsd.org> <92a05dfe-683c-43d9-bd29-3110e89be275@FreeBSD.org> <768D45F9-2F02-4BA1-BFB7-51685486CFCC@freebsd.org> <4d81d34f-4749-4911-b302-eca9166e4be7@FreeBSD.org> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 11/20/24 22:08, Konstantin Belousov wrote: > On Tue, Nov 19, 2024 at 10:14:52AM -0500, John Baldwin wrote: >> On 11/19/24 22:30, Konstantin Belousov wrote: >>> On Thu, Nov 14, 2024 at 09:47:30AM -0500, John Baldwin wrote: >>>> On 11/13/24 12:10, Jessica Clarke wrote: >>>>> On 13 Nov 2024, at 19:44, John Baldwin wrote: >>>>>> >>>>>> On 4/7/22 07:38, Andrew Turner wrote: >>>>>>> The branch main has been updated by andrew: >>>>>>> URL: https://cgit.FreeBSD.org/src/commit/?id=e85eaa930862d5b4dc917bc31e8d7254a693635d >>>>>>> commit e85eaa930862d5b4dc917bc31e8d7254a693635d >>>>>>> Author: Andrew Turner >>>>>>> AuthorDate: 2022-04-04 15:05:40 +0000 >>>>>>> Commit: Andrew Turner >>>>>>> CommitDate: 2022-04-07 14:37:37 +0000 >>>>>>> Have rtld query the page size from the kernel >>>>>>> To allow for a dynamic page size on arm64 have the runtime linker >>>>>>> query the kernel for the currentl page size. >>>>>>> Reviewed by: kib >>>>>>> Sponsored by: The FreeBSD Foundation >>>>>>> Differential Revision: https://reviews.freebsd.org/D34765 >>>>>> >>>>>> This broke relro handling for rtld. The reason is that init_pagesizes() is >>>>>> called after parsing the program headers for rltd in init_rtld(). As a result, >>>>>> page_size is 0 when rtld_round_page() is called so the relro_size is 0. The >>>>>> RTLD_INIT_EARLY_PAGESIZES case was for ia64, and in the early case it's probably >>>>>> not safe to call sysctl? If it is safe to call sysctl, we could just always >>>>>> init pagesizes early? >>>>> >>>>> It looks like there are a few things going on: >>>>> >>>>> 1. relocate_object calls obj_enforce_relro if !obj->mainprog, so will >>>>> try to enforce RELRO for RTLD itself whilst page_size is 0 >>>>> >>>>> 2. init_rtld later calls obj_enforce_relro for obj_rtld, after >>>>> page_size has been initialised >>>>> >>>>> 3. init_rtld is careful to avoid using global variables until it’s >>>>> called relocate_objects for RTLD itself, but by hiding accesses to >>>>> page_size away in rtld_*_page that’s no longer true (definitely not >>>>> true in the case of text relocations, for example, though whether it >>>>> also occurs for other cases we care more about I don’t know) >>>>> >>>>> So I think there are a couple of things to fix: >>>>> >>>>> 1. Stop accessing page_size prior to relocate_objects returning for >>>>> RTLD itself >>>>> >>>>> 2. Stop enforcing RELRO twice for RTLD (e.g. add && obj != rtldobj to >>>>> relocate_object’s case) >>>>> >>>>> At least, that’s what I’ve inferred from reading the code. >>>>> >>>>> Though, to be honest, things might be rather nicer if we just made >>>>> .rtld_start responsible for relocating RTLD itself prior to calling >>>>> init_rtld, that’s what we have to do for CHERI, as do arm, powerpc and >>>>> powerpc64, and it means you can use globals from the start in init_rtld. >>>> >>>> I've done 2) locally which fixed my immediate issue. >>> Can you provide some more info please? >> >> I have a local patch that supports mutiple PT_GNU_RELRO segments, and to >> do that it removes relro_* from Obj_Entry and just walks the list of >> phdrs in obj_remap_relro(). However, that defeats the order you mention >> below of the timing of parse_rtld_phdr(). I hadn't realized until your >> paragraph below that that local change was part of why this was exposed. >> It would still be more correct, strictly speaking, to skip obj_enforce_relro >> for rtldobj, and if we ever supported multiple PT_GNU_RELRO upstream we >> would want that change. > Ok, please commit this change. Ok, I will put that up for review. I wasn't sure if we would want this change upstream, but it is pretty simple. -- John Baldwin