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.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 36E8FC4363D for ; Wed, 23 Sep 2020 14:41:11 +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 E4B22206FB for ; Wed, 23 Sep 2020 14:41:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="3ZsBZvaC"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="G+dmkEqP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E4B22206FB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.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:MIME-Version:Message-ID:In-Reply-To:Date:References: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=E5vsKRVxVvtmgiTTcv4EdqjiEKaE1jfSvKq07ovxybY=; b=3ZsBZvaCMP9Id3hf9ZIsEY9+t aM7gw3nEbELJeJpQK+chlzvSofHnXdCWWkHLB7mFI45Ms/1mOnyvCzaAz3bdkeTM1cnTPofFhJi4y j68PquHtE2l1yfc0pbUNieIvJdrAvblXP3TsJFoV7HltYnSdFcp6VHu2jBSMSdGBn+XfMFPRAyQKt pA+RO3iIMLT2qwj2NM4pr3djZz1nOvBOJhs5vliWDFhWg7K5Pr57TRy24uj/mFnpkImQAKMWc5cw6 BOSShWSzJV+nmYCVWIGe15KcJUOjzNKzenANxL9JGrsfk+oAUNjcWqWe+HMjASpvK8cw9LDciDy8x BjHOSW9Vg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kL5w1-0003B6-6z; Wed, 23 Sep 2020 14:39:53 +0000 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kL5vx-00038o-7S for linux-arm-kernel@lists.infradead.org; Wed, 23 Sep 2020 14:39:50 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1600871988; 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=XtUNJYHV2J1JZ6JLBA0jisxCSujCzEq2vD80O/D6hKQ=; b=G+dmkEqPJBi3f5i7FcUcaVulmRYMAH2y73HVTLnvN6Mb3DmCloP3XKtaNvgoBj2RDKbHwA 2MWENmDITUuUSD8/OUY1HqonbmMY3rVqddRf32kXbvH+xrq0lAzmXKun8FRQVr+oNDgv5a 8Zj2hNFefaykwdvpC11DhMr7gX9oNk0= 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-497-Ai1jqBmFMUa4zYresSj0Pg-1; Wed, 23 Sep 2020 10:39:44 -0400 X-MC-Unique: Ai1jqBmFMUa4zYresSj0Pg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CBF2018A2249; Wed, 23 Sep 2020 14:39:40 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-114-108.ams2.redhat.com [10.36.114.108]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 147BA7882D; Wed, 23 Sep 2020 14:39:32 +0000 (UTC) From: Florian Weimer To: Solar Designer Subject: Re: [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor References: <20200922215326.4603-1-madvenka@linux.microsoft.com> <20200923081426.GA30279@amd> <20200923091456.GA6177@openwall.com> Date: Wed, 23 Sep 2020 16:39:31 +0200 In-Reply-To: <20200923091456.GA6177@openwall.com> (Solar Designer's message of "Wed, 23 Sep 2020 11:14:57 +0200") Message-ID: <87wo0ko8v0.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200923_103949_333620_4A4D5EFF X-CRM114-Status: GOOD ( 19.62 ) 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: mark.rutland@arm.com, Rich Felker , luto@kernel.org, kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, oleg@redhat.com, madvenka@linux.microsoft.com, mic@digikod.net, linux-security-module@vger.kernel.org, David.Laight@ACULAB.COM, Pavel Machek , 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 * Solar Designer: > While I share my opinion here, I don't mean that to block Madhavan's > work. I'd rather defer to people more knowledgeable in current userland > and ABI issues/limitations and plans on dealing with those, especially > to Florian Weimer. I haven't seen Florian say anything specific for or > against Madhavan's proposal, and I'd like to. (Have I missed that?) There was a previous discussion, where I provided feedback (not much different from the feedback here, given that the mechanism is mostly the same). I think it's unnecessary for the libffi use case. Precompiled code can be loaded from disk because the libffi trampolines are so regular. On most architectures, it's not even the code that's patched, but some of the data driving it, which happens to be located on the same page due to a libffi quirk. The libffi use case is a bit strange anyway: its trampolines are type-generic, and the per-call adjustment is data-driven. This means that once you have libffi in the process, you have a generic data-to-function-call mechanism available that can be abused (it's even fully CET compatible in recent versions). And then you need to look at the processes that use libffi. A lot of them contain bytecode interpreters, and those enable data-driven arbitrary code execution as well. I know that there are efforts under way to harden Python, but it's going to be tough to get to the point where things are still difficult for an attacker once they have the ability to make mprotect calls. It was pointed out to me that libffi is doing things wrong, and the trampolines should not be type-generic, but generated so that they match the function being called. That is, the marshal/unmarshal code would be open-coded in the trampoline, rather than using some generic mechanism plus run-time dispatch on data tables describing the function type. That is a very different design (and typically used by compilers (JIT or not JIT) to implement native calls). Mapping some code page with a repeating pattern would no longer work to defeat anti-JIT measures because it's closer to real JIT. I don't know if kernel support could make sense in this context, but it would be a completely different patch. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel