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 B6252C7EE23 for ; Tue, 16 May 2023 22:17:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229486AbjEPWRw (ORCPT ); Tue, 16 May 2023 18:17:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49064 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229518AbjEPWRt (ORCPT ); Tue, 16 May 2023 18:17:49 -0400 Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5AA0059F4 for ; Tue, 16 May 2023 15:17:48 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-510a5a5cf79so181a12.1 for ; Tue, 16 May 2023 15:17:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1684275467; x=1686867467; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=DFM3fAYlTPBxQGmteO/2uHFhqAyi1JN0aT26xTBpePY=; b=o2yls/45s0xkZRgXdYp9Llp5QvwSiw2Yins46NJBQ93VxSzpcVos6BkD9ZuzWFA6zU OLiA/M6Ocvy+P4BEWoZdomhusGCoMMqAFW61552mNjMRB4VeIol0mTshVg5jouXKuObl Qj7ybH1dkgrkD5EEkwaYEi3zN4P4l5qGIq5z9AwQNzUOGmyRuM62BwnbBdj6zPnZ0v4B gdKf2Eq2CjxCfpZB1geOeSvb6FtBgiO4ynAq+LDyuAWeuAucwu30IDaI3JRef9OAg43t m+dXn+w3YLkbCgdi1d7j3HJbtKxXGw15d65FITdPhLK6pSsk9JI6fdnBe39mHtctSmcS Shgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684275467; x=1686867467; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=DFM3fAYlTPBxQGmteO/2uHFhqAyi1JN0aT26xTBpePY=; b=L83x/vZ2+LZLuaG5YAxxvdfeWAlODPn8PkytuqYrwx8H9SvWIF2Dt3QNc/On6T2uxI x0BfxpjR09PRizhmS8GZD0nXhqKN2E0CREMon83Ugu3vUoRGfcTEGAXDo4AFW8EHQRxU oVt9kCzc44f2YA7almp/Y4kniWb/nMUEDHfxnb64JyRo1Wf8S21LoNJvnYmB8gYY0SlA DLZiEd0aUP7wjlu6MYDYZcgTHhQ/2AtCtcmVbrgmm0Z3lstlad2YI6W0lWAom6phmk5p yOKGtUc07YIf7MnKQMFHBEBE/xXtc22DeUwUvqyxiFURrnf+apdmy4l00N1fPNQj5mNy Lr8A== X-Gm-Message-State: AC+VfDzlJrpFTrF3ZFhkLamcDyaL/3pzimjRlNPXrtdytyWrZMZOWskZ 2+F2/4aNTM1TWw/FyzWrUxLzCCb0RmACs+A8wN/jFw== X-Google-Smtp-Source: ACHHUZ4kIdAG/+KEv1wYdz2uXbEvowoCYDRdQ98dgmPo2TYOqhB/KFXxkuuo4dMNQNDQo21ejrglf36AsKWL2Iuky8U= X-Received: by 2002:a50:aadd:0:b0:50b:f6ce:2f3d with SMTP id r29-20020a50aadd000000b0050bf6ce2f3dmr51714edc.0.1684275466605; Tue, 16 May 2023 15:17:46 -0700 (PDT) MIME-Version: 1.0 References: <20230515130553.2311248-1-jeffxu@chromium.org> <202305161307.4A16BB6A47@keescook> In-Reply-To: <202305161307.4A16BB6A47@keescook> From: Jeff Xu Date: Tue, 16 May 2023 15:17:09 -0700 Message-ID: Subject: Re: [PATCH 0/6] Memory Mapping (VMA) protection using PKU - set 1 To: Kees Cook Cc: jeffxu@chromium.org, dave.hansen@intel.com, luto@kernel.org, jorgelo@chromium.org, groeck@chromium.org, jannh@google.com, sroettger@google.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, linux-hardening@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 16, 2023 at 1:08=E2=80=AFPM Kees Cook w= rote: > > On Mon, May 15, 2023 at 01:05:46PM +0000, jeffxu@chromium.org wrote: > > This patch introduces a new flag, PKEY_ENFORCE_API, to the pkey_alloc() > > function. When a PKEY is created with this flag, it is enforced that an= y > > thread that wants to make changes to the memory mapping (such as mprote= ct) > > of the memory must have write access to the PKEY. PKEYs created without > > this flag will continue to work as they do now, for backwards > > compatibility. > > > > Only PKEY created from user space can have the new flag set, the PKEY > > allocated by the kernel internally will not have it. In other words, > > ARCH_DEFAULT_PKEY(0) and execute_only_pkey won=E2=80=99t have this flag= set, > > and continue work as today. > > Cool! Yeah, this looks like it could become quite useful. I assume > V8 folks are on board with this API, etc? > > > This set of patch covers mprotect/munmap, I plan to work on other > > syscalls after this. > > Which ones are on your list currently? > mprotect/mprotect_pkey/munmap mmap/mremap madvice,brk,sbrk Thanks! -Jeff Xu > -- > Kees Cook