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=-7.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 F2AEFC07E95 for ; Fri, 2 Jul 2021 22:44:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CAF716140E for ; Fri, 2 Jul 2021 22:44:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233265AbhGBWrR (ORCPT ); Fri, 2 Jul 2021 18:47:17 -0400 Received: from mail.kernel.org ([198.145.29.99]:39062 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233249AbhGBWrP (ORCPT ); Fri, 2 Jul 2021 18:47:15 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 88B1D61369; Fri, 2 Jul 2021 22:44:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1625265883; bh=VAS+i7j9RsZ5DMKojNBUf0k3To0kIZtOvo7yvM1oi8w=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=dD0DozhQq7Qa778vxZIqWGs+qXclDLvCdjAF/3bHkz1/HbJEX8RMbAqV7L08WQ3D9 p5TQhcRdav3lunVo3DljPtUD5d/CX/y/A+ybJW8U7+WsIFZeV5AFu9lhICMuRGJhzo 2iUu5aPzwJtW1ZipB4zChrDyLLqTOt2AKk5Mub4GgU40xW8Xn/IDdiO5MIuOTEK8Vm ssM7dNIyHlzjgvHGDabsNNa5E0qmSUEC5Qn/7Iu0SaBXuU1YqwxEBbOV6mp5bqzb7Y 4i0QQ2mcNWbS1oRiPTiRM+Tyubz2xmwDHty6m2wBCw9zHO3ehs09NwTwiDYxLspJhf /e6zPWovD4/Bw== Subject: Re: [PATCH 0/4 POC] Allow executing code and syscalls in another address space To: Andrei Vagin , linux-kernel@vger.kernel.org, linux-api@vger.kernel.org Cc: linux-um@lists.infradead.org, criu@openvz.org, avagin@google.com, Andrew Morton , Anton Ivanov , Christian Brauner , Dmitry Safonov <0x7f454c46@gmail.com>, Ingo Molnar , Jeff Dike , Mike Rapoport , Michael Kerrisk , Oleg Nesterov , Peter Zijlstra , Richard Weinberger , Thomas Gleixner References: <20210414055217.543246-1-avagin@gmail.com> From: Andy Lutomirski Message-ID: <6073e4c6-6fe8-0448-4586-5d04d7154164@kernel.org> Date: Fri, 2 Jul 2021 15:44:41 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210414055217.543246-1-avagin@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/13/21 10:52 PM, Andrei Vagin wrote: > process_vm_exec has two modes: > > * Execute code in an address space of a target process and stop on any > signal or system call. We already have a perfectly good context switch mechanism: context switches. If you execute code, you are basically guaranteed to be subject to being hijacked, which means you pretty much can't allow syscalls. But there's a lot of non-syscall state, and I think context switching needs to be done with extreme care. (Just as example, suppose you switch mms, then set %gs to point to the LDT, then switch back. Now you're in a weird state. With %ss the plot is a bit thicker. And there are emulated vsyscalls and such.) If you, PeterZ, and the UMCG could all find an acceptable, efficient way to wake-and-wait so you can switch into an injected task in the target process and switch back quickly, then I think a much nicer solution will become available. > > * Execute a system call in an address space of a target process. I could get behind this, but there are plenty of cans of worms to watch out for. Serious auditing would be needed. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lzRtr-004Bjy-PC for linux-um@lists.infradead.org; Fri, 02 Jul 2021 22:44:45 +0000 Subject: Re: [PATCH 0/4 POC] Allow executing code and syscalls in another address space References: <20210414055217.543246-1-avagin@gmail.com> From: Andy Lutomirski Message-ID: <6073e4c6-6fe8-0448-4586-5d04d7154164@kernel.org> Date: Fri, 2 Jul 2021 15:44:41 -0700 MIME-Version: 1.0 In-Reply-To: <20210414055217.543246-1-avagin@gmail.com> Content-Language: en-US List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-um" Errors-To: linux-um-bounces+geert=linux-m68k.org@lists.infradead.org To: Andrei Vagin , linux-kernel@vger.kernel.org, linux-api@vger.kernel.org Cc: linux-um@lists.infradead.org, criu@openvz.org, avagin@google.com, Andrew Morton , Anton Ivanov , Christian Brauner , Dmitry Safonov <0x7f454c46@gmail.com>, Ingo Molnar , Jeff Dike , Mike Rapoport , Michael Kerrisk , Oleg Nesterov , Peter Zijlstra , Richard Weinberger , Thomas Gleixner On 4/13/21 10:52 PM, Andrei Vagin wrote: > process_vm_exec has two modes: > > * Execute code in an address space of a target process and stop on any > signal or system call. We already have a perfectly good context switch mechanism: context switches. If you execute code, you are basically guaranteed to be subject to being hijacked, which means you pretty much can't allow syscalls. But there's a lot of non-syscall state, and I think context switching needs to be done with extreme care. (Just as example, suppose you switch mms, then set %gs to point to the LDT, then switch back. Now you're in a weird state. With %ss the plot is a bit thicker. And there are emulated vsyscalls and such.) If you, PeterZ, and the UMCG could all find an acceptable, efficient way to wake-and-wait so you can switch into an injected task in the target process and switch back quickly, then I think a much nicer solution will become available. > > * Execute a system call in an address space of a target process. I could get behind this, but there are plenty of cans of worms to watch out for. Serious auditing would be needed. _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um