Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 28 Oct 2022 16:19:37 -0700
From:   Kees Cook <keescook@chromium.org>
To:     Stanislav Fomichev <sdf@google.com>
Cc:     Alexei Starovoitov <ast@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        John Fastabend <john.fastabend@gmail.com>,
        Andrii Nakryiko <andrii@kernel.org>,
        Martin KaFai Lau <martin.lau@linux.dev>,
        Song Liu <song@kernel.org>, Yonghong Song <yhs@fb.com>,
        KP Singh <kpsingh@kernel.org>, Hao Luo <haoluo@google.com>,
        Jiri Olsa <jolsa@kernel.org>, bpf@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH] bpf: Use kmalloc_size_roundup() to match ksize() usage
Message-ID: <202210281617.F35925A52@keescook>
References: <20221018090550.never.834-kees@kernel.org>
 <Y07raim32wOBRGPi@google.com>
 <202210181110.CD92A00@keescook>
 <CAKH8qBvwKfhMYjHV=rizA0ZinArHKmBP6U_N63HTcZTmM=QQ+g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAKH8qBvwKfhMYjHV=rizA0ZinArHKmBP6U_N63HTcZTmM=QQ+g@mail.gmail.com>
Precedence: bulk

On Tue, Oct 18, 2022 at 01:07:45PM -0700, Stanislav Fomichev wrote:
> On Tue, Oct 18, 2022 at 11:19 AM Kees Cook <keescook@chromium.org> wrote:
> >
> > On Tue, Oct 18, 2022 at 11:07:38AM -0700, sdf@google.com wrote:
> > > On 10/18, Kees Cook wrote:
> > > > Round up allocations with kmalloc_size_roundup() so that the verifier's
> > > > use of ksize() is always accurate and no special handling of the memory
> > > > is needed by KASAN, UBSAN_BOUNDS, nor FORTIFY_SOURCE. Pass the new size
> > > > information back up to callers so they can use the space immediately,
> > > > so array resizing to happen less frequently as well. Explicitly zero
> > > > any trailing bytes in new allocations.
> > >
> > > > Additionally fix a memory allocation leak: if krealloc() fails, "arr"
> > > > wasn't freed, but NULL was return to the caller of realloc_array() would
> > > > be writing NULL to the lvalue, losing the reference to the original
> > > > memory.
> [...]
> > > > -   arr = krealloc_array(arr, new_n, size, GFP_KERNEL);
> > > > -   if (!arr)
> > > > +   alloc_size = kmalloc_size_roundup(size_mul(*new_n, size));
> > > > +   arr = krealloc(old_arr, alloc_size, GFP_KERNEL);
> > > > +   if (!arr) {
> > > > +           kfree(old_arr);
> > > >             return NULL;
> > > > +   }
> > >
> > > Any reason not do hide this complexity behind krealloc_array? Why can't
> > > it take care of those roundup details?
> >
> > It might be possible to do this with a macro, yes, but then callers
> > aren't in a position to take advantage of the new size. Maybe we need
> > something like:
> >
> >         arr = krealloc_up(old_arr, alloc_size, &new_size, GFP_KERNEL);
> 
> Maybe even krealloc_array_up(arr, &new_n, size, flags) or similar
> where we return a new size?
> Though I don't know if there are any other places in the kernel to
> reuse it and warrant a new function..

Yeah, and it explicitly can't be a function, since GCC has broken
attribute handling[1] for inlines. :(

Regardless, I'll respin this with a macro and see how it looks.

-Kees

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96503

-- 
Kees Cook