From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E21D7C433E0 for ; Fri, 31 Jul 2020 18:31:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D098C21744 for ; Fri, 31 Jul 2020 18:31:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387791AbgGaSbx (ORCPT ); Fri, 31 Jul 2020 14:31:53 -0400 Received: from foss.arm.com ([217.140.110.172]:36014 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730040AbgGaSbw (ORCPT ); Fri, 31 Jul 2020 14:31:52 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C0C9130E; Fri, 31 Jul 2020 11:31:51 -0700 (PDT) Received: from C02TD0UTHF1T.local (unknown [10.57.4.61]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 48D163F71F; Fri, 31 Jul 2020 11:31:49 -0700 (PDT) Date: Fri, 31 Jul 2020 19:31:46 +0100 From: Mark Rutland To: "Madhavan T. Venkataraman" Cc: Andy Lutomirski , Kernel Hardening , Linux API , linux-arm-kernel , Linux FS Devel , linux-integrity , LKML , LSM List , Oleg Nesterov , X86 ML Subject: Re: [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor Message-ID: <20200731183146.GD67415@C02TD0UTHF1T.local> References: <20200728131050.24443-1-madvenka@linux.microsoft.com> <6540b4b7-3f70-adbf-c922-43886599713a@linux.microsoft.com> <46a1adef-65f0-bd5e-0b17-54856fb7e7ee@linux.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46a1adef-65f0-bd5e-0b17-54856fb7e7ee@linux.microsoft.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 31, 2020 at 12:13:49PM -0500, Madhavan T. Venkataraman wrote: > On 7/30/20 3:54 PM, Andy Lutomirski wrote: > > On Thu, Jul 30, 2020 at 7:24 AM Madhavan T. Venkataraman > > wrote: > Dealing with multiple architectures > ----------------------------------------------- > > One good reason to use trampfd is multiple architecture support. The > trampoline table in a code page approach is neat. I don't deny that at > all. But my question is - can it be used in all cases? > > It requires PC-relative data references. I have not worked on all architectures. > So, I need to study this. But do all ISAs support PC-relative data references? Not all do, but pretty much any recent ISA will as it's a practical necessity for fast position-independent code. > Even in an ISA that supports it, there would be a maximum supported offset > from the current PC that can be reached for a data reference. That maximum > needs to be at least the size of a base page in the architecture. This is because > the code page and the data page need to be separate for security reasons. > Do all ISAs support a sufficiently large offset? ISAs with pc-relative addessing can usually generate PC-relative addresses into a GPR, from which they can apply an arbitrarily large offset. > When the kernel generates the code for a trampoline, it can hard code data values > in the generated code itself so it does not need PC-relative data referencing. > > And, for ISAs that do support the large offset, we do have to implement and > maintain the code page stuff for different ISAs for each application and library > if we did not use trampfd. Trampoline code is architecture specific today, so I don't see that as a major issue. Common structural bits can probably be shared even if the specifid machine code cannot. [...] > Security > ----------- > > With the user level trampoline table approach, the data part of the trampoline table > can be hacked by an attacker if an application has a vulnerability. Specifically, the > target PC can be altered to some arbitrary location. Trampfd implements an > "Allowed PCS" context. In the libffi changes, I have created a read-only array of > all ABI handlers used in closures for each architecture. This read-only array > can be used to restrict the PC values for libffi trampolines to prevent hacking. > > To generalize, we can implement security rules/features if the trampoline > object is in the kernel. I don't follow this argument. If it's possible to statically define that in the kernel, it's also possible to do that in userspace without any new kernel support. [...] > Trampfd is a framework that can be used to implement multiple things. May be, > a few of those things can also be implemented in user land itself. But I think having > just one mechanism to execute dynamic code objects is preferable to having > multiple mechanisms not standardized across all applications. In abstract, having a common interface sounds nice, but in practice elements of this are always architecture-specific (e.g. interactiosn with HW CFI), and that common interface can result in more pain as it doesn't fit naturally into the context that ISAs were designed for (e.g. where control-flow instructions are extended with new semantics). It also meass that you can't share the rough approach across OSs which do not implement an identical mechanism, so for code abstracting by ISA first, then by platform/ABI, there isn't much saving. Thanks, Mark. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 35C46C433E0 for ; Fri, 31 Jul 2020 18:33:14 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0819422B3F for ; Fri, 31 Jul 2020 18:33:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="TwDG4PXA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0819422B3F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=hlGa99c5IoT1JCFzgLkXG8A9P0aafjdWYnP9k0GlZrI=; b=TwDG4PXA3lIAZpoJLHKK/3Cj+ Zlh3UkixGvbPzGn+mtDIxmj4h3tExwBdLZPfZ135aBajtWkqOb1iAFY3LEmfNyjhcaHoWBLBAt9GD O5p64SVayGU5nhArohpsc6RiZ0jJthlju0Wg3GbNFB+MwmsFhtpw83hEQTEhM+IaLXZX39581UW4b SLlljwd1U40NR9qOIwuxxvm18sQYuJa+q9l9hrYJWt4MQsA7GcV8SA6UDb/T/QWqwz4cf24rHKEcF cL3+mg6RtazIIk5S9J738jKUjWC73lVeoGDQeG9JDNA/HglaFGav6QlXCOoF5bLD0huNAl6/yKZMF roX6IF4XQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k1Zow-0004Nd-Qo; Fri, 31 Jul 2020 18:31:54 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k1Zou-0004Ma-C8 for linux-arm-kernel@lists.infradead.org; Fri, 31 Jul 2020 18:31:53 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C0C9130E; Fri, 31 Jul 2020 11:31:51 -0700 (PDT) Received: from C02TD0UTHF1T.local (unknown [10.57.4.61]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 48D163F71F; Fri, 31 Jul 2020 11:31:49 -0700 (PDT) Date: Fri, 31 Jul 2020 19:31:46 +0100 From: Mark Rutland To: "Madhavan T. Venkataraman" Subject: Re: [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor Message-ID: <20200731183146.GD67415@C02TD0UTHF1T.local> References: <20200728131050.24443-1-madvenka@linux.microsoft.com> <6540b4b7-3f70-adbf-c922-43886599713a@linux.microsoft.com> <46a1adef-65f0-bd5e-0b17-54856fb7e7ee@linux.microsoft.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <46a1adef-65f0-bd5e-0b17-54856fb7e7ee@linux.microsoft.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200731_143152_599248_5D8EC95D X-CRM114-Status: GOOD ( 26.18 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kernel Hardening , Linux API , X86 ML , LKML , Oleg Nesterov , LSM List , Andy Lutomirski , Linux FS Devel , linux-integrity , linux-arm-kernel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Jul 31, 2020 at 12:13:49PM -0500, Madhavan T. Venkataraman wrote: > On 7/30/20 3:54 PM, Andy Lutomirski wrote: > > On Thu, Jul 30, 2020 at 7:24 AM Madhavan T. Venkataraman > > wrote: > Dealing with multiple architectures > ----------------------------------------------- > > One good reason to use trampfd is multiple architecture support. The > trampoline table in a code page approach is neat. I don't deny that at > all. But my question is - can it be used in all cases? > > It requires PC-relative data references. I have not worked on all architectures. > So, I need to study this. But do all ISAs support PC-relative data references? Not all do, but pretty much any recent ISA will as it's a practical necessity for fast position-independent code. > Even in an ISA that supports it, there would be a maximum supported offset > from the current PC that can be reached for a data reference. That maximum > needs to be at least the size of a base page in the architecture. This is because > the code page and the data page need to be separate for security reasons. > Do all ISAs support a sufficiently large offset? ISAs with pc-relative addessing can usually generate PC-relative addresses into a GPR, from which they can apply an arbitrarily large offset. > When the kernel generates the code for a trampoline, it can hard code data values > in the generated code itself so it does not need PC-relative data referencing. > > And, for ISAs that do support the large offset, we do have to implement and > maintain the code page stuff for different ISAs for each application and library > if we did not use trampfd. Trampoline code is architecture specific today, so I don't see that as a major issue. Common structural bits can probably be shared even if the specifid machine code cannot. [...] > Security > ----------- > > With the user level trampoline table approach, the data part of the trampoline table > can be hacked by an attacker if an application has a vulnerability. Specifically, the > target PC can be altered to some arbitrary location. Trampfd implements an > "Allowed PCS" context. In the libffi changes, I have created a read-only array of > all ABI handlers used in closures for each architecture. This read-only array > can be used to restrict the PC values for libffi trampolines to prevent hacking. > > To generalize, we can implement security rules/features if the trampoline > object is in the kernel. I don't follow this argument. If it's possible to statically define that in the kernel, it's also possible to do that in userspace without any new kernel support. [...] > Trampfd is a framework that can be used to implement multiple things. May be, > a few of those things can also be implemented in user land itself. But I think having > just one mechanism to execute dynamic code objects is preferable to having > multiple mechanisms not standardized across all applications. In abstract, having a common interface sounds nice, but in practice elements of this are always architecture-specific (e.g. interactiosn with HW CFI), and that common interface can result in more pain as it doesn't fit naturally into the context that ISAs were designed for (e.g. where control-flow instructions are extended with new semantics). It also meass that you can't share the rough approach across OSs which do not implement an identical mechanism, so for code abstracting by ISA first, then by platform/ABI, there isn't much saving. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel