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=-5.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 8E2E0C433B4 for ; Wed, 14 Apr 2021 10:27:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6735F613B1 for ; Wed, 14 Apr 2021 10:27:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233511AbhDNK1u (ORCPT ); Wed, 14 Apr 2021 06:27:50 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:58491 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232235AbhDNK1s (ORCPT ); Wed, 14 Apr 2021 06:27:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1618396047; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=vMLyJy+yuIUeQ69Nie1nVj2ps7AR8ETn5DL2B4VvFQI=; b=JE8ws063FQoAIwfFCDHiF/5SIqJ3/seymoUwLVt6tG8bCgvywBs+lpMpOMSw5rUkaTAR48 +fgCULGhpQ2aRwrJZsUmMhKLrCYOCrGxvBcn70v1puUM5AfHy86XguuiGi7syzviuB+yd3 f9qdlaoajc2vXhH+V9iYVLmaF4Q2Wj4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-465-qkYKl8RuMciGaPIHYwMLdg-1; Wed, 14 Apr 2021 06:27:23 -0400 X-MC-Unique: qkYKl8RuMciGaPIHYwMLdg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 1EEBE8030C4; Wed, 14 Apr 2021 10:27:20 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-112-148.ams2.redhat.com [10.36.112.148]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8A5D41A86B; Wed, 14 Apr 2021 10:27:14 +0000 (UTC) From: Florian Weimer To: Andrei Vagin Cc: linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, linux-um@lists.infradead.org, criu@openvz.org, avagin@google.com, Andrew Morton , Andy Lutomirski , 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 Subject: Re: [PATCH 0/4 POC] Allow executing code and syscalls in another address space References: <20210414055217.543246-1-avagin@gmail.com> Date: Wed, 14 Apr 2021 12:27:28 +0200 In-Reply-To: <20210414055217.543246-1-avagin@gmail.com> (Andrei Vagin's message of "Tue, 13 Apr 2021 22:52:13 -0700") Message-ID: <87blahb1pr.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Andrei Vagin: > We already have process_vm_readv and process_vm_writev to read and write > to a process memory faster than we can do this with ptrace. And now it > is time for process_vm_exec that allows executing code in an address > space of another process. We can do this with ptrace but it is much > slower. > > = Use-cases = We also have some vaguely related within the same address space: running code on another thread, without modifying its stack, while it has signal handlers blocked, and without causing system calls to fail with EINTR. This can be used to implement certain kinds of memory barriers. It is also necessary to implement set*id with POSIX semantics in userspace. (Linux only changes the current thread credentials, POSIX requires process-wide changes.) We currently use a signal for set*id, but it has issues (it can be blocked, the signal could come from somewhere, etc.). We can't use signals for barriers because of the EINTR issue, and because the signal context is stored on the stack. Thanks, Florian