Message ID | 20231222235248.576482-1-debug@rivosinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-10145-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:2483:b0:fb:cd0c:d3e with SMTP id q3csp1395458dyi; Fri, 22 Dec 2023 15:57:23 -0800 (PST) X-Google-Smtp-Source: AGHT+IG8WnrlC0fdnpZKKsFt5FPtY4VYoxuJzTPV+HLKZDdwiLOVtzGEcneK3kCnIrar6smh6Y9F X-Received: by 2002:a05:600c:4ed4:b0:40c:6e2a:6cd with SMTP id g20-20020a05600c4ed400b0040c6e2a06cdmr586099wmq.23.1703289443594; Fri, 22 Dec 2023 15:57:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703289443; cv=none; d=google.com; s=arc-20160816; b=AH9vEfAN0lSlZrevn8zz+RqDQk1F0p3Oz2byKfNaOd9qnpVwpy2FebWYGJaHn0q+h6 xNUHhqChcakbrTOOVXCcnZMrB/ha1M+Ym/TS9cUZ0H0KZgbFIeZfMyYYVBt3ORS069PF kwXa331hJ+/VuY9lJNrKac9KG9xMSyw2uGAmOF+07uBrulQ+kdlA2dlWh9GyCsZM23qT KvEsFGr3RAhIwDEPl6toBqivb5JucUG+yOkWJ6HUnZPQjx4cI0D2gYFgu/3UOtRGEYtB 6Ntfui3Ng1i0W8Lsl2F5Rx9fQZEpvwiHfJROpxF4/e4wdtESD3l+qtz87HmdUjrngvIr mW/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=jovKxsj0YGOzwwNQclPyLUNNHjkrdGN438RuH3dRR2A=; fh=r91DopZpKQ1SrIaWRrw4wk8rFjCKGNI0R1OyTSlhTiI=; b=sJJP2rjQDSCFHIB0FPc75moWevGCr2d5rs+RjoW8bi7P/ZuM+R8gYlPL1liwDGC6hN K0r965+eLF0HFSO95GZApJpY2L2a1TWkyjmSrjc5BXwc6vC5oU8P7Slkpdv0dTl/UDUA PspipaCYc5bBhW8CSXwPBmv/YkvhObPw4UVNX+sESGJkZ0aeQJ+avs+o0tBBq93cSzna rTEK8kCpwM1pJoccq9DARPoZxFPXkg8CoFYOKF2qQ7o9kaA2daQAdHg69X1STDaVAXkM EPZp0mQlkXPjQs8Ngq3g9zC1TWSd692cT4TY7Pj5PvvKbOadb/ZrqLgyLbqhf2sgFHW6 mkxA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=fvSnWIDX; spf=pass (google.com: domain of linux-kernel+bounces-10145-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-10145-ouuuleilei=gmail.com@vger.kernel.org" Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id v9-20020a1709060b4900b00a26aa69bb75si1667753ejg.936.2023.12.22.15.57.23 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Dec 2023 15:57:23 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-10145-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=fvSnWIDX; spf=pass (google.com: domain of linux-kernel+bounces-10145-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-10145-ouuuleilei=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 29A9E1F22837 for <ouuuleilei@gmail.com>; Fri, 22 Dec 2023 23:57:23 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 391E24E1CD; Fri, 22 Dec 2023 23:55:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b="fvSnWIDX" X-Original-To: linux-kernel@vger.kernel.org Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 57F244E1A0 for <linux-kernel@vger.kernel.org>; Fri, 22 Dec 2023 23:55:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-ot1-f53.google.com with SMTP id 46e09a7af769-6db9f489cddso1015033a34.1 for <linux-kernel@vger.kernel.org>; Fri, 22 Dec 2023 15:55:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1703289300; x=1703894100; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=jovKxsj0YGOzwwNQclPyLUNNHjkrdGN438RuH3dRR2A=; b=fvSnWIDXCSYcwJzywnIWs4x4Kw6nigrt3MnI2yuHkeIF3or9WBhZzUFAXaMMsGBwqg usGirWhdj6X1Vl07gDi16bSi/Q9NN41YkBlZzS/UYAFw7vMDs+7n1F1HZmGGEuSB4AfI Uu8pvExS7NdQgH+Pi9CeTPGPef/rthyyb4ejiRKUFmPxzm5n6cRV21NcQ36TKKBRS4Bm lVsOPvVfo3MmYBeLBh6sbHoWwW0EcFGesR5l9HzpvOvOt8tiF7vp1RDSWAAuN4UR7GYq iUt0pjlhBNZ6R0h/nB6zGCClllilxo3331W2WDShKCG4f2jb+pwP2JtygV8s42wY8f5n hPog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703289300; x=1703894100; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=jovKxsj0YGOzwwNQclPyLUNNHjkrdGN438RuH3dRR2A=; b=shN4hAJ5Fy6ltdovxrLykEtUHuLT28op/KLYeI+IWVNlwHjTdPXFT9cVfdZbSUFc5O IVabXCHlLGvwcHmeIyw8GOOPUnMN9Y409IBeuh5aPKIEMfX8Xq5WzYjKOeyRz8f8s2gW CUVWRb6Vngw0VxN9h0u5r41fGoNeA+luJ1hagP40bvXOXE63VZQ+HduwQmc5n/nt00gh 0ILpOD97UgQL2QUxDVbzNin3cXwZ52GK9ykPnDXStEZGNuZMbC44M6+NY1wpe3QsUCsc os4J9qj60sg8aBmbCF1MVPxPBKLXHf+2FOFZkZC1jBvvcBTPzIHCD2MqIQYz5iBIzerX mN+w== X-Gm-Message-State: AOJu0YzlyQ2qqWLZlHje3DHSbjzL9+oVLFgpO8hEj28HrU5GpNkBb/jW fv/+9Tavh9F1+0VgR4JRSO47l+nd7wo97A== X-Received: by 2002:a05:6830:450f:b0:6db:b9db:4393 with SMTP id i15-20020a056830450f00b006dbb9db4393mr1209126otv.0.1703289300272; Fri, 22 Dec 2023 15:55:00 -0800 (PST) Received: from debug.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id q65-20020a4a4b44000000b005944c7f6bb6sm249999ooa.29.2023.12.22.15.54.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Dec 2023 15:54:59 -0800 (PST) From: Deepak Gupta <debug@rivosinc.com> To: rick.p.edgecombe@intel.com, broonie@kernel.org Cc: Deepak Gupta <debug@rivosinc.com>, Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH v1] mm: abstract shadow stack vma behind arch_is_shadow_stack_vma Date: Fri, 22 Dec 2023 15:51:04 -0800 Message-ID: <20231222235248.576482-1-debug@rivosinc.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1786028431378173189 X-GMAIL-MSGID: 1786028431378173189 |
Series |
[v1] mm: abstract shadow stack vma behind arch_is_shadow_stack_vma
|
|
Commit Message
Deepak Gupta
Dec. 22, 2023, 11:51 p.m. UTC
x86 has used VM_SHADOW_STACK (alias to VM_HIGH_ARCH_5) to encode shadow
stack VMA. VM_SHADOW_STACK is thus not possible on 32bit. Some arches may
need a way to encode shadow stack on 32bit and 64bit both and they may
encode this information differently in VMAs.
This patch changes checks of VM_SHADOW_STACK flag in generic code to call
to a function `arch_is_shadow_stack_vma` which will return true if arch
supports shadow stack and vma is shadow stack else stub returns false.
Signed-off-by: Deepak Gupta <debug@rivosinc.com>
---
include/linux/mm.h | 15 ++++++++++++++-
mm/gup.c | 2 +-
mm/internal.h | 2 +-
3 files changed, 16 insertions(+), 3 deletions(-)
Comments
On Fri, 22 Dec 2023 15:51:04 -0800 Deepak Gupta <debug@rivosinc.com> wrote: > x86 has used VM_SHADOW_STACK (alias to VM_HIGH_ARCH_5) to encode shadow > stack VMA. VM_SHADOW_STACK is thus not possible on 32bit. Some arches may > need a way to encode shadow stack on 32bit and 64bit both and they may > encode this information differently in VMAs. Is such a patch in the pipeline? Otherwise we're making a change that serves no purpose. > This patch changes checks of VM_SHADOW_STACK flag in generic code to call > to a function `arch_is_shadow_stack_vma` which will return true if arch > supports shadow stack and vma is shadow stack else stub returns false. > > ... > > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -352,8 +352,21 @@ extern unsigned int kobjsize(const void *objp); > * for more details on the guard size. > */ > # define VM_SHADOW_STACK VM_HIGH_ARCH_5 > + > +static inline bool arch_is_shadow_stack_vma(vm_flags_t vm_flags) > +{ > + return (vm_flags & VM_SHADOW_STACK) ? true : false; > +} The naming seems a little wrong. I'd expect it to take a vma* arg. Maybe just drop the "_vma"?
On Wed, Dec 27, 2023 at 1:45 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > On Fri, 22 Dec 2023 15:51:04 -0800 Deepak Gupta <debug@rivosinc.com> wrote: > > > x86 has used VM_SHADOW_STACK (alias to VM_HIGH_ARCH_5) to encode shadow > > stack VMA. VM_SHADOW_STACK is thus not possible on 32bit. Some arches may > > need a way to encode shadow stack on 32bit and 64bit both and they may > > encode this information differently in VMAs. > > Is such a patch in the pipeline? Otherwise we're making a change that > serves no purpose. Yes I do have patches in the pipeline for riscv. On riscv, presence of only `VM_WRITE` (i.e. (flags & (VM_READ | VM_WRITE | VM_EXEC)) == VM_WRITE) would mean a shadow stack. And yes there would be relevant patches to ensure that existing consumers using `PROT_WRITE` gets translated to (VM_WRITE | VM_READ) > > > This patch changes checks of VM_SHADOW_STACK flag in generic code to call > > to a function `arch_is_shadow_stack_vma` which will return true if arch > > supports shadow stack and vma is shadow stack else stub returns false. > > > > ... > > > > --- a/include/linux/mm.h > > +++ b/include/linux/mm.h > > @@ -352,8 +352,21 @@ extern unsigned int kobjsize(const void *objp); > > * for more details on the guard size. > > */ > > # define VM_SHADOW_STACK VM_HIGH_ARCH_5 > > + > > +static inline bool arch_is_shadow_stack_vma(vm_flags_t vm_flags) > > +{ > > + return (vm_flags & VM_SHADOW_STACK) ? true : false; > > +} > > The naming seems a little wrong. I'd expect it to take a vma* arg. > Maybe just drop the "_vma"? Well I did start with taking vma* argument but then realized that `is_stack_mapping` only takes vma flags. And in order to change that I would have to change `vm_stat_account` and every place it's called. In the next version I'll either do that or drop `_vma` from the proposed function name. >
On Wed, 27 Dec 2023 14:20:36 -0800 Deepak Gupta <debug@rivosinc.com> wrote: > On Wed, Dec 27, 2023 at 1:45 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > > > On Fri, 22 Dec 2023 15:51:04 -0800 Deepak Gupta <debug@rivosinc.com> wrote: > > > > > x86 has used VM_SHADOW_STACK (alias to VM_HIGH_ARCH_5) to encode shadow > > > stack VMA. VM_SHADOW_STACK is thus not possible on 32bit. Some arches may > > > need a way to encode shadow stack on 32bit and 64bit both and they may > > > encode this information differently in VMAs. > > > > Is such a patch in the pipeline? Otherwise we're making a change that > > serves no purpose. > > Yes I do have patches in the pipeline for riscv. > On riscv, presence of only `VM_WRITE` (i.e. (flags & (VM_READ | > VM_WRITE | VM_EXEC)) > == VM_WRITE) would mean a shadow stack. > And yes there would be relevant patches to ensure that existing consumers using > `PROT_WRITE` gets translated to (VM_WRITE | VM_READ) OK, please plan to carry this patch in whatever tree contains the above.
On Wed, Dec 27, 2023 at 2:24 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > On Wed, 27 Dec 2023 14:20:36 -0800 Deepak Gupta <debug@rivosinc.com> wrote: > > > On Wed, Dec 27, 2023 at 1:45 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > > > > > On Fri, 22 Dec 2023 15:51:04 -0800 Deepak Gupta <debug@rivosinc.com> wrote: > > > > > > > x86 has used VM_SHADOW_STACK (alias to VM_HIGH_ARCH_5) to encode shadow > > > > stack VMA. VM_SHADOW_STACK is thus not possible on 32bit. Some arches may > > > > need a way to encode shadow stack on 32bit and 64bit both and they may > > > > encode this information differently in VMAs. > > > > > > Is such a patch in the pipeline? Otherwise we're making a change that > > > serves no purpose. > > > > Yes I do have patches in the pipeline for riscv. > > On riscv, presence of only `VM_WRITE` (i.e. (flags & (VM_READ | > > VM_WRITE | VM_EXEC)) > > == VM_WRITE) would mean a shadow stack. > > And yes there would be relevant patches to ensure that existing consumers using > > `PROT_WRITE` gets translated to (VM_WRITE | VM_READ) > > OK, please plan to carry this patch in whatever tree contains the above. > > ACK. Thanks
On Wed, Dec 27, 2023 at 01:45:14PM -0800, Andrew Morton wrote: > On Fri, 22 Dec 2023 15:51:04 -0800 Deepak Gupta <debug@rivosinc.com> wrote: > > > x86 has used VM_SHADOW_STACK (alias to VM_HIGH_ARCH_5) to encode shadow > > stack VMA. VM_SHADOW_STACK is thus not possible on 32bit. Some arches may > > need a way to encode shadow stack on 32bit and 64bit both and they may > > encode this information differently in VMAs. > > Is such a patch in the pipeline? Otherwise we're making a change that > serves no purpose. > > > This patch changes checks of VM_SHADOW_STACK flag in generic code to call > > to a function `arch_is_shadow_stack_vma` which will return true if arch > > supports shadow stack and vma is shadow stack else stub returns false. > > > > ... > > > > --- a/include/linux/mm.h > > +++ b/include/linux/mm.h > > @@ -352,8 +352,21 @@ extern unsigned int kobjsize(const void *objp); > > * for more details on the guard size. > > */ > > # define VM_SHADOW_STACK VM_HIGH_ARCH_5 > > + > > +static inline bool arch_is_shadow_stack_vma(vm_flags_t vm_flags) > > +{ > > + return (vm_flags & VM_SHADOW_STACK) ? true : false; > > +} > > The naming seems a little wrong. I'd expect it to take a vma* arg. > Maybe just drop the "_vma"? I'd suggest to use vma_is_shadow_stack() to make it inline with other vma_is_*() tests.
On Fri, 2023-12-22 at 15:51 -0800, Deepak Gupta wrote: > + > +static inline bool arch_is_shadow_stack_vma(vm_flags_t vm_flags) > +{ > + return (vm_flags & VM_SHADOW_STACK) ? true : false; > +} > + The bit after the "?" should be unneeded. I would think that patterns like: bool res = val ? true : false; ...should never be needed for the kernel's current bool typedef. Is there some special arch define consideration or something, I'm unaware of? https://www.kernel.org/doc/html/latest/process/coding-style.html#using-bool
On Tue, Jan 2, 2024 at 9:50 AM Edgecombe, Rick P <rick.p.edgecombe@intel.com> wrote: > > On Fri, 2023-12-22 at 15:51 -0800, Deepak Gupta wrote: > > + > > +static inline bool arch_is_shadow_stack_vma(vm_flags_t vm_flags) > > +{ > > + return (vm_flags & VM_SHADOW_STACK) ? true : false; > > +} > > + > > The bit after the "?" should be unneeded. I would think that patterns > like: > > bool res = val ? true : false; > > ...should never be needed for the kernel's current bool typedef. Is > there some special arch define consideration or something, I'm unaware > of? > > https://www.kernel.org/doc/html/latest/process/coding-style.html#using-bool Thanks. Just checked out the link you sent. Yes it's not needed. Will remove it.
On Tue, Jan 2, 2024 at 5:57 AM Mike Rapoport <rppt@kernel.org> wrote: > > On Wed, Dec 27, 2023 at 01:45:14PM -0800, Andrew Morton wrote: > > On Fri, 22 Dec 2023 15:51:04 -0800 Deepak Gupta <debug@rivosinc.com> wrote: > > > > > x86 has used VM_SHADOW_STACK (alias to VM_HIGH_ARCH_5) to encode shadow > > > stack VMA. VM_SHADOW_STACK is thus not possible on 32bit. Some arches may > > > need a way to encode shadow stack on 32bit and 64bit both and they may > > > encode this information differently in VMAs. > > > > Is such a patch in the pipeline? Otherwise we're making a change that > > serves no purpose. > > > > > This patch changes checks of VM_SHADOW_STACK flag in generic code to call > > > to a function `arch_is_shadow_stack_vma` which will return true if arch > > > supports shadow stack and vma is shadow stack else stub returns false. > > > > > > ... > > > > > > --- a/include/linux/mm.h > > > +++ b/include/linux/mm.h > > > @@ -352,8 +352,21 @@ extern unsigned int kobjsize(const void *objp); > > > * for more details on the guard size. > > > */ > > > # define VM_SHADOW_STACK VM_HIGH_ARCH_5 > > > + > > > +static inline bool arch_is_shadow_stack_vma(vm_flags_t vm_flags) > > > +{ > > > + return (vm_flags & VM_SHADOW_STACK) ? true : false; > > > +} > > > > The naming seems a little wrong. I'd expect it to take a vma* arg. > > Maybe just drop the "_vma"? > > I'd suggest to use vma_is_shadow_stack() to make it inline with other > vma_is_*() tests. Noted. Thanks > > -- > Sincerely yours, > Mike.
diff --git a/include/linux/mm.h b/include/linux/mm.h index 418d26608ece..9586e7bbd2aa 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -352,8 +352,21 @@ extern unsigned int kobjsize(const void *objp); * for more details on the guard size. */ # define VM_SHADOW_STACK VM_HIGH_ARCH_5 + +static inline bool arch_is_shadow_stack_vma(vm_flags_t vm_flags) +{ + return (vm_flags & VM_SHADOW_STACK) ? true : false; +} + #else + # define VM_SHADOW_STACK VM_NONE + +static inline bool arch_is_shadow_stack_vma(vm_flags_t vm_flags) +{ + return false; +} + #endif #if defined(CONFIG_X86) @@ -3452,7 +3465,7 @@ static inline unsigned long stack_guard_start_gap(struct vm_area_struct *vma) return stack_guard_gap; /* See reasoning around the VM_SHADOW_STACK definition */ - if (vma->vm_flags & VM_SHADOW_STACK) + if (arch_is_shadow_stack_vma(vma->vm_flags)) return PAGE_SIZE; return 0; diff --git a/mm/gup.c b/mm/gup.c index 231711efa390..dcc2aa079163 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -1051,7 +1051,7 @@ static int check_vma_flags(struct vm_area_struct *vma, unsigned long gup_flags) !writable_file_mapping_allowed(vma, gup_flags)) return -EFAULT; - if (!(vm_flags & VM_WRITE) || (vm_flags & VM_SHADOW_STACK)) { + if (!(vm_flags & VM_WRITE) || arch_is_shadow_stack_vma(vm_flags)) { if (!(gup_flags & FOLL_FORCE)) return -EFAULT; /* hugetlb does not support FOLL_FORCE|FOLL_WRITE. */ diff --git a/mm/internal.h b/mm/internal.h index b61034bd50f5..05a6b47c3ca1 100644 --- a/mm/internal.h +++ b/mm/internal.h @@ -572,7 +572,7 @@ static inline bool is_exec_mapping(vm_flags_t flags) */ static inline bool is_stack_mapping(vm_flags_t flags) { - return ((flags & VM_STACK) == VM_STACK) || (flags & VM_SHADOW_STACK); + return ((flags & VM_STACK) == VM_STACK) || arch_is_shadow_stack_vma(flags); } /*