From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97755 invoked by alias); 21 Feb 2019 19:22:47 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 97730 invoked by uid 89); 21 Feb 2019 19:22:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-11.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,GIT_PATCH_1,GIT_PATCH_2,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-Spam-Status: No, score=-11.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,GIT_PATCH_1,GIT_PATCH_2,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mail-ot1-f67.google.com Received: from mail-ot1-f67.google.com (HELO mail-ot1-f67.google.com) (209.85.210.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 21 Feb 2019 19:22:45 +0000 Received: by mail-ot1-f67.google.com with SMTP id i5so45869826oto.9 for ; Thu, 21 Feb 2019 11:22:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=JSmB98JlpMs1uLXrUoMneDC/xP6f/5jwjIwEZHtXFW0=; b=TBUcR97AIZsRyKHw7D4I+wysbHR7VVW5QevTH0FzcjcC9NKzieoJxflwiFkEE8YpEt BargnrB+zqztrptVqO2O1Q5ppmucjmHrT9SDVVPe5Ib/DDgdEfKOAfjCCPT+p1S8SJ7E FzG++CdtOgHPxsaP2L40O9/sJ7ppAtWSkgbpm2gmHIxBhwZbuyCvFQs8uETFRqXJy+4h U+MwElToimXlijMnLCE5RHeOi76J3oMDgmGaMJMKYKo16+i/mLeoMHnTdEBmjqscV+Oh CRTyBxK94Z6KyL880M7scl9OdMLfcY17YHFd2fi0zaTEfXTWkAgumAn7L8sO/iATI0pB LT/Q== 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:content-transfer-encoding; bh=JSmB98JlpMs1uLXrUoMneDC/xP6f/5jwjIwEZHtXFW0=; b=hVjxb1Jvfl7gpHcfjUQpV+nli3rWyXqcHMpV3/OGYmvB++pLIKqJfdhOwTMB0wQuYH THt3p2OomVaW95cLBgYdA+WoHlYapV7Rtosie6YyKyImNrr1qhuY5uv7tCAwswItsLer RRTib5msj9LgkFqFbzlpE3v/KDj10gtLlGJgxmQ660LLNOX74g4FDjYZ1BGG4rtFOc14 FphYDkJ+qJ+aDYhcHwLZcjDMGrCLW+FzLczRgpVIXCGV70cIEFjypcETSp2zjzTI+JzE bO5Sm2BbjxsM/9Vgzy1Umi/Sgx+Tcr3WbELIHnaX5PSONxCYw1nbN3SLDFM/bL2xavvg oJGg== X-Gm-Message-State: AHQUAuYPDHq6KFrdrR6eN/sRQ+qG2OCeVnnN8YDAN43cs86kiSjo8Bdn MgSw7qZp6G4HWX3eYjkQXJL2lIJtyomQ/gc03e8= X-Google-Smtp-Source: AHgI3IZkPmnzrxByvyKH7L5CaX+z/SOeCk5peFJ89pCOzoi6TbQ3BDnOzBTyGsQHdn1uf/0yRKdmA1GB2cVWfnfFLRQ= X-Received: by 2002:a9d:803:: with SMTP id 3mr119386oty.4.1550776963228; Thu, 21 Feb 2019 11:22:43 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "H.J. Lu" Date: Tue, 01 Jan 2019 00:00:00 -0000 Message-ID: Subject: Re: RFC: Update x86 psABIs to support IBT To: Rui Ueyama Cc: IA32 System V Application Binary Interface , "x86-64-abi@googlegroups.com" , gnu-gabi@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-q1/txt/msg00007.txt.bz2 On Thu, Feb 21, 2019 at 11:18 AM Rui Ueyama wrote: > > On Wed, Feb 20, 2019 at 7:01 PM H.J. Lu wrote: >> >> On Wed, Feb 20, 2019 at 4:30 PM Rui Ueyama wrote: >> > >> > Hi H.J.Lu, >> > >> > I'm replying because I was wondering why the 2-PLT scheme was chosen t= o support Intel CET. >> > >> > On Tue, Feb 19, 2019 at 8:36 PM H.J. Lu wrote: >> >> >> >> On Tue, Jun 20, 2017 at 9:38 AM H.J. Lu wrote: >> >> > >> >> > On Tue, Jun 13, 2017 at 12:11 PM, H.J. Lu wro= te: >> >> > > To support ENDBR in Intel Control-flow Enforcement Technology (CE= T) >> >> > > instructions: >> >> > > >> >> > > https://software.intel.com/sites/default/files/managed/4d/2a/cont= rol-flow-enforcement-technology-preview.pdf >> >> > > >> >> > > following changes to i386 psABI are required. >> >> > >> >> > Here is the updated extension for both i386 and x86-64 psABI to >> >> > support IBT. I will post a binutls patch later. >> >> > >> >> > Any comments? >> >> > >> >> > -- >> >> > H.J. >> >> > --- >> >> > To support indirect branch tracking (IBT) in Intel Control-flow Enf= orcement >> >> > Technology (CET) instructions: >> >> > >> >> > https://software.intel.com/sites/default/files/managed/4d/2a/contro= l-flow-enforcement-technology-preview.pdf >> >> > >> >> > following changes to x86 psABI are required. >> >> > >> >> > To program properties, add >> >> > >> >> > #define GNU_PROPERTY_X86_FEATURE_1_AND 0xc0000002 >> >> > >> >> > #define GNU_PROPERTY_X86_FEATURE_1_IBT (1U << 0) >> >> > >> >> > to indicate that all executable sections are compatible with IBT wh= en >> >> > ENDBR instruction is inserted at: >> >> > >> >> > a. All function entries whose addresses may be taken. >> >> > b. All branch targets whose addresses have been taken. >> >> > >> >> > GNU_PROPERTY_X86_FEATURE_1_IBT is set on output only if it is set on >> >> > all relocatable inputs, which means that the C library must be comp= iled >> >> > with IBT-enabled compiler. >> >> > >> >> > The followings changes are made to the Procedure Linkage Table (PLT= ) to >> >> > enable IBT: >> >> > >> >> > 1. For 64-bit x86-64, PLT is changed to: >> >> > >> >> > PLT0: push GOT[1] >> >> > bnd jmp *GOT[2] >> >> > nop >> >> > ... >> >> > PLTn: endbr64 >> >> > push namen_reloc_index >> >> > bnd jmp PLT0 >> >> > >> >> > together with the second PLT section: >> >> > >> >> > PLTn: endbr64 >> >> > bnd jmp *GOT[namen_index] >> >> > nop >> >> > >> >> > BND prefix is also added so that IBT-enabled PLT is compatible with= MPX. >> >> > >> >> > 2. For 32-bit x86-64 (x32) and i386, PLT is changed to >> >> > >> >> > PLT0: push GOT[1] >> >> > jmp *GOT[2] >> >> > nop >> >> > ... >> >> > PLTn: endbr64 # endbr32 for i386. >> >> > push namen_reloc_index >> >> > jmp PLT0 >> >> > >> >> > together with the second PLT section: >> >> > >> >> > PLTn: endbr64 # endbr32 for i386. >> >> > jmp *GOT[namen_index] >> >> > nop >> >> > >> >> > BND prefix isn't used since MPX isn't supported on x32 and BND regi= sters >> >> > aren't used in parameter passing on i386. >> >> > >> >> >> >> There are 2 reasons for this 2-PLT scheme: >> >> >> >> 1. Provide compatibility with other tools that have an hardcoded lim= it of 16 >> >> bytes for an x86 PLT entry. >> > >> > >> > I don't think that the 2-PLT scheme actually provides compatibility wi= th existing tools. The new PLT uses different code instructions, and the us= age of the .plt section has changed as well. IIUC, foo@PLT is now resolved = to its entry in the second PLT instead of the first regular PLT. >> > >> > I know that some existing tools even crash if we change the PLT entry = size, so keeping the PLT entry size would at least keep them from crashing.= But I'd think compatibility means more than that. >> > >> >> We are doing the best we can. >> >> >> 2. Improve code cache locality: since most of the instructions in .p= lt would be >> >> executed only the first time a symbol is resolved they would waste sp= ace in >> >> the cache and, by having a .plt.sec, only instructions that are often= executed >> >> would be cached. >> > >> > >> > This is personally much more convincing answer than keeping the compat= ibility. The PLT section could be hot, and separating hot code from relativ= ely cold code could have an performance impact. But do you know how much is= the impact? I wonder if there's a measurable difference if you simply exte= nd the PLT size to 32-byte. >> > >> >> We don't have such data. > > > Then it could be a premature optimization. The single PLT scheme would be= undeniably much simpler, so unless it is shown to not work, we probably sh= ouldn't have splitted a PLT into two, no? > Simpler to implement, yes. We designed it with performance in mind. We have implemented it many years ago starting from MPX. It shouldn't be changed just because it is "hard" to implement. --=20 H.J.