Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp704119pxk; Wed, 23 Sep 2020 13:54:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzv4eGN5l6q1swqEiYjrvjbKBYbDY5I4Pz0MLFpXa3og5NZKiZMcM+SH+x3c9VkJ7HPnxnt X-Received: by 2002:a50:fc91:: with SMTP id f17mr1214681edq.319.1600894448669; Wed, 23 Sep 2020 13:54:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600894448; cv=none; d=google.com; s=arc-20160816; b=lZZdlyBkEoDUsuZmnhS83GPDfZ8L591wGlixnrYYyZe/B3YRHtZFEB6X9vaP6ybZx8 +0JackljFTsc/GWUNWvtAWoGXyxlXTk9WWAiz0IRlkG2dNiS6z8PMxA74E0a//A6sczi eItlP8COOfIOvwU+BI+IbkCDVmp1uvE/iZkVXt+ank8kF1C2U7v4BRNxorFW6UjiY+ZW zy153YX9B0RyOhN04tFNKqJF34Eb6nB1GjozMtr3U7IBh99OR7BvNPcNYKx8TvlJaQeA YBedD7Gtb2m6R3UuflW5gHuOPDRyXto431QcwT8ZFyBc4f5FH1T9O390TOT6wE3DGyfR de4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=UH2rziB/GHPuYZZMR6ZB/NL6iOGrBXcjdAO3AZtNawQ=; b=CEU+KzfgVFgSxX/jqUaD3dUiEU1w8OttQ2hnlp4wV2eKC+2OKQXtPfc6DnaTAyEBdJ c+RqHTOh3yOGsfVd9/qyA21QqLh8Ed91n2aUpFElTYTYgO9nRYu6EMD/+Dm2TFIHOnB5 vAoRaA5n3DF/J7/axr6V9oydYmujUi1qrKddwim3ZFHJSaJTdXpYcQtTD1qPXoLcQUob 2YKkUimGE8INjZMvLGKKqelI3kFhN/S0craJnGepClUYTQNXZk9FErmoWQ+q18nFKRkM x01Elcq/fu2nMjrKeueYVii7Bc2LmsPtmNLSrcrQvmEyFSHGR9xanONph0W/y2j7NAly cA6Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id yc15si753776ejb.674.2020.09.23.13.53.45; Wed, 23 Sep 2020 13:54:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726806AbgIWUwC (ORCPT + 99 others); Wed, 23 Sep 2020 16:52:02 -0400 Received: from jabberwock.ucw.cz ([46.255.230.98]:33862 "EHLO jabberwock.ucw.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726265AbgIWUwC (ORCPT ); Wed, 23 Sep 2020 16:52:02 -0400 Received: by jabberwock.ucw.cz (Postfix, from userid 1017) id 2992C1C0BB6; Wed, 23 Sep 2020 22:51:57 +0200 (CEST) Date: Wed, 23 Sep 2020 22:51:56 +0200 From: Pavel Machek To: "Madhavan T. Venkataraman" Cc: 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, luto@kernel.org, David.Laight@ACULAB.COM, fweimer@redhat.com, mark.rutland@arm.com, mic@digikod.net Subject: Re: [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor Message-ID: <20200923205156.GA12034@duo.ucw.cz> References: <210d7cd762d5307c2aa1676705b392bd445f1baa> <20200922215326.4603-1-madvenka@linux.microsoft.com> <20200923084232.GB30279@amd> <34257bc9-173d-8ef9-0c97-fb6bd0f69ecb@linux.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline In-Reply-To: <34257bc9-173d-8ef9-0c97-fb6bd0f69ecb@linux.microsoft.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > >> Scenario 2 > >> ---------- > >> > >> We know what code we need in advance. User trampolines are a good exam= ple of > >> this. It is possible to define such code statically with some help fro= m the > >> kernel. > >> > >> This RFC addresses (2). (1) needs a general purpose trusted code gener= ator > >> and is out of scope for this RFC. > >=20 > > 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.= =20 > >=20 > > And as you noted, we don't have "a general purpose trusted code > > generator" for our systems. > >=20 > > I believe you should simply delete confusing "introduction" and > > provide details of super-secure system where your patches would be > > useful, instead. >=20 > This RFC talks about converting dynamic code (which cannot be authenticat= ed) > to static code that can be authenticated using signature verification. Th= at > is the scope of this RFC. >=20 > If I have not been clear before, by dynamic code, I mean machine code tha= t is > dynamic in nature. Scripts are beyond the scope of this RFC. >=20 > Also, malware compiled from sources is not dynamic code. That is orthogon= al > to this RFC. If such malware has a valid signature that the kernel permit= s its > execution, we have a systemic problem. >=20 > I am not saying that script authentication or compiled malware are not pr= oblems. > 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. Well, you don't have to solve all problems at once. But solutions have to exist, and AFAIK in this case they don't. You are armoring doors, but ignoring open windows. Or very probably you are thinking about something different than normal desktop distros (Debian 10). Because on my systems, I have python, gdb and gcc... It would be nice to specify what other pieces need to be present for this to make sense -- because it makes no sense on Debian 10. Best regards, Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --45Z9DzgjV8m4Oswq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQRPfPO7r0eAhk010v0w5/Bqldv68gUCX2u1bAAKCRAw5/Bqldv6 8ov1AJ9oh8sVA5W7qErLEsJzifoDuHM8DACgh6w28VCKvVj+dLDCdmUuI6zKsgc= =0Viq -----END PGP SIGNATURE----- --45Z9DzgjV8m4Oswq--