From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by sourceware.org (Postfix) with ESMTP id B1B38386F00E for ; Fri, 29 Jan 2021 02:38:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B1B38386F00E Received: from [192.168.254.32] (unknown [47.187.219.45]) by linux.microsoft.com (Postfix) with ESMTPSA id EDF7320B7192; Thu, 28 Jan 2021 18:38:50 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com EDF7320B7192 Subject: Re: [RFC PATCH v3 2/5] x86: Support for Static Trampolines To: DJ Delorie Cc: libffi-discuss@sourceware.org References: From: "Madhavan T. Venkataraman" Message-ID: Date: Thu, 28 Jan 2021 20:38:49 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-20.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, ENV_AND_HDR_SPF_MATCH, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL 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: libffi-discuss@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libffi-discuss mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 02:38:53 -0000 On 1/28/21 8:09 PM, DJ Delorie wrote: > "Madhavan T. Venkataraman" writes: >> So, the definition is like this: >> >> #if !defined(GENERATE_LIBFFI_MAP) && defined(__ASSEMBLER__) \ >> && defined(__CET__) >> # include >> # define _CET_NOTRACK notrack >> #else >> # define _CET_ENDBR >> # define _CET_NOTRACK >> #endif >> >> Where we include cet.h, CET_ENDBR may still be defined either >> as endbr64 or empty depending on __CET__ & 1 being non-zero or >> zero, right? >> >> So, would something like this work? > > I suspect you only need one trampoline template, with __CET_ENDBR in it. Use > .align instead of hardcoding the right number of NOPs, and other logic > to figure out the repeat counts. It's safe to execute endbr64 when CET > is not enabled. > Yes. But the problem I ran into is that if libffi is compiled with old compilers that have not yet been updated for Intel CET, the builds fail because the assembler cannot recognize endbr64 and endbr32. This happened in CI testing. In the previous version, I had the endbr64 in the code like you suggested. As for the repeat count, here is the reason. I need to pack as many trampolines as possible in a page to conserve memory. I can do this in one of three ways: 1. Map an anon page and copy the template multiple times into the page creating a code table. This is only possible if the security settings allow anon memory to be mapped with exec permissions. 2. Create a file and write the template multiple times into the file and map the file with executable permissions. Again, security settings must allow it. They do today. But allowing temp files to be mapped with exec permissions presents a security problem. That will be addressed in Linux. Microsoft has submitted a Linux Security Module implementation which will only allow a file to be mapped with exec permissions if the file is a signed file and the sign can be verified. Temp files will not have that. In our case, we are only writing a read-only buffer in the text segment into the temp file. So, it does not really pose a security problem in the sense that a hacker cannot modify anything. But the kernel does not know that. It may blindly prevent the mapping of a temp file with exec permissions because of its inability to validate the contents. Because of this reason, I use the temp file approach as a fallback method if the 3rd method below fails. 3. Create a code table like I have done and map it directly from the text segment. With the code table, the .align will not work because of the repeat of the code sequence. Hence, the nops. I know it is not pretty. But this is my justification for that. Madhavan