LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Daniel Micay <danielmicay@gmail.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Kees Cook <keescook@chromium.org>,
	kernel list <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Miguel Ojeda <ojeda@kernel.org>,
	Nathan Chancellor <nathan@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Christoph Lameter <cl@linux.com>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Vlastimil Babka <vbabka@suse.cz>, Dennis Zhou <dennis@kernel.org>,
	Tejun Heo <tj@kernel.org>, Masahiro Yamada <masahiroy@kernel.org>,
	Michal Marek <michal.lkml@markovi.net>,
	clang-built-linux@googlegroups.com, Linux-MM <linux-mm@kvack.org>,
	linux-kbuild <linux-kbuild@vger.kernel.org>,
	linux-hardening@vger.kernel.org
Subject: Re: [PATCH 0/5] Add __alloc_size() for better bounds checking
Date: Thu, 19 Aug 2021 10:18:47 -0400	[thread overview]
Message-ID: <CA+DvKQL6pLfK1vRzaOkEWR7DQLgTh=WZTka2L5yuS8Lf_1ZmoA@mail.gmail.com> (raw)
In-Reply-To: <YR4frlpfJQonPuKp@infradead.org>

It tells the compiler the function will either return NULL or an
allocation of the size specific by the parameter referenced by
alloc_size. It could also be used for functions resembling allocation
functions which aren't actually allocating. The compiler will use it
for optimization so it's extremely important that it's only used
correctly. It only really has a use on the top-level API used
externally.

The compiler uses it for __builtin_object_size which is primarily used
by FORTIFY_SOURCE and also internally by -fsanitize=object-size which
will be available for the kernel via UBSan to find bugs or as
hardening in the trapping mode. There are currently compatibility
issues (undefined out-of-bounds accesses) blocking using
-fsanitize=object-size beyond fixing those relatively benign issues to
allow using it elsewhere.

For example, it will know that kmalloc(n) returns either NULL or an
allocation of size n. A simple sample program with calloc in
userspace:

    #include <stdlib.h>
    #include <stdio.h>

    int main(void) {
        char *p = calloc(64, 1);
        if (!p) {
            return 1;
        }
        printf("%zu\n", __builtin_object_size(p, 1));
        return 0;
    }

It will also detect an out-of-bounds access via the allocation with
-fsanitize=object-size including with a runtime value as the index.

It's not as useful as it should be yet because __builtin_object_size
must return a compile-time constant. Clang has a new
__builtin_dynamic_object_size that's allowed to return a value that's
not a compile-time constant so it can work for kmalloc(n) where n is a
runtime value. It might not be quite ready for use yet but it should
be able to make it a lot more useful. GCC also seems open to adding it
too.

  reply	other threads:[~2021-08-19 14:19 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-18  5:08 Kees Cook
2021-08-18  5:08 ` [PATCH 1/5] Compiler Attributes: " Kees Cook
2021-08-18 13:07   ` Miguel Ojeda
2021-08-18 17:58     ` Kees Cook
2021-08-18 18:04   ` Nathan Chancellor
2021-08-18 21:04     ` Kees Cook
2021-08-18  5:08 ` [PATCH 2/5] slab: Add __alloc_size attributes " Kees Cook
2021-08-18  5:31   ` Joe Perches
2021-08-18  6:16     ` Kees Cook
2021-08-18  6:30       ` Joe Perches
2021-08-19  0:27     ` Matthew Wilcox
2021-08-19  1:10       ` Joe Perches
2021-08-19  2:16         ` Matthew Wilcox
2021-08-19  2:59           ` Joe Perches
2021-08-18  5:08 ` [PATCH 3/5] mm/page_alloc: " Kees Cook
2021-08-18  5:08 ` [PATCH 4/5] percpu: " Kees Cook
2021-08-18  5:08 ` [PATCH 5/5] mm/vmalloc: " Kees Cook
2021-08-19  9:09 ` [PATCH 0/5] Add __alloc_size() " Christoph Hellwig
2021-08-19 14:18   ` Daniel Micay [this message]
2021-08-25 10:01     ` Christoph Lameter
2021-08-25 16:34       ` Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+DvKQL6pLfK1vRzaOkEWR7DQLgTh=WZTka2L5yuS8Lf_1ZmoA@mail.gmail.com' \
    --to=danielmicay@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=clang-built-linux@googlegroups.com \
    --cc=dennis@kernel.org \
    --cc=hch@infradead.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=keescook@chromium.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=masahiroy@kernel.org \
    --cc=michal.lkml@markovi.net \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=ojeda@kernel.org \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=tj@kernel.org \
    --cc=vbabka@suse.cz \
    --subject='Re: [PATCH 0/5] Add __alloc_size() for better bounds checking' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).