From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756922AbcGIXSc (ORCPT ); Sat, 9 Jul 2016 19:18:32 -0400 Received: from r00tworld.com ([212.85.137.150]:56899 "EHLO r00tworld.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756655AbcGIXSb (ORCPT ); Sat, 9 Jul 2016 19:18:31 -0400 From: "PaX Team" To: Kees Cook , Andy Lutomirski Date: Sun, 10 Jul 2016 01:16:36 +0200 MIME-Version: 1.0 Subject: Re: [PATCH 0/9] mm: Hardened usercopy Reply-to: pageexec@freemail.hu CC: Christoph Lameter , Andrew Morton , Brad Spengler , Pekka Enberg , Ard Biesheuvel , Casey Schaufler , Will Deacon , Rik van Riel , Benjamin Herrenschmidt , Dmitry Vyukov , "linux-ia64@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , X86 ML , Catalin Marinas , linux-arch , David Rientjes , Mathias Krause , "kernel-hardening@lists.openwall.com" , "David S. Miller" , Laura Abbott , "linux-mm@kvack.org" , Jan Kara , Russell King , Michael Ellerman , Andrea Arcangeli , Fenghua Yu , linuxppc-dev@lists.ozlabs.org, Vitaly Wool , "linux-kernel@vger.kernel.org" , Borislav Petkov , Tony Luck , Joonsoo Kim , sparclinux@vger.kernel.org Message-ID: <578185D4.29090.242668C8@pageexec.freemail.hu> In-reply-to: References: <1467843928-29351-1-git-send-email-keescook@chromium.org>, X-mailer: Pegasus Mail for Windows (4.72.572) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.12 (r00tworld.com [212.85.137.150]); Sun, 10 Jul 2016 01:16:36 +0200 (CEST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9 Jul 2016 at 14:27, Andy Lutomirski wrote: > On Jul 6, 2016 6:25 PM, "Kees Cook" wrote: > > > > Hi, > > > > This is a start of the mainline port of PAX_USERCOPY[1]. After I started > > writing tests (now in lkdtm in -next) for Casey's earlier port[2], I > > kept tweaking things further and further until I ended up with a whole > > new patch series. To that end, I took Rik's feedback and made a number > > of other changes and clean-ups as well. > > > > I like the series, but I have one minor nit to pick. The effect of > this series is to harden usercopy, but most of the code is really > about infrastructure to validate that a pointed-to object is valid. actually USERCOPY has never been about validating pointers. its sole purpose is to validate the *size* argument of copy*user calls, a very specific form of runtime bounds checking. it's only really relevant for slab objects and the pointer checks (that one might mistake for being a part of the defense mechanism) are only there to determine whether the kernel pointer refers to a slab object or not (the stack part is a small bonus and was never the main goal either). > Might it make sense to call the infrastructure part something else? yes, more bikeshedding will surely help, like the renaming of .data..read_only to .data..ro_after_init which also had nothing to do with init but everything to do with objects being conceptually read-only... > After all, this could be extended in the future for memcpy or even for > some GCC plugin to check pointers passed to ordinary (non-allocator) > functions. what kind of checks are you thinking of here? and more fundamentally, against what kind of threats? as for memcpy, it's the standard mandated memory copying function, what security related properties can it check on its pointer arguments? From mboxrd@z Thu Jan 1 00:00:00 1970 From: "PaX Team" Subject: Re: [PATCH 0/9] mm: Hardened usercopy Date: Sun, 10 Jul 2016 01:16:36 +0200 Message-ID: <578185D4.29090.242668C8@pageexec.freemail.hu> References: <1467843928-29351-1-git-send-email-keescook@chromium.org>, Reply-To: pageexec@freemail.hu Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Return-path: In-reply-to: Content-description: Mail message body Sender: owner-linux-mm@kvack.org To: Kees Cook , Andy Lutomirski Cc: Christoph Lameter , Andrew Morton , Brad Spengler , Pekka Enberg , Ard Biesheuvel , Casey Schaufler , Will Deacon , Rik van Riel , Benjamin Herrenschmidt , Dmitry Vyukov , "linux-ia64@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , X86 ML , Catalin Marinas , linux-arch , David Rientjes , Mathias Krause , "kernel-hardening@lists.openwall.com" List-Id: linux-arch.vger.kernel.org On 9 Jul 2016 at 14:27, Andy Lutomirski wrote: > On Jul 6, 2016 6:25 PM, "Kees Cook" wrote: > > > > Hi, > > > > This is a start of the mainline port of PAX_USERCOPY[1]. After I started > > writing tests (now in lkdtm in -next) for Casey's earlier port[2], I > > kept tweaking things further and further until I ended up with a whole > > new patch series. To that end, I took Rik's feedback and made a number > > of other changes and clean-ups as well. > > > > I like the series, but I have one minor nit to pick. The effect of > this series is to harden usercopy, but most of the code is really > about infrastructure to validate that a pointed-to object is valid. actually USERCOPY has never been about validating pointers. its sole purpose is to validate the *size* argument of copy*user calls, a very specific form of runtime bounds checking. it's only really relevant for slab objects and the pointer checks (that one might mistake for being a part of the defense mechanism) are only there to determine whether the kernel pointer refers to a slab object or not (the stack part is a small bonus and was never the main goal either). > Might it make sense to call the infrastructure part something else? yes, more bikeshedding will surely help, like the renaming of .data..read_only to .data..ro_after_init which also had nothing to do with init but everything to do with objects being conceptually read-only... > After all, this could be extended in the future for memcpy or even for > some GCC plugin to check pointers passed to ordinary (non-allocator) > functions. what kind of checks are you thinking of here? and more fundamentally, against what kind of threats? as for memcpy, it's the standard mandated memory copying function, what security related properties can it check on its pointer arguments? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from r00tworld.com ([212.85.137.150]:51225 "EHLO r00tworld.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752846AbcGIXt1 (ORCPT ); Sat, 9 Jul 2016 19:49:27 -0400 From: "PaX Team" Date: Sun, 10 Jul 2016 01:16:36 +0200 MIME-Version: 1.0 Subject: Re: [PATCH 0/9] mm: Hardened usercopy Reply-to: pageexec@freemail.hu Message-ID: <578185D4.29090.242668C8@pageexec.freemail.hu> In-reply-to: References: <1467843928-29351-1-git-send-email-keescook@chromium.org>, Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Sender: linux-arch-owner@vger.kernel.org List-ID: To: Kees Cook , Andy Lutomirski Cc: Christoph Lameter , Andrew Morton , Brad Spengler , Pekka Enberg , Ard Biesheuvel , Casey Schaufler , Will Deacon , Rik van Riel , Benjamin Herrenschmidt , Dmitry Vyukov , "linux-ia64@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , X86 ML , Catalin Marinas , linux-arch , David Rientjes , Mathias Krause , "kernel-hardening@lists.openwall.com" , "David S. Miller" , Laura Abbott , "linux-mm@kvack.org" , Jan Kara , Russell King , Michael Ellerman , Andrea Arcangeli , Fenghua Yu , linuxppc-dev@lists.ozlabs.org, Vitaly Wool , "linux-kernel@vger.kernel.org" , Borislav Petkov , Tony Luck , Joonsoo Kim , sparclinux@vger.kernel.org Message-ID: <20160709231636.Vk_iLGJSQDEOfVmAAebBiZr7FutR-SlTGLFpmKtt16I@z> On 9 Jul 2016 at 14:27, Andy Lutomirski wrote: > On Jul 6, 2016 6:25 PM, "Kees Cook" wrote: > > > > Hi, > > > > This is a start of the mainline port of PAX_USERCOPY[1]. After I started > > writing tests (now in lkdtm in -next) for Casey's earlier port[2], I > > kept tweaking things further and further until I ended up with a whole > > new patch series. To that end, I took Rik's feedback and made a number > > of other changes and clean-ups as well. > > > > I like the series, but I have one minor nit to pick. The effect of > this series is to harden usercopy, but most of the code is really > about infrastructure to validate that a pointed-to object is valid. actually USERCOPY has never been about validating pointers. its sole purpose is to validate the *size* argument of copy*user calls, a very specific form of runtime bounds checking. it's only really relevant for slab objects and the pointer checks (that one might mistake for being a part of the defense mechanism) are only there to determine whether the kernel pointer refers to a slab object or not (the stack part is a small bonus and was never the main goal either). > Might it make sense to call the infrastructure part something else? yes, more bikeshedding will surely help, like the renaming of .data..read_only to .data..ro_after_init which also had nothing to do with init but everything to do with objects being conceptually read-only... > After all, this could be extended in the future for memcpy or even for > some GCC plugin to check pointers passed to ordinary (non-allocator) > functions. what kind of checks are you thinking of here? and more fundamentally, against what kind of threats? as for memcpy, it's the standard mandated memory copying function, what security related properties can it check on its pointer arguments? From mboxrd@z Thu Jan 1 00:00:00 1970 From: "PaX Team" Date: Sat, 09 Jul 2016 23:16:36 +0000 Subject: Re: [PATCH 0/9] mm: Hardened usercopy Message-Id: <578185D4.29090.242668C8@pageexec.freemail.hu> List-Id: References: <1467843928-29351-1-git-send-email-keescook@chromium.org>, In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Kees Cook , Andy Lutomirski Cc: Christoph Lameter , Andrew Morton , Brad Spengler , Pekka Enberg , Ard Biesheuvel , Casey Schaufler , Will Deacon , Rik van Riel , Benjamin Herrenschmidt , Dmitry Vyukov , "linux-ia64@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , X86 ML , Catalin Marinas , linux-arch , David Rientjes , Mathias Krause , "kernel-hardening@lists.openwall.com" , "David S. Miller" , Laura Abbott , "linux-mm@kvack.org" , Jan Kara , Russell King , Michael Ellerman , Andrea Arcangeli , Fenghua Yu , linuxppc-dev@lists.ozlabs.org, Vitaly Wool , "linux-kernel@vger.kernel.org" , Borislav Petkov , Tony Luck , Joonsoo Kim , sparclinux@vger.kernel.org On 9 Jul 2016 at 14:27, Andy Lutomirski wrote: > On Jul 6, 2016 6:25 PM, "Kees Cook" wrote: > > > > Hi, > > > > This is a start of the mainline port of PAX_USERCOPY[1]. After I started > > writing tests (now in lkdtm in -next) for Casey's earlier port[2], I > > kept tweaking things further and further until I ended up with a whole > > new patch series. To that end, I took Rik's feedback and made a number > > of other changes and clean-ups as well. > > > > I like the series, but I have one minor nit to pick. The effect of > this series is to harden usercopy, but most of the code is really > about infrastructure to validate that a pointed-to object is valid. actually USERCOPY has never been about validating pointers. its sole purpose is to validate the *size* argument of copy*user calls, a very specific form of runtime bounds checking. it's only really relevant for slab objects and the pointer checks (that one might mistake for being a part of the defense mechanism) are only there to determine whether the kernel pointer refers to a slab object or not (the stack part is a small bonus and was never the main goal either). > Might it make sense to call the infrastructure part something else? yes, more bikeshedding will surely help, like the renaming of .data..read_only to .data..ro_after_init which also had nothing to do with init but everything to do with objects being conceptually read-only... > After all, this could be extended in the future for memcpy or even for > some GCC plugin to check pointers passed to ordinary (non-allocator) > functions. what kind of checks are you thinking of here? and more fundamentally, against what kind of threats? as for memcpy, it's the standard mandated memory copying function, what security related properties can it check on its pointer arguments? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f71.google.com (mail-wm0-f71.google.com [74.125.82.71]) by kanga.kvack.org (Postfix) with ESMTP id DBBF36B0005 for ; Sat, 9 Jul 2016 19:17:29 -0400 (EDT) Received: by mail-wm0-f71.google.com with SMTP id o80so3433679wme.1 for ; Sat, 09 Jul 2016 16:17:29 -0700 (PDT) Received: from r00tworld.com (r00tworld.com. [212.85.137.150]) by mx.google.com with ESMTPS id uv1si174795wjc.96.2016.07.09.16.17.28 for (version=TLS1 cipher=AES128-SHA bits=128/128); Sat, 09 Jul 2016 16:17:28 -0700 (PDT) From: "PaX Team" Date: Sun, 10 Jul 2016 01:16:36 +0200 MIME-Version: 1.0 Subject: Re: [PATCH 0/9] mm: Hardened usercopy Reply-to: pageexec@freemail.hu Message-ID: <578185D4.29090.242668C8@pageexec.freemail.hu> In-reply-to: References: <1467843928-29351-1-git-send-email-keescook@chromium.org>, Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Sender: owner-linux-mm@kvack.org List-ID: To: Kees Cook , Andy Lutomirski Cc: Christoph Lameter , Andrew Morton , Brad Spengler , Pekka Enberg , Ard Biesheuvel , Casey Schaufler , Will Deacon , Rik van Riel , Benjamin Herrenschmidt , Dmitry Vyukov , "linux-ia64@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , X86 ML , Catalin Marinas , linux-arch , David Rientjes , Mathias Krause , "kernel-hardening@lists.openwall.com" , "David S. Miller" , Laura Abbott , "linux-mm@kvack.org" , Jan Kara , Russell King , Michael Ellerman , Andrea Arcangeli , Fenghua Yu , linuxppc-dev@lists.ozlabs.org, Vitaly Wool , "linux-kernel@vger.kernel.org" , Borislav Petkov , Tony Luck , Joonsoo Kim , sparclinux@vger.kernel.org On 9 Jul 2016 at 14:27, Andy Lutomirski wrote: > On Jul 6, 2016 6:25 PM, "Kees Cook" wrote: > > > > Hi, > > > > This is a start of the mainline port of PAX_USERCOPY[1]. After I started > > writing tests (now in lkdtm in -next) for Casey's earlier port[2], I > > kept tweaking things further and further until I ended up with a whole > > new patch series. To that end, I took Rik's feedback and made a number > > of other changes and clean-ups as well. > > > > I like the series, but I have one minor nit to pick. The effect of > this series is to harden usercopy, but most of the code is really > about infrastructure to validate that a pointed-to object is valid. actually USERCOPY has never been about validating pointers. its sole purpose is to validate the *size* argument of copy*user calls, a very specific form of runtime bounds checking. it's only really relevant for slab objects and the pointer checks (that one might mistake for being a part of the defense mechanism) are only there to determine whether the kernel pointer refers to a slab object or not (the stack part is a small bonus and was never the main goal either). > Might it make sense to call the infrastructure part something else? yes, more bikeshedding will surely help, like the renaming of .data..read_only to .data..ro_after_init which also had nothing to do with init but everything to do with objects being conceptually read-only... > After all, this could be extended in the future for memcpy or even for > some GCC plugin to check pointers passed to ordinary (non-allocator) > functions. what kind of checks are you thinking of here? and more fundamentally, against what kind of threats? as for memcpy, it's the standard mandated memory copying function, what security related properties can it check on its pointer arguments? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from r00tworld.com (r00tworld.com [212.85.137.150]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3rn7PF22N4zDqwR for ; Sun, 10 Jul 2016 09:49:20 +1000 (AEST) From: "PaX Team" To: Kees Cook , Andy Lutomirski Date: Sun, 10 Jul 2016 01:16:36 +0200 MIME-Version: 1.0 Subject: Re: [PATCH 0/9] mm: Hardened usercopy Reply-to: pageexec@freemail.hu CC: Christoph Lameter , Andrew Morton , Brad Spengler , Pekka Enberg , Ard Biesheuvel , Casey Schaufler , Will Deacon , Rik van Riel , Benjamin Herrenschmidt , Dmitry Vyukov , "linux-ia64@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , X86 ML , Catalin Marinas , linux-arch , David Rientjes , Mathias Krause , "kernel-hardening@lists.openwall.com" , "David S. Miller" , Laura Abbott , "linux-mm@kvack.org" , Jan Kara , Russell King , Michael Ellerman , Andrea Arcangeli , Fenghua Yu , linuxppc-dev@lists.ozlabs.org, Vitaly Wool , "linux-kernel@vger.kernel.org" , Borislav Petkov , Tony Luck , Joonsoo Kim , sparclinux@vger.kernel.org Message-ID: <578185D4.29090.242668C8@pageexec.freemail.hu> In-reply-to: References: <1467843928-29351-1-git-send-email-keescook@chromium.org>, Content-type: text/plain; charset=US-ASCII List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 9 Jul 2016 at 14:27, Andy Lutomirski wrote: > On Jul 6, 2016 6:25 PM, "Kees Cook" wrote: > > > > Hi, > > > > This is a start of the mainline port of PAX_USERCOPY[1]. After I started > > writing tests (now in lkdtm in -next) for Casey's earlier port[2], I > > kept tweaking things further and further until I ended up with a whole > > new patch series. To that end, I took Rik's feedback and made a number > > of other changes and clean-ups as well. > > > > I like the series, but I have one minor nit to pick. The effect of > this series is to harden usercopy, but most of the code is really > about infrastructure to validate that a pointed-to object is valid. actually USERCOPY has never been about validating pointers. its sole purpose is to validate the *size* argument of copy*user calls, a very specific form of runtime bounds checking. it's only really relevant for slab objects and the pointer checks (that one might mistake for being a part of the defense mechanism) are only there to determine whether the kernel pointer refers to a slab object or not (the stack part is a small bonus and was never the main goal either). > Might it make sense to call the infrastructure part something else? yes, more bikeshedding will surely help, like the renaming of .data..read_only to .data..ro_after_init which also had nothing to do with init but everything to do with objects being conceptually read-only... > After all, this could be extended in the future for memcpy or even for > some GCC plugin to check pointers passed to ordinary (non-allocator) > functions. what kind of checks are you thinking of here? and more fundamentally, against what kind of threats? as for memcpy, it's the standard mandated memory copying function, what security related properties can it check on its pointer arguments? From mboxrd@z Thu Jan 1 00:00:00 1970 From: pageexec@freemail.hu (PaX Team) Date: Sun, 10 Jul 2016 01:16:36 +0200 Subject: [PATCH 0/9] mm: Hardened usercopy In-Reply-To: References: <1467843928-29351-1-git-send-email-keescook@chromium.org>, Message-ID: <578185D4.29090.242668C8@pageexec.freemail.hu> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 9 Jul 2016 at 14:27, Andy Lutomirski wrote: > On Jul 6, 2016 6:25 PM, "Kees Cook" wrote: > > > > Hi, > > > > This is a start of the mainline port of PAX_USERCOPY[1]. After I started > > writing tests (now in lkdtm in -next) for Casey's earlier port[2], I > > kept tweaking things further and further until I ended up with a whole > > new patch series. To that end, I took Rik's feedback and made a number > > of other changes and clean-ups as well. > > > > I like the series, but I have one minor nit to pick. The effect of > this series is to harden usercopy, but most of the code is really > about infrastructure to validate that a pointed-to object is valid. actually USERCOPY has never been about validating pointers. its sole purpose is to validate the *size* argument of copy*user calls, a very specific form of runtime bounds checking. it's only really relevant for slab objects and the pointer checks (that one might mistake for being a part of the defense mechanism) are only there to determine whether the kernel pointer refers to a slab object or not (the stack part is a small bonus and was never the main goal either). > Might it make sense to call the infrastructure part something else? yes, more bikeshedding will surely help, like the renaming of .data..read_only to .data..ro_after_init which also had nothing to do with init but everything to do with objects being conceptually read-only... > After all, this could be extended in the future for memcpy or even for > some GCC plugin to check pointers passed to ordinary (non-allocator) > functions. what kind of checks are you thinking of here? and more fundamentally, against what kind of threats? as for memcpy, it's the standard mandated memory copying function, what security related properties can it check on its pointer arguments? From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com From: "PaX Team" Date: Sun, 10 Jul 2016 01:16:36 +0200 MIME-Version: 1.0 Message-ID: <578185D4.29090.242668C8@pageexec.freemail.hu> In-reply-to: References: <1467843928-29351-1-git-send-email-keescook@chromium.org>, Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Subject: [kernel-hardening] Re: [PATCH 0/9] mm: Hardened usercopy To: Kees Cook , Andy Lutomirski Cc: Christoph Lameter , Andrew Morton , Brad Spengler , Pekka Enberg , Ard Biesheuvel , Casey Schaufler , Will Deacon , Rik van Riel , Benjamin Herrenschmidt , Dmitry Vyukov , "linux-ia64@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , X86 ML , Catalin Marinas , linux-arch , David Rientjes , Mathias Krause , "kernel-hardening@lists.openwall.com" , "David S. Miller" , Laura Abbott , "linux-mm@kvack.org" , Jan Kara , Russell King , Michael Ellerman , Andrea Arcangeli , Fenghua Yu , linuxppc-dev@lists.ozlabs.org, Vitaly Wool , "linux-kernel@vger.kernel.org" , Borislav Petkov , Tony Luck , Joonsoo Kim , sparclinux@vger.kernel.org List-ID: On 9 Jul 2016 at 14:27, Andy Lutomirski wrote: > On Jul 6, 2016 6:25 PM, "Kees Cook" wrote: > > > > Hi, > > > > This is a start of the mainline port of PAX_USERCOPY[1]. After I started > > writing tests (now in lkdtm in -next) for Casey's earlier port[2], I > > kept tweaking things further and further until I ended up with a whole > > new patch series. To that end, I took Rik's feedback and made a number > > of other changes and clean-ups as well. > > > > I like the series, but I have one minor nit to pick. The effect of > this series is to harden usercopy, but most of the code is really > about infrastructure to validate that a pointed-to object is valid. actually USERCOPY has never been about validating pointers. its sole purpose is to validate the *size* argument of copy*user calls, a very specific form of runtime bounds checking. it's only really relevant for slab objects and the pointer checks (that one might mistake for being a part of the defense mechanism) are only there to determine whether the kernel pointer refers to a slab object or not (the stack part is a small bonus and was never the main goal either). > Might it make sense to call the infrastructure part something else? yes, more bikeshedding will surely help, like the renaming of .data..read_only to .data..ro_after_init which also had nothing to do with init but everything to do with objects being conceptually read-only... > After all, this could be extended in the future for memcpy or even for > some GCC plugin to check pointers passed to ordinary (non-allocator) > functions. what kind of checks are you thinking of here? and more fundamentally, against what kind of threats? as for memcpy, it's the standard mandated memory copying function, what security related properties can it check on its pointer arguments?