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  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]
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

Powered by blists - more mailing lists