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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 36259EB64D9 for ; Mon, 19 Jun 2023 19:45:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229720AbjFSTps (ORCPT ); Mon, 19 Jun 2023 15:45:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47570 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229593AbjFSTpr (ORCPT ); Mon, 19 Jun 2023 15:45:47 -0400 Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BC02F119 for ; Mon, 19 Jun 2023 12:45:45 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id d2e1a72fcca58-66654d019d4so3237862b3a.0 for ; Mon, 19 Jun 2023 12:45:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1687203945; x=1689795945; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=2mZiRdSqt+8wYLSRq7eLPC9b4RpYVG9iNh28AaCGdYw=; b=VbyQLRYNz3Mu4xhjfuwM6hsK60V4+prvJC2X+UK9XAc/Elig3W+lZfOdm3lsaFffXc aLwRhEXpqpl49PVYjZsMWtH3rA+TStqTAEBqKAhOrHyss+uM65w2xGYEfuipVtRsXjG5 f8D6Fx7Bv1krhLICrN7S8Z1r0/mK+azg85Gk8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687203945; x=1689795945; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=2mZiRdSqt+8wYLSRq7eLPC9b4RpYVG9iNh28AaCGdYw=; b=N26oc8Owii+2SZJi8QDI72esOfKPlCWLLtPhgXzhCYRP/VFcQNEDHI2xGJyMfzgPW6 8CCN3BLel2h+3Pq24UUAWil0W6DZPgUGAjZuyX5FKz9a41NUsyaML0/BszdKbREKv34C BP8J+viFsrlNINcd2vuC/6C2YoDk6Fcwp2l4BbhKWQ2Brdgys2u1PMmYaKGhYzoqMoXt a2qja0CeFJHMz2fwL8+sV6VhdUZddS7YaGLrgptpZDyZbuX0VCcFrLTIK+s98JboaMDK 1F87zv4TI1lqebSzNlg6Tgi75NrqXchvJor3H558dPv4DzwQIhlIhVsfYnbLLSyUcjP4 ke5Q== X-Gm-Message-State: AC+VfDyIgrnieGeCw0Z/UQR0c9wugt6zlXmmg5iX9OEIb8e2Rn0lMQYt WPzK9d4bOcOPacTKA4hX/ZUmPg== X-Google-Smtp-Source: ACHHUZ7onSh5feYj5qpymA9lTfUnolVSYLdS9M5+I0v+eTgmIbWulfKky2Q6Tl0VqKEkRqo1tB/S/w== X-Received: by 2002:a05:6a20:9389:b0:121:637e:f0e5 with SMTP id x9-20020a056a20938900b00121637ef0e5mr6130614pzh.5.1687203945205; Mon, 19 Jun 2023 12:45:45 -0700 (PDT) Received: from www.outflux.net (198-0-35-241-static.hfc.comcastbusiness.net. [198.0.35.241]) by smtp.gmail.com with ESMTPSA id h18-20020a63f912000000b00519c3475f21sm76437pgi.46.2023.06.19.12.45.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Jun 2023 12:45:44 -0700 (PDT) Date: Mon, 19 Jun 2023 12:45:43 -0700 From: Kees Cook To: Kent Overstreet Cc: Andy Lutomirski , Johannes Thumshirn , "linux-kernel@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-bcachefs@vger.kernel.org" , Kent Overstreet , Andrew Morton , Uladzislau Rezki , "hch@infradead.org" , "linux-mm@kvack.org" , "linux-hardening@vger.kernel.org" Subject: Re: [PATCH 07/32] mm: Bring back vmalloc_exec Message-ID: <202306191228.6A98FD25@keescook> References: <20230509165657.1735798-1-kent.overstreet@linux.dev> <20230509165657.1735798-8-kent.overstreet@linux.dev> <3508afc0-6f03-a971-e716-999a7373951f@wdc.com> <202305111525.67001E5C4@keescook> <202305161401.F1E3ACFAC@keescook> <1d249326-e3dd-9c9d-7b53-2fffeb39bfb4@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-hardening@vger.kernel.org On Sat, Jun 17, 2023 at 11:34:31AM -0400, Kent Overstreet wrote: > On Fri, Jun 16, 2023 at 09:13:22PM -0700, Andy Lutomirski wrote: > > On 5/16/23 14:20, Kent Overstreet wrote: > > > On Tue, May 16, 2023 at 02:02:11PM -0700, Kees Cook wrote: > > > > For something that small, why not use the text_poke API? > > > > > > This looks like it's meant for patching existing kernel text, which > > > isn't what I want - I'm generating new functions on the fly, one per > > > btree node. > > > > Dynamically generating code is a giant can of worms. > > > > Kees touched on a basic security thing: a linear address mapped W+X is a big > > no-no. And that's just scratching the surface -- ideally we would have a > > strong protocol for generating code: the code is generated in some > > extra-secure context, then it's made immutable and double-checked, then > > it becomes live. > > "Double checking" arbitrary code is is fantasy. You can't "prove the > security" of arbitrary code post compilation. I think there's a misunderstanding here about the threat model I'm interested in protecting against for JITs. While making sure the VM of a JIT is safe in itself, that's separate from what I'm concerned about. The threat model is about flaws _elsewhere_ in the kernel that can leverage the JIT machinery to convert a "write anything anywhere anytime" exploit primitive into an "execute anything" primitive. Arguments can be made to say "a write anything flaw means the total collapse of the security model so there's no point defending against it", but both that type of flaw and the slippery slope argument don't stand up well to real-world situations. The kinds of flaws we've seen are frequently limited in scope (write 1 byte, write only NULs, write only in a specific range, etc), but when chained together, the weakest link is what ultimately compromises the kernel. As such, "W^X" is a basic building block of the kernel's self-defense methods, because it is such a potent target for a write->execute attack upgrades. Since a JIT constructs something that will become executable, it needs to defend itself against stray writes from other threads. Since Linux doesn't (really) use per-CPU page tables, the workspace for a JIT can be targeted by something that isn't the JIT. To deal with this, JITs need to use 3 phases: a writing pass (into W memory), then switch it to RO and perform a verification pass (construct it again, but compare results to the RO version), and finally switch it executable. Or, it can use writes to memory that only the local CPU can perform (i.e. text_poke(), which uses a different set of page tables with different permissions). Without basic W^X, it becomes extremely difficult to build further defenses (e.g. protecting page tables themselves, etc) since WX will remain the easiest target. -Kees -- Kees Cook