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 D249DC2D0A8 for ; Sat, 26 Sep 2020 15:56:49 +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 712FA21527 for ; Sat, 26 Sep 2020 15:56:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="QCJ4yhYv"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="DUBA2qNr" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 712FA21527 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=alum.mit.edu 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:References:Message-ID: Subject:To:Date:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=0wG5EFRs4eyFjKM1ZWt6F11euGZWDBvqm4ldtuO567U=; b=QCJ4yhYvXmBrOcC41aHZ5pJOp V9KW/VaMHxZNPAyNs1sXd4/Dlki34BNcM+ArrgBEVUmdcEx34h0uWgjyeefeuj0uJKSp5bgt+iSvw D8AAdiJ5rFNmiOtwZM28rOLoDzVMmEgltA/fNsApS9A+F2qO/GGNY7H7DPlwxBesuLiLGFbCXZAn+ /WH/tae9cDqBCe3VXqhfChdwaTljDUR6w6oQASEDIcmCGC/i42cwgluwUJOmQ5EQ/76HyFDzMuCAm hALFgyA2roI5wCSWRwVXkdWgkFpd21sTW9y1jB06kTb1EAdhS6KKMLDgGe/Vt91AvoS6vgHRWQtOf xnFAQdBdA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kMCXY-0006Q4-Mz; Sat, 26 Sep 2020 15:55:12 +0000 Received: from mail-qv1-xf43.google.com ([2607:f8b0:4864:20::f43]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kMCXU-0006P8-Uq for linux-arm-kernel@lists.infradead.org; Sat, 26 Sep 2020 15:55:09 +0000 Received: by mail-qv1-xf43.google.com with SMTP id cv8so3066223qvb.12 for ; Sat, 26 Sep 2020 08:55:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=9K+TORI1qzRkLGrmcb8ynRXJgkPPOWq5NVEpME43Yt0=; b=DUBA2qNrcI62cN5SQKIfv4SMlznZeSGX1APD1Z6GvGlZWsGRrmUjq3uBadgEJErWBu zqpNK/U3O1V+njEbNCndeHQ7rld7GORTIYOijvJ82Ouq7Ziw+vvmmPDvF8fOR5eLm0H2 5d/t92sr2C0UYwYYRVrOfhMN330RHnf6Z4aHyd6LhtdseZInb/ClO5LDp63lTdoUl+eT 25p2sxuemk0CMSERnc2jUNIT5S8m+LmRMSIbXjCWsAevDaxm1CmBSm+8jq/aX8ANG01v sLr8mJNPkiFoOaJSHZ0X5OvIw0kFFYHUMrFLidYgNS5OivgrGaGrvIYGIBl4C4/ui5t6 jV5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:date:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=9K+TORI1qzRkLGrmcb8ynRXJgkPPOWq5NVEpME43Yt0=; b=HfeRYDh+2arStmKU7rcBiGIpff9CcbEssPww1sanWSNvflNm+qnfDQ8/KTFu7ThTXe s32ZrFVQ/tNqdsnCmoGBfyUDxAyt6O++nr4nJc/wzJJW0E75IKks14AAdkh8rrevo8Ly 3EtRCoArv13ngWldSIHtuL5tkFTa4V4ENsurrnKDM0GDGOWLnZDlEI3x0sYHOx+YUtql AfUkhwS5gdNlRUQEijNBnXYyq2kwZp6yzDBuLbc7eHvIfnR6siDx+UrzS+Pl//49m6dm GRi/WtoOqSD3yvJmH3q4OLLsbpMts1mTh0OKqi4F8tzvOaD/Z9YjvuMX12uTOuhjHsuD DsRQ== X-Gm-Message-State: AOAM53338ck3OCYOG/CI+0SXhIeVEYZ/VAYr8X/G6DxV2WZnxjZns4Aq nNE9+lqFAzk9jGRoZqs+ZWEILML1ttpf6Q== X-Google-Smtp-Source: ABdhPJxfGgdFSQrEPU0DSDPMe2uIJ2q1rjb46XTTNZ8JMpjLFcZXIvIzBDa4vnln1Ydvdliysqgn2g== X-Received: by 2002:a05:6214:a03:: with SMTP id dw3mr3963031qvb.44.1601135705190; Sat, 26 Sep 2020 08:55:05 -0700 (PDT) Received: from rani.riverdale.lan ([2001:470:1f07:5f3::b55f]) by smtp.gmail.com with ESMTPSA id p29sm4635341qtu.68.2020.09.26.08.55.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 26 Sep 2020 08:55:04 -0700 (PDT) From: Arvind Sankar X-Google-Original-From: Arvind Sankar Date: Sat, 26 Sep 2020 11:55:02 -0400 To: "Madhavan T. Venkataraman" Subject: Re: [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor Message-ID: <20200926155502.GA930344@rani.riverdale.lan> References: <20200916150826.5990-1-madvenka@linux.microsoft.com> <87v9gdz01h.fsf@mid.deneb.enyo.de> <96ea02df-4154-5888-1669-f3beeed60b33@linux.microsoft.com> <20200923014616.GA1216401@rani.riverdale.lan> <20200923091125.GB1240819@rani.riverdale.lan> <20200923195147.GA1358246@rani.riverdale.lan> <2ed2becd-49b5-7e76-9836-6a43707f539f@linux.microsoft.com> <20200924234347.GA341645@rani.riverdale.lan> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200926_115509_003890_62B65CAC X-CRM114-Status: GOOD ( 43.60 ) 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, linux-security-module@vger.kernel.org, pavel@ucw.cz, kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, oleg@redhat.com, mic@digikod.net, Arvind Sankar , Florian Weimer , luto@kernel.org, linux-fsdevel@vger.kernel.org, linux-integrity@vger.kernel.org, David.Laight@ACULAB.COM, libffi-discuss@sourceware.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 Fri, Sep 25, 2020 at 05:44:56PM -0500, Madhavan T. Venkataraman wrote: > > > On 9/24/20 6:43 PM, Arvind Sankar wrote: > > > > The source PC will generally not be available if the compiler decided to > > tail-call optimize the call to the trampoline into a jump. > > > > This is still work in progress. But I am thinking that labels can be used. > So, if the code is: > > invoke_tramp: > (*tramp)(); > > then, invoke_tramp can be supplied as the calling PC. > > Similarly, labels can be used in assembly functions as well. > > Like I said, I have to think about this more. What I mean is that the kernel won't have access to the actual source PC. If I followed your v1 correctly, it works by making any branch to the trampoline code trigger a page fault. At this point, the PC has already been updated to the trampoline entry, so the only thing the fault handler can know is the return address on the top of the stack, which (a) might not be where the branch actually originated, either because it was a jump, or you've already been hacked and you got here using a ret; (b) is available to userspace anyway. > > > What's special about these trampolines anyway? Any indirect function > > call could have these same problems -- an attacker could have > > overwritten the pointer the same way, whether it's supposed to point to > > a normal function or it is the target of this trampoline. > > > > For making them a bit safer, userspace could just map the page holding > > the data pointers/destination address(es) as read-only after > > initialization. > > > > You need to look at version 1 of trampfd for how to do "allowed pcs". > As an example, libffi defines ABI handlers for every arch-ABI combo. > These ABI handler pointers could be placed in an array in .rodata. > Then, the array can be written into trampfd for setting allowed PCS. > When the target PC is set for a trampoline, the kernel will check > it against allowed PCs and reject it if it has been overwritten. I'm not asking how it's implemented. I'm asking what's the point? On a typical linux system, at least on x86, every library function call is an indirect branch. The protection they get is that the dynamic linker can map the pointer table read-only after initializing it. For the RO mapping, libffi could be mapping both the entire closure structure, as well as the structure that describes the arguments and return types of the function, read-only once they are initialized. For libffi, there are three indirect branches for every trampoline call with your suggested trampoline: one to get to the trampoline, one to jump to the handler, and one to call the actual user function. If we are particularly concerned about the trampoline to handler branch for some reason, we could just replace it with a direct branch: if the kernel was generating the code, there's no reason to allow the data pointer or code target to be changed after the trampoline was created. It can just hard-code them in the generated code and be done with it. Even with user-space trampolines, you can use a direct call. All you need is libffi-trampoline.so which contains a few thousand trampolines all jumping to one handler, which then decides what to do based on which trampoline was called. Sure libffi currently dispatches to one of 2-3 handlers based on the ABI, but there's no technical reason it couldn't dispatch to just one that handled all the ABIs, and the trampoline could be boiled down to just: endbr call handler ret > >> > >> In order to address the FFI_REGISTER ABI in libffi, we could use the secure > >> trampoline. In FFI_REGISTER, the data is pushed on the stack and the code > >> is jumped to without using any registers. > >> > >> As outlined in version 1, the kernel can push the data address on the stack > >> and write the code address into the PC and return to userland. > >> > >> For doing all of this, we need trampfd. > > > > We don't need this for FFI_REGISTER. I presented a solution that works > > in userspace. Even if you want to use a trampoline created by the > > kernel, there's no reason it needs to trap into the kernel at trampoline > > execution time. libffi's trampolines already handle this case today. > > > > libffi handles this using user level dynamic code which needs to be executed. > If the security subsystem prevents that, then the dynamic code cannot execute. > That is the whole point of this RFC. /If/ you are using a trampoline created by the kernel, it can just create the one that libffi is using today; which doesn't need trapping into the kernel at execution time. And if you aren't, you can use the trampoline I wrote, which has no dynamic code, and doesn't need to trap into the kernel at execution time either. > > >> > >> Permitting the use of trampfd > >> ----------------------------- > >> > >> An "exectramp" setting can be implemented in SELinux to selectively allow the > >> use of trampfd for applications. > >> > >> Madhavan > > > > Applications can use their own userspace trampolines regardless of this > > setting, so it doesn't provide any additional security benefit by > > preventing usage of trampfd. > > > > The background for all of this is that dynamic code such as trampolines > need to be placed in a page with executable permissions so they can > execute. If security measures such as W^X are present, this will not > be possible. Admitted, today some user level tricks exist to get around > W^X. I have alluded to those. IMO, they are all security holes and will > get plugged sooner or later. Then, these trampolines cannot execute. > Currently, there exist security exceptions such as execmem to let them > execute. But we would like to do it without making security exceptions. > > Madhavan How can you still say this after this whole discussion? Applications can get the exact same functionality as your proposed trampfd using static code, no W^X tricks needed. This only matters if you have a trampfd that generates _truly_ dynamic code, not just code that can be trivially made static. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel