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 6AF52C4346E for ; Thu, 24 Sep 2020 23:45:40 +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 930E9208C7 for ; Thu, 24 Sep 2020 23:45:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="EQom0f4i"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="SRS+3ztW" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 930E9208C7 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=6VOZHEgajvu+MqhpwCaDSoT85nxuYWFvfwSljYeAjg8=; b=EQom0f4inQ2j2uDSHq0FJcCdx cpNBf3uEcfyL2MiftTZbZnNY+mKRhRyBe+hkTzVUOsVcRYYqqzUPiEc5EkHteDT/JtYnkknwTKOKr GBywldaRjIUM8ghGdFwzGYPRdmjhvMNtH7yxu4HMw+A89esuYWPMRQyU4CaudpEVVrAygs4BGPZgB lscG6l6sLIXzmny5Kd/UDaFhjfSTzrcbzlQ+RVQGug2N8ShUTDa7AwtTkWOEHR9bruydlJwuN/yoW zxYzLZi87VzTpUcS5qJeAEBtWlnQMrWZfYwICtPn8Tx2qz0gpu1z3Hnl4gYaR0xcOMh3WO5idoNiF AilqYSiKg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kLau4-0004wG-UF; Thu, 24 Sep 2020 23:43:56 +0000 Received: from mail-qt1-x842.google.com ([2607:f8b0:4864:20::842]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kLau1-0004uO-Iu for linux-arm-kernel@lists.infradead.org; Thu, 24 Sep 2020 23:43:54 +0000 Received: by mail-qt1-x842.google.com with SMTP id k25so573608qtu.4 for ; Thu, 24 Sep 2020 16:43:51 -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=+T95pP0uGxIm5Hz5QWTAjFs5Yw5r7ZYnLnu32ktfF3g=; b=SRS+3ztWImIJz5ak5a8R2YUyAT3cOcKWla/DfSAbwA5EsQXf6lTgaBbOhFfu5VRAMx EBRH7dn0NSJYoCVohXXTd3AMFraMiAcZml1GyPB3z58QN07wqG9zoJivG2DgcQaQXRMb pWz1g3b2BP0i/X6v4wphLB+1NOv2S5Y2UonuWaD/OVTEuBAvqkQRTMfKw/959ClbM9aG aBdpSP0+xY/OxvAAtmGW3n2mOviHfCjFeRdI2E3xoJCVzhoPhpxVTCaqKyS10a3SpZZs WFJE9UifKsyVMPXz0QZXmvh6FqqjyMtTPWKuNF6a/pmAJT3YNgidThcGIy1lLmEKypUh CFyQ== 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=+T95pP0uGxIm5Hz5QWTAjFs5Yw5r7ZYnLnu32ktfF3g=; b=irVQTsZ2i4zW7UBPG3DWCe5ZI8KjkoSwvsOpNgCAzxgJNI9Nfzg5hctBO99zM7mGpX mC17FCTOW/f8nzd2ppD0qzeAw+qd+tHmzBv5O5tYafhUFNp6IK1DM+ahWBWeKnZanqLu xo8NS/giWmHBso9A/eqrsUbhcKDraXio1z2K83nE3vJwME7KM9+eRAMrMqdjneyJwTZx hRj32gythexhUy0r9QO3GpwIFI9tZX7PBKjUtYZka2apK2Mt4gpqZwydt0AvvNa0ps3W u7Q+Qdsvp2MKszT+UIPWaZ0rZ8SbGwa4fkncfsHwHg3vnRbDqLpMEpGjvFjEjtc8ebSM Jggw== X-Gm-Message-State: AOAM5318EpLs/Mn0EEpF1heO6PlauMC1xmXqEmhRUL2nnjk2jU0xtqDZ C4U7GzCSK9Syzr3qX7n+18I= X-Google-Smtp-Source: ABdhPJwOU/cF0q6NGU9SSXHvmok6uvYBc/rMxoHf5l0kEVkV0CgcegrS+4efhWf0u0ngCNKQHRuDUQ== X-Received: by 2002:aed:2e26:: with SMTP id j35mr1773028qtd.377.1600991030270; Thu, 24 Sep 2020 16:43:50 -0700 (PDT) Received: from rani.riverdale.lan ([2001:470:1f07:5f3::b55f]) by smtp.gmail.com with ESMTPSA id w18sm793791qtt.19.2020.09.24.16.43.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Sep 2020 16:43:49 -0700 (PDT) From: Arvind Sankar X-Google-Original-From: Arvind Sankar Date: Thu, 24 Sep 2020 19:43:47 -0400 To: "Madhavan T. Venkataraman" Subject: Re: [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor Message-ID: <20200924234347.GA341645@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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <2ed2becd-49b5-7e76-9836-6a43707f539f@linux.microsoft.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200924_194353_669717_ECE48B9E X-CRM114-Status: GOOD ( 40.94 ) 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 Thu, Sep 24, 2020 at 03:23:52PM -0500, Madhavan T. Venkataraman wrote: > > > > Which ISA does not support PIC objects? You mentioned i386 below, but > > i386 does support them, it just needs to copy the PC into a GPR first > > (see below). > > Position Independent Code needs PC-relative branches. I was referring > to PC-relative data references. Like RIP-relative data references in > X64. i386 ISA does not support this. I was talking about PC-relative data references too: they are a requirement for PIC code that wants to access any global data. They can be implemented easily on i386 even though it doesn't have an addressing mode that uses the PC. > Otherwise, using an ABI quirk or a calling convention side effect to load the > PC into a GPR is, IMO, non-standard or non-compliant or non-approved or > whatever you want to call it. I would be conservative and not use it. Who knows > what incompatibility there will be with some future software or hardware > features? > > For instance, in the i386 example, we do a call without a matching return. > Also, we use a pop to undo the call. Can anyone tell me if this kind of use > is an ABI approved one? This doesn't have anything to do with the ABI, since what happened here isn't visible to any caller or callee. Any machine instruction sequence that has the effect of copying the PC into a GPR is acceptable, but this is basically the only possible solution on i386. If you don't like the call/pop mismatch (though that's supported by the hardware, and is what clang likes to use), you can use the slightly different technique used in my example, which copies the top of stack into a GPR after a call. This is how all i386 PIC code has always worked. > Standard API for all userland for all architectures > --------------------------------------------------- > > The next advantage in using the kernel is standardization. > > If the kernel supplies this, then all applications and libraries can use > it for all architectures with one single, simple API. Without this, each > application/library has to roll its own solution for every architecture-ABI > combo it wants to support. But you can get even more standardization out of a userspace library, because that can work even on non-linux OS's, as well as versions of linux where the new syscall isn't available. > > Furthermore, if this work gets accepted, I plan to add a glibc wrapper for > the kernel API. The glibc API would look something like this: > > Allocate a trampoline > --------------------- > > tramp = alloc_tramp(); > > Set trampoline parameters > ------------------------- > > init_tramp(tramp, code, data); > > Free the trampoline > ------------------- > > free_tramp(tramp); > > glibc will allocate and manage the code and data tables, handle kernel API > details and manage the trampoline table. glibc could do this already if it wants, even without the syscall, because this can be done in userspace already. > > Secure vs Performant trampoline > ------------------------------- > > If you recall, in version 1, I presented a trampoline type that is > implemented in the kernel. When an application invokes the trampoline, > it traps into the kernel and the kernel performs the work of the trampoline. > > The disadvantage is that a trip to the kernel is needed. That can be > expensive. > > The advantage is that the kernel can add security checks before doing the > work. Mainly, I am looking at checks that might prevent the trampoline > from being used in an ROP/BOP chain. Some half-baked ideas: > > - Check that the invocation is at the starting point of the > trampoline > > - Check if the trampoline is jumping to an allowed PC > > - Check if the trampoline is being invoked from an allowed > calling PC or PC range > > Allowed PCs can be input using the trampfd API mentioned in version 1. > Basically, an array of PCs is written into trampfd. The source PC will generally not be available if the compiler decided to tail-call optimize the call to the trampoline into a jump. 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. > > Suggestions for other checks are most welcome! > > I would like to implement an option in the trampfd API. The user can > choose a secure trampoline or a performant trampoline. For a performant > trampoline, the kernel will generate the code. For a secure trampoline, > the kernel will do the work itself. > > 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. > > 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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel