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.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 11965C433DF for ; Wed, 29 Jul 2020 05:17:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E1B2320663 for ; Wed, 29 Jul 2020 05:17:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1595999822; bh=qItqwNi4q4ELXpJAVlv3H8dC/ihmulIDrwoa1DDcrFY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=golpJlf77YVWmMSFx6xvZooWm5jMACd5Iq2YnWtzdAMS1CXWceCR7S9LpJ7bRZQpG +Aqs09j4PxvxHMv7Ki0JEaXR4ISNl20yHRbbRfdt/YDcay2QiZTq3xKdjdu8IrqgDR yyaKAw372LvXvsT5/GV3XvezbtfJ8eBEBH2F5AXs= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726944AbgG2FRA (ORCPT ); Wed, 29 Jul 2020 01:17:00 -0400 Received: from mail.kernel.org ([198.145.29.99]:47524 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726880AbgG2FQ7 (ORCPT ); Wed, 29 Jul 2020 01:16:59 -0400 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E826621D95 for ; Wed, 29 Jul 2020 05:16:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1595999819; bh=qItqwNi4q4ELXpJAVlv3H8dC/ihmulIDrwoa1DDcrFY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=k2/ypYf8chH29waA/oS7FzUjhmqJvZsAK5yreLc+JnHHzlqaz9vnEqabE+qyemEMh V59mmT0x99Zz7xAAr4mzDnLpnXyxu10GUK80PkfmZzTfRw0ApQRzkJVmfxPNtOL+Nt orHtR8IzwwnOF1rKVTvLOZzzbUFBmX6T//Qhyjrc= Received: by mail-wm1-f44.google.com with SMTP id k20so1616288wmi.5 for ; Tue, 28 Jul 2020 22:16:58 -0700 (PDT) X-Gm-Message-State: AOAM532/KXNbuw+hurbZhkrbVJ/u2gH0qJTnXCyEKRMT2vIbul15Hn2y 6FX878u4o3WwvOW1N33ZGQHvu+dGbjchYfPsljh74g== X-Google-Smtp-Source: ABdhPJyc8ExWo5/AVhgh7lVVbcBRbBl+yZD/a1oDf2lJ2rOxAoDZo7htpcvpKEGk9rvSh0Xh0NAF4mmPRBSSCBjw09E= X-Received: by 2002:a1c:7511:: with SMTP id o17mr7308351wmc.49.1595999817430; Tue, 28 Jul 2020 22:16:57 -0700 (PDT) MIME-Version: 1.0 References: <20200728131050.24443-1-madvenka@linux.microsoft.com> <81d744c0-923e-35ad-6063-8b186f6a153c@linux.microsoft.com> In-Reply-To: <81d744c0-923e-35ad-6063-8b186f6a153c@linux.microsoft.com> From: Andy Lutomirski Date: Tue, 28 Jul 2020 22:16:45 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor To: "Madhavan T. Venkataraman" Cc: Andy Lutomirski , David Laight , "kernel-hardening@lists.openwall.com" , "linux-api@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-fsdevel@vger.kernel.org" , "linux-integrity@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-security-module@vger.kernel.org" , "oleg@redhat.com" , "x86@kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 28, 2020 at 10:40 AM Madhavan T. Venkataraman wrote: > > > > On 7/28/20 12:16 PM, Andy Lutomirski wrote: > > On Tue, Jul 28, 2020 at 9:32 AM Madhavan T. Venkataraman > wrote: > > Thanks. See inline.. > > On 7/28/20 10:13 AM, David Laight wrote: > > From: madvenka@linux.microsoft.com > > Sent: 28 July 2020 14:11 > > ... > > The kernel creates the trampoline mapping without any permissions. When > the trampoline is executed by user code, a page fault happens and the > kernel gets control. The kernel recognizes that this is a trampoline > invocation. It sets up the user registers based on the specified > register context, and/or pushes values on the user stack based on the > specified stack context, and sets the user PC to the requested target > PC. When the kernel returns, execution continues at the target PC. > So, the kernel does the work of the trampoline on behalf of the > application. > > Isn't the performance of this going to be horrid? > > It takes about the same amount of time as getpid(). So, it is > one quick trip into the kernel. I expect that applications will > typically not care about this extra overhead as long as > they are able to run. > > What did you test this on? A page fault on any modern x86_64 system > is much, much, much, much slower than a syscall. > > > I tested it in on a KVM guest running Ubuntu. So, when you say > that a page fault is much slower, do you mean a regular page > fault that is handled through the VM layer? Here is the relevant code > in do_user_addr_fault(): I mean that x86 CPUs have reasonably SYSCALL and SYSRET instructions (the former is used for 64-bit system calls on Linux and the latter is mostly used to return from system calls), but hardware page fault delivery and IRET (used to return from page faults) are very slow. 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,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 08813C433DF for ; Wed, 29 Jul 2020 05:18:27 +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 C673920663 for ; Wed, 29 Jul 2020 05:18:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="qe8yRPut"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="k2/ypYf8" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C673920663 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Bco7bv96TYXiyZX9XdsyMXkttgQNHMs+AAAo1xTmOPI=; b=qe8yRPutMT9N6K6MDlhmO4bWv ma/dNH0MesegCdhYm6SLEQEloP6Njhor3UwB9//tjLRr1jE2ddHFKMCLzVunIJKPC4ZawyFzEXeui VG3xPiWlVgOHhquo1rOxps/T1YzKWCVy967MTOpocY2oScQ59aS2ITQoogGC8gp9eZxz4wGHqV7XV +wdOOGSnRHhND0oUjS4NdiF+xLrVYsv/60Qx9Q6Yqvm84K6LQkWAhE9hbQYUn5sgw7oWrmQsUhUBE 8JOfmt4zHUC+3AO5RYE2qVNRan04t6eJ6aJXiDlgDiDrbvCkenKrZPA2v3hGwEfBpjM9ZstKrQEO/ qfeFkRVDg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k0eSc-00040m-DG; Wed, 29 Jul 2020 05:17:02 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k0eSZ-0003zu-UR for linux-arm-kernel@lists.infradead.org; Wed, 29 Jul 2020 05:17:00 +0000 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E14B520825 for ; Wed, 29 Jul 2020 05:16:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1595999819; bh=qItqwNi4q4ELXpJAVlv3H8dC/ihmulIDrwoa1DDcrFY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=k2/ypYf8chH29waA/oS7FzUjhmqJvZsAK5yreLc+JnHHzlqaz9vnEqabE+qyemEMh V59mmT0x99Zz7xAAr4mzDnLpnXyxu10GUK80PkfmZzTfRw0ApQRzkJVmfxPNtOL+Nt orHtR8IzwwnOF1rKVTvLOZzzbUFBmX6T//Qhyjrc= Received: by mail-wm1-f47.google.com with SMTP id 3so1638871wmi.1 for ; Tue, 28 Jul 2020 22:16:58 -0700 (PDT) X-Gm-Message-State: AOAM532iAycSaQpXfJn+JG1q3pJ2x6eWt6VVSGaJDG/2e1o4dmRlo4F9 1LZ7UCut8+GSyPxBgh5yJDkpLRIvTHj3vsKAJTIOPA== X-Google-Smtp-Source: ABdhPJyc8ExWo5/AVhgh7lVVbcBRbBl+yZD/a1oDf2lJ2rOxAoDZo7htpcvpKEGk9rvSh0Xh0NAF4mmPRBSSCBjw09E= X-Received: by 2002:a1c:7511:: with SMTP id o17mr7308351wmc.49.1595999817430; Tue, 28 Jul 2020 22:16:57 -0700 (PDT) MIME-Version: 1.0 References: <20200728131050.24443-1-madvenka@linux.microsoft.com> <81d744c0-923e-35ad-6063-8b186f6a153c@linux.microsoft.com> In-Reply-To: <81d744c0-923e-35ad-6063-8b186f6a153c@linux.microsoft.com> From: Andy Lutomirski Date: Tue, 28 Jul 2020 22:16:45 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor To: "Madhavan T. Venkataraman" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200729_011700_124114_F87A9DC2 X-CRM114-Status: GOOD ( 26.61 ) 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@lists.openwall.com" , "linux-api@vger.kernel.org" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "oleg@redhat.com" , "linux-security-module@vger.kernel.org" , David Laight , Andy Lutomirski , "linux-fsdevel@vger.kernel.org" , "linux-integrity@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" 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 Tue, Jul 28, 2020 at 10:40 AM Madhavan T. Venkataraman wrote: > > > > On 7/28/20 12:16 PM, Andy Lutomirski wrote: > > On Tue, Jul 28, 2020 at 9:32 AM Madhavan T. Venkataraman > wrote: > > Thanks. See inline.. > > On 7/28/20 10:13 AM, David Laight wrote: > > From: madvenka@linux.microsoft.com > > Sent: 28 July 2020 14:11 > > ... > > The kernel creates the trampoline mapping without any permissions. When > the trampoline is executed by user code, a page fault happens and the > kernel gets control. The kernel recognizes that this is a trampoline > invocation. It sets up the user registers based on the specified > register context, and/or pushes values on the user stack based on the > specified stack context, and sets the user PC to the requested target > PC. When the kernel returns, execution continues at the target PC. > So, the kernel does the work of the trampoline on behalf of the > application. > > Isn't the performance of this going to be horrid? > > It takes about the same amount of time as getpid(). So, it is > one quick trip into the kernel. I expect that applications will > typically not care about this extra overhead as long as > they are able to run. > > What did you test this on? A page fault on any modern x86_64 system > is much, much, much, much slower than a syscall. > > > I tested it in on a KVM guest running Ubuntu. So, when you say > that a page fault is much slower, do you mean a regular page > fault that is handled through the VM layer? Here is the relevant code > in do_user_addr_fault(): I mean that x86 CPUs have reasonably SYSCALL and SYSRET instructions (the former is used for 64-bit system calls on Linux and the latter is mostly used to return from system calls), but hardware page fault delivery and IRET (used to return from page faults) are very slow. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 D9191C433DF for ; Wed, 29 Jul 2020 05:17:19 +0000 (UTC) Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.kernel.org (Postfix) with SMTP id 3594520786 for ; Wed, 29 Jul 2020 05:17:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="k2/ypYf8" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3594520786 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernel-hardening-return-19486-kernel-hardening=archiver.kernel.org@lists.openwall.com Received: (qmail 30130 invoked by uid 550); 29 Jul 2020 05:17:12 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Received: (qmail 30109 invoked from network); 29 Jul 2020 05:17:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1595999819; bh=qItqwNi4q4ELXpJAVlv3H8dC/ihmulIDrwoa1DDcrFY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=k2/ypYf8chH29waA/oS7FzUjhmqJvZsAK5yreLc+JnHHzlqaz9vnEqabE+qyemEMh V59mmT0x99Zz7xAAr4mzDnLpnXyxu10GUK80PkfmZzTfRw0ApQRzkJVmfxPNtOL+Nt orHtR8IzwwnOF1rKVTvLOZzzbUFBmX6T//Qhyjrc= X-Gm-Message-State: AOAM5307zloSMUCPZQOleka+RdFQgzJ834TMjLIAW3FAV2Q+6NgKqLXA x+/eY8fIfSI11hwMwPtgZ3a4L4uqgZdXC9kmObJpFg== X-Google-Smtp-Source: ABdhPJyc8ExWo5/AVhgh7lVVbcBRbBl+yZD/a1oDf2lJ2rOxAoDZo7htpcvpKEGk9rvSh0Xh0NAF4mmPRBSSCBjw09E= X-Received: by 2002:a1c:7511:: with SMTP id o17mr7308351wmc.49.1595999817430; Tue, 28 Jul 2020 22:16:57 -0700 (PDT) MIME-Version: 1.0 References: <20200728131050.24443-1-madvenka@linux.microsoft.com> <81d744c0-923e-35ad-6063-8b186f6a153c@linux.microsoft.com> In-Reply-To: <81d744c0-923e-35ad-6063-8b186f6a153c@linux.microsoft.com> From: Andy Lutomirski Date: Tue, 28 Jul 2020 22:16:45 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor To: "Madhavan T. Venkataraman" Cc: Andy Lutomirski , David Laight , "kernel-hardening@lists.openwall.com" , "linux-api@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-fsdevel@vger.kernel.org" , "linux-integrity@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-security-module@vger.kernel.org" , "oleg@redhat.com" , "x86@kernel.org" Content-Type: text/plain; charset="UTF-8" On Tue, Jul 28, 2020 at 10:40 AM Madhavan T. Venkataraman wrote: > > > > On 7/28/20 12:16 PM, Andy Lutomirski wrote: > > On Tue, Jul 28, 2020 at 9:32 AM Madhavan T. Venkataraman > wrote: > > Thanks. See inline.. > > On 7/28/20 10:13 AM, David Laight wrote: > > From: madvenka@linux.microsoft.com > > Sent: 28 July 2020 14:11 > > ... > > The kernel creates the trampoline mapping without any permissions. When > the trampoline is executed by user code, a page fault happens and the > kernel gets control. The kernel recognizes that this is a trampoline > invocation. It sets up the user registers based on the specified > register context, and/or pushes values on the user stack based on the > specified stack context, and sets the user PC to the requested target > PC. When the kernel returns, execution continues at the target PC. > So, the kernel does the work of the trampoline on behalf of the > application. > > Isn't the performance of this going to be horrid? > > It takes about the same amount of time as getpid(). So, it is > one quick trip into the kernel. I expect that applications will > typically not care about this extra overhead as long as > they are able to run. > > What did you test this on? A page fault on any modern x86_64 system > is much, much, much, much slower than a syscall. > > > I tested it in on a KVM guest running Ubuntu. So, when you say > that a page fault is much slower, do you mean a regular page > fault that is handled through the VM layer? Here is the relevant code > in do_user_addr_fault(): I mean that x86 CPUs have reasonably SYSCALL and SYSRET instructions (the former is used for 64-bit system calls on Linux and the latter is mostly used to return from system calls), but hardware page fault delivery and IRET (used to return from page faults) are very slow.