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=-6.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 910B9C2D0A8 for ; Wed, 23 Sep 2020 18:57:50 +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 1783621D92 for ; Wed, 23 Sep 2020 18:57:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="wLclIIwH"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="qUdFn++L" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1783621D92 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.microsoft.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:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=56I/n1ron+ZmuS8F5aYKbiShDUc40M+9sV9J5X7/QMQ=; b=wLclIIwHn8gjK5u61K/vv5Pjr TWD+0Gq02dx2J5HsfvRKsXjztNT0QaQrCiWNuxKhzY/28ynkAVoXO8N+jbf9VAPuJ6xFxDDODIh2j 2tZndzAUGnlaJrLhxf+Z5sMPP2KPQhy/O+JzJKcPUeBTHCcuzo7Mk0SSeL/h8m8107uJXCFQOgEgK SLX5T94gvGidUq7OCx+ed14tsB80DrN+rRGvHSolU+WYW/3P3PWwtDCGrJwh6argMyfxc+19YQgPZ vwY6Zb7KTqJGl4nFDomgv84YwR5MsjywPVKphTVfbfmFyeX3nqEJzfI2LgyGVFi6A/qPf0K4qod3R ER52tjrtw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kL9wO-00046s-Gx; Wed, 23 Sep 2020 18:56:32 +0000 Received: from linux.microsoft.com ([13.77.154.182]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kL9wK-00045o-TI for linux-arm-kernel@lists.infradead.org; Wed, 23 Sep 2020 18:56:29 +0000 Received: from [192.168.254.38] (unknown [47.187.206.220]) by linux.microsoft.com (Postfix) with ESMTPSA id 557EE20B7179; Wed, 23 Sep 2020 11:56:26 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 557EE20B7179 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1600887387; bh=uwZVH+hKIIVKFv+K1bPzJWqdSDUVXBp6JUcQYxnsRrI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=qUdFn++LAT4vA2tvu8K1c5Cl/qAqAfZdDZ89KrYyASfOsM4Xmiai4vXaT11vsEf1N 1jZlly6d5QA/+idswdCiva/H0kjaoiZ50IagxTZcPRY8FXTmEHeXrmRQm/DhxP8qz5 3adFTFMbP+ClvkbfYhD+L8lgHluLwPew8dbPIpzw= Subject: Re: [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor To: Pavel Machek References: <210d7cd762d5307c2aa1676705b392bd445f1baa> <20200922215326.4603-1-madvenka@linux.microsoft.com> <20200923084232.GB30279@amd> From: "Madhavan T. Venkataraman" Message-ID: <34257bc9-173d-8ef9-0c97-fb6bd0f69ecb@linux.microsoft.com> Date: Wed, 23 Sep 2020 13:56:25 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200923084232.GB30279@amd> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200923_145629_045161_E030883C X-CRM114-Status: GOOD ( 18.90 ) 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: fweimer@redhat.com, mark.rutland@arm.com, kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, oleg@redhat.com, mic@digikod.net, linux-security-module@vger.kernel.org, David.Laight@ACULAB.COM, luto@kernel.org, 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 9/23/20 3:42 AM, Pavel Machek wrote: > Hi! > >> Solution proposed in this RFC >> ============================= >> >> >From this RFC's perspective, there are two scenarios for dynamic code: >> >> Scenario 1 >> ---------- >> >> We know what code we need only at runtime. For instance, JIT code generated >> for frequently executed Java methods. Only at runtime do we know what >> methods need to be JIT compiled. Such code cannot be statically defined. It >> has to be generated at runtime. >> >> Scenario 2 >> ---------- >> >> We know what code we need in advance. User trampolines are a good example of >> this. It is possible to define such code statically with some help from the >> kernel. >> >> This RFC addresses (2). (1) needs a general purpose trusted code generator >> and is out of scope for this RFC. > > This is slightly less crazy talk than introduction talking about holes > in W^X. But it is very, very far from normal Unix system, where you > have selection of interpretters to run your malware on (sh, python, > awk, emacs, ...) and often you can even compile malware from sources. > > And as you noted, we don't have "a general purpose trusted code > generator" for our systems. > > I believe you should simply delete confusing "introduction" and > provide details of super-secure system where your patches would be > useful, instead. > > Best regards, > Pavel > This RFC talks about converting dynamic code (which cannot be authenticated) to static code that can be authenticated using signature verification. That is the scope of this RFC. If I have not been clear before, by dynamic code, I mean machine code that is dynamic in nature. Scripts are beyond the scope of this RFC. Also, malware compiled from sources is not dynamic code. That is orthogonal to this RFC. If such malware has a valid signature that the kernel permits its execution, we have a systemic problem. I am not saying that script authentication or compiled malware are not problems. I am just saying that this RFC is not trying to solve all of the security problems. It is trying to define one way to convert dynamic code to static code to address one class of problems. Madhavan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel