linux-hardening - Re: [PATCH 4/4] fortify: Use __builtin_dynamic_object

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <450c41a1-9713-0928-338a-3f3d659b9894@gotplt.org>
Date:   Thu, 22 Sep 2022 10:45:05 -0400
From:   Siddhesh Poyarekar <siddhesh@...plt.org>
To:     Kees Cook <keescook@...omium.org>
Cc:     linux-hardening@...r.kernel.org, Miguel Ojeda <ojeda@...nel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Nathan Chancellor <nathan@...nel.org>,
        Tom Rix <trix@...hat.com>, llvm@...ts.linux.dev,
        Juergen Gross <jgross@...e.com>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/4] fortify: Use __builtin_dynamic_object_size() when
 available

On 2022-09-21 23:33, Kees Cook wrote:
> On Wed, Sep 21, 2022 at 07:43:17AM -0400, Siddhesh Poyarekar wrote:
>> On 2022-09-20 15:22, Kees Cook wrote:
>>> Since the commits starting with c37495d6254c ("slab: add __alloc_size
>>> attributes for better bounds checking"), the compilers have runtime
>>> allocation size hints available in some places. This was immediately
>>> available to CONFIG_UBSAN_BOUNDS, but CONFIG_FORTIFY_SOURCE needed
>>> updating to explicitly make use the hints via the associated
>>> __builtin_dynamic_object_size() helper. Detect and use the builtin when
>>> it is available, increasing the accuracy of the mitigation. When runtime
>>> sizes are not available, __builtin_dynamic_object_size() falls back to
>>> __builtin_object_size(), leaving the existing bounds checking unchanged.
>>
>> I don't know yet what the overhead is for __builtin_dynamic_object_size vs
>> __builtin_object_size, were you able to measure it somehow for the kernel?
>> If there's a significant tradeoff, it may make sense to provide a user
>> override.
> 
> So far I've not seen any measurable performance difference, but I just
> may not be creative enough yet.
> 
> So far, the tunable is building a kernel with or without FORTIFY_SOURCE
> and UBSAN_BOUNDS. :)
> 

The overhead should only be noticeable in, e.g. fortified calls inside a 
hot loop.  In theory expressions to compute sizes could be arbitrarily 
complex, but I haven't seen any cases yet that were large enough to be a 
bother.  I reckon if we find such use cases, it'll be in the kernel but 
even then it may not be worth downgrading fortification across all 
sources just for those specific hot paths.  So I agree, the user 
override isn't critically necessary.

FWIW,

Reviewed-by: Siddhesh Poyarekar <siddhesh@...plt.org>

Thanks,
Sid