From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) by sourceware.org (Postfix) with ESMTPS id 99A4E3953422 for ; Wed, 21 Oct 2020 08:02:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 99A4E3953422 Received: by mail-lj1-x233.google.com with SMTP id h20so1568657lji.9 for ; Wed, 21 Oct 2020 01:02:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=DWgwUV5vrnyr52vvGedowojWBgJHij0tK1Esw5DkMW4=; b=SjR+Aoajgkzb5Ctsg3F4+wA1b6rwE8sAynYrXrHkh3R2RkEketEWPqpO8s7t5hALS7 F50vuiwG8+j3kXLlXu/kymslQNDZ094W7DJ2TPFHc11vgZZ3o5f5XimWTWkNglC9YYk7 WykCxVY2Ngc+S4nvJhkCw+vKl1Ory8pVESQNpJ/D2tU49P0uF0N5+c3ni3Wr9hX248Uk SBfkIygUZn17R2sa9Vs6k4g/Vw6T3cqlIQEQ+tVi+m6u2/Mewgm1FJqlenX5To3oraOQ tedPKLMUcTnoUZ1C54KW4RcA430cKp3oBSdCtrBpe479LViMsWj08/9bk9PLs6EMfKTM vt9A== X-Gm-Message-State: AOAM533ezVBBFhh61k+ttr52+4InqsXV8ZVCorx+r/68Cx7dtixMD70e QEIKfOU+/CF2Fa4fwNkzy8UBCcHr1mE= X-Google-Smtp-Source: ABdhPJy4EWl3kRBCkUbTaQMhx9bfTV9pnuf9PO53XoNTj+Lb+/ix++nbJOe38U6BbsZWQi8DEPqefw== X-Received: by 2002:a2e:9c3:: with SMTP id 186mr903480ljj.134.1603267342161; Wed, 21 Oct 2020 01:02:22 -0700 (PDT) Received: from [192.168.1.112] (88-114-211-119.elisa-laajakaista.fi. [88.114.211.119]) by smtp.gmail.com with ESMTPSA id x7sm267677lfg.281.2020.10.21.01.02.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Oct 2020 01:02:21 -0700 (PDT) Subject: Re: Randomize offset between program segments? To: Florian Weimer , Topi Miettinen via Libc-alpha References: <87y2k016u1.fsf@oldenburg2.str.redhat.com> From: Topi Miettinen Message-ID: <5da187b7-afd3-e985-7d6a-d8334ebc276f@gmail.com> Date: Wed, 21 Oct 2020 11:02:05 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <87y2k016u1.fsf@oldenburg2.str.redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, 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: Wed, 21 Oct 2020 08:02:25 -0000 On 21.10.2020 8.33, Florian Weimer wrote: > * Topi Miettinen via Libc-alpha: > >> I'd like to improve address space randomization (ASLR) by randomizing >> the offset between .text, .data and .bss segments (or more >> generalized, any program segments). With large code generation model >> (-mcmodel=large) on AMD64, the offset could be very large, but even >> with the default model, the segments could be randomized within range >> of RIP-relative accesses (+/-2GB). Currently the dynamic loader can't >> randomize the segments (nothing also tells it if this would be OK) so >> it maps them next to each other, which is predictable and boring. > > As far as I understand it, -mcmodel=large does not really work right now > with a stock toolchain. At least small programs seem to work, but I'll try compiling something more serious. I'd expect very little breakage outside of assembly, since externally visible values (pointers) already use 64-bit absolute addresses. But I'm not so interested in large model anyway, randomizing the default model could be more interesting. > But what you are asking for looks more like FDPIC support to me anyway. > I do not think it's particularly useful to implement this for targets > which have an MMU, to be honest. I'm not proposing to introduce FDPIC. In the default code model, 32 bit offsets to RIP would not be hard coded like now but there would be relocations, handled by the dynamic linker. Even for the large model, I don't care much how the compiler implements the position independence. -Topi