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.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 AB955C433E0 for ; Tue, 11 Aug 2020 12:42:48 +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 72FE920756 for ; Tue, 11 Aug 2020 12:42:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="OTCah2nF"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="PFQNuX5m" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 72FE920756 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=QeHXQwyvR8fb7WeyyVopm8DWy8GUwm2ns85nHYnINlg=; b=OTCah2nFGuDjcWPbpRTrdkeMQ 7jmCh95Fw1CdojMDcjIqN+Q3nRmQF33ZGa83mhfEuxOfkOh7T6Jg16OJRdLnNjUAcTAYio/kf0NoC JI7SCJik/GeDcIDwxr2yZazBvpx3LxdLX6DGePlQVbX14fbmZ1yoN88DucRq+0ik6d97PfOD12kar uQftr2ebb93vHD5i85Wnto5Gjj3NNjr3BZyAEi9iNIaoAVt8Ll5wyI0sdWjFy2pktIEwh8vYtPhPg kpzXZ5qcadMV4TemnTdtTXveb7/pLSTtlffVeeTiedz6I/PwYSiDVomhcZIA5gCwsFL5TZs2KDlV9 EQ7BKyzKQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k5Taj-0004kp-42; Tue, 11 Aug 2020 12:41:21 +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 1k5Tag-0004k4-Ih for linux-arm-kernel@lists.infradead.org; Tue, 11 Aug 2020 12:41:19 +0000 Received: from [192.168.254.32] (unknown [47.187.206.220]) by linux.microsoft.com (Postfix) with ESMTPSA id 7A2A120B4908; Tue, 11 Aug 2020 05:41:16 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 7A2A120B4908 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1597149677; bh=/01YYim8UON1WnW57/jtTiKZ9zMxYZQ09Mw9cbuIu4A=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=PFQNuX5mWMquO2HGENEzafqUyJUE7/be/jyBGj5BPS+LLzBuKDCp8oxu/gpMGiuzS 6nmE9EJ+VCIZo4ZznNZO0l1rypST2o/WGeVSn+KjlmzrdKh1od3CFRwpGX0UIvppY1 +3sGwRwS/5aecpkyVSZ45vXgzNz/7thzHMTdnYOE= Subject: Re: [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor To: Pavel Machek References: <20200728131050.24443-1-madvenka@linux.microsoft.com> <20200731180955.GC67415@C02TD0UTHF1T.local> <6236adf7-4bed-534e-0956-fddab4fd96b6@linux.microsoft.com> <20200804143018.GB7440@C02TD0UTHF1T.local> <20200808221748.GA1020@bug> From: "Madhavan T. Venkataraman" Message-ID: <6cca8eac-f767-b891-dc92-eaa7504a0e8b@linux.microsoft.com> Date: Tue, 11 Aug 2020 07:41:15 -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: <20200808221748.GA1020@bug> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200811_084118_869256_C010BC80 X-CRM114-Status: GOOD ( 20.36 ) 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 , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, oleg@redhat.com, linux-security-module@vger.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 8/8/20 5:17 PM, Pavel Machek wrote: > Hi! > >> Thanks for the lively discussion. I have tried to answer some of the >> comments below. > >>> There are options today, e.g. >>> >>> a) If the restriction is only per-alias, you can have distinct aliases >>> where one is writable and another is executable, and you can make it >>> hard to find the relationship between the two. >>> >>> b) If the restriction is only temporal, you can write instructions into >>> an RW- buffer, transition the buffer to R--, verify the buffer >>> contents, then transition it to --X. >>> >>> c) You can have two processes A and B where A generates instrucitons into >>> a buffer that (only) B can execute (where B may be restricted from >>> making syscalls like write, mprotect, etc). >> >> The general principle of the mitigation is W^X. I would argue that >> the above options are violations of the W^X principle. If they are >> allowed today, they must be fixed. And they will be. So, we cannot >> rely on them. > > Would you mind describing your threat model? > > Because I believe you are using model different from everyone else. > > In particular, I don't believe b) is a problem or should be fixed. It is a problem because a kernel that implements W^X properly will not allow it. It has no idea what has been done in userland. It has no idea that the user has checked and verified the buffer contents after transitioning the page to R--. > > I'll add d), application mmaps a file(R--), and uses write syscall to change > trampolines in it. > No matter how you do it, these are all user-level methods that can be hacked. The kernel cannot be sure that an attacker's code has not found its way into the file. >> b) This is again a violation. The kernel should refuse to give execute >> ???????? permission to a page that was writeable in the past and refuse to >> ???????? give write permission to a page that was executable in the past. > > Why? I don't know about the latter part. I guess I need to think about it. But the former is valid. When a page is RW-, a hacker could hack the page. Then it does not matter that the page is transitioned to R--. Again, the kernel cannot be sure that the user has verified the contents after R--. IMO, W^X needs to be enforced temporally as well. Madhavan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel