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
| ||
|
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
Powered by blists - more mailing lists