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=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 2DDF9C433E3 for ; Sun, 2 Aug 2020 20:01:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2314C20759 for ; Sun, 2 Aug 2020 20:01:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596398471; bh=dArsY75FWjtt7As5xgbBwC+egu06UpMYVG1i87QOXX4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=yDWOKwfiasrzta6/fmBySalw/mpmckWZahawmLKKn2laNfoFJLie8+wGXWAygjXor wZt7bcfjGgAs2QWoXr5fNy3xXiLgyYknz47PnX0ks9hpXBAt0jseZquXypAvjBSDfs eA6YlEnmAMnImKAi62owAB0dnTvwneVp3Kd5kAvk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726345AbgHBUBK (ORCPT ); Sun, 2 Aug 2020 16:01:10 -0400 Received: from mail.kernel.org ([198.145.29.99]:48726 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726482AbgHBUBH (ORCPT ); Sun, 2 Aug 2020 16:01:07 -0400 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5F865208E4 for ; Sun, 2 Aug 2020 20:01:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596398466; bh=dArsY75FWjtt7As5xgbBwC+egu06UpMYVG1i87QOXX4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=lFOS7lJYqGZDUwyxfvUbEw3DcXArYKRSiYijAubBtPRJsaSTkU+wCq03sdFRLVP4y AxSKRyRIeluQfLLcwq6rbGsNh5LQAyLHEcwqj39yOsWbZUGcPQzjGSJYbrAmCsU3Z1 2xtGHK38WBWYXZvVcRrlBcdTDy5mCbY9rXYSK5Qc= Received: by mail-wr1-f53.google.com with SMTP id r12so32257891wrj.13 for ; Sun, 02 Aug 2020 13:01:06 -0700 (PDT) X-Gm-Message-State: AOAM5338f+wAcfkLobS0Yx1NZOnkjZQm1c2DGeaQSBI/6rPqM+7i9mwV VhksMdY7zctbHbYRwBP5X23oWpIF6TdYGi3tykTEew== X-Google-Smtp-Source: ABdhPJzzn0TKME2O/OiT/zeV9TBqi5bQ33rtcB/MxXB3Iouj0pekgUtP+crNwDATDo4OGLVWkntyqQrZSKf4qTC10bw= X-Received: by 2002:adf:fa85:: with SMTP id h5mr12474521wrr.18.1596398464878; Sun, 02 Aug 2020 13:01:04 -0700 (PDT) MIME-Version: 1.0 References: <20200728131050.24443-1-madvenka@linux.microsoft.com> <3b916198-3a98-bd19-9a1c-f2d8d44febe8@linux.microsoft.com> In-Reply-To: <3b916198-3a98-bd19-9a1c-f2d8d44febe8@linux.microsoft.com> From: Andy Lutomirski Date: Sun, 2 Aug 2020 13:00:53 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor To: "Madhavan T. Venkataraman" Cc: Andy Lutomirski , Kernel Hardening , Linux API , linux-arm-kernel , Linux FS Devel , linux-integrity , LKML , LSM List , Oleg Nesterov , X86 ML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: On Sun, Aug 2, 2020 at 11:54 AM Madhavan T. Venkataraman wrote: > > More responses inline.. > > On 7/28/20 12:31 PM, Andy Lutomirski wrote: > >> On Jul 28, 2020, at 6:11 AM, madvenka@linux.microsoft.com wrote: > >> > >> =EF=BB=BFFrom: "Madhavan T. Venkataraman" > >> > > > > 2. Use existing kernel functionality. Raise a signal, modify the > > state, and return from the signal. This is very flexible and may not > > be all that much slower than trampfd. > > Let me understand this. You are saying that the trampoline code > would raise a signal and, in the signal handler, set up the context > so that when the signal handler returns, we end up in the target > function with the context correctly set up. And, this trampoline code > can be generated statically at build time so that there are no > security issues using it. > > Have I understood your suggestion correctly? yes. > > So, my argument would be that this would always incur the overhead > of a trip to the kernel. I think twice the overhead if I am not mistaken. > With trampfd, we can have the kernel generate the code so that there > is no performance penalty at all. I feel like trampfd is too poorly defined at this point to evaluate. There are three general things it could do. It could generate actual code that varies by instance. It could have static code that does not vary. And it could actually involve a kernel entry. If it involves a kernel entry, then it's slow. Maybe this is okay for some use cases. If it involves only static code, I see no good reason that it should be in the kernel. If it involves dynamic code, then I think it needs a clearly defined use case that actually requires dynamic code. > Also, signals are asynchronous. So, they are vulnerable to race condition= s. > To prevent other signals from coming in while handling the raised signal, > we would need to block and unblock signals. This will cause more > overhead. If you're worried about raise() racing against signals from out of thread, you have bigger problems to deal with.