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] [day] [month] [year] [list]
Date:   Thu, 11 Jun 2020 07:58:00 -0500
From:   Alex Elder <elder@...aro.org>
To:     David Miller <davem@...emloft.net>
Cc:     kuba@...nel.org, evgreen@...omium.org, subashab@...eaurora.org,
        cpratapa@...eaurora.org, bjorn.andersson@...aro.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net 5/5] net: ipa: warn if gsi_trans structure is too big

On 6/10/20 6:36 PM, David Miller wrote:
> From: Alex Elder <elder@...aro.org>
> Date: Wed, 10 Jun 2020 14:53:32 -0500
> 
>> When the DEBUG_SPINLOCK and DEBUG_LOCK_ALLOC config options are
>> enabled, sizeof(raw_spinlock_t) grows considerably (from 4 bytes
>> to 56 bytes currently).  As a consequence the size of the gsi_trans
>> structure exceeds 128 bytes, and this triggers a BUILD_BUG_ON()
>> error.
>>
>> These are useful configuration options to enable, so rather than
>> causing a build failure, just issue a warning message at run time
>> if the structure is larger than we'd prefer.
>>
>> Signed-off-by: Alex Elder <elder@...aro.org>
> 
> Please fix the problem or prevent the build of this module in such
> configurations since obviously it will fail to load successfully.

It will not fail to load; this really shouldn't have been treated as
a BUG to begin with.  The condition can be detected at build time but
I'm not aware of a BUILD_WARN_ON() (which would probably break the
build anyway).  The check should at least have remained under the
control of IPA_VALIDATE, because it's really there for my benefit
so I'm told if the structure grows unexpectedly.

Your pushback on this has made me think a bit more about how much
of a problem this really is though, so I'll omit this last patch
in version 2 of this series that I will post today.  Then after a
little more consideration I'll post a revised version of this one
(or not).

Thanks.

					-Alex

> It is completely unexpected for something to fail at run time that
> could be detected at build time.
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ