linux-kernel - Re: alpha: Checking source code positions for the setting of error codes

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: <20170118174320.GE1555@ZenIV.linux.org.uk>
Date:   Wed, 18 Jan 2017 17:43:20 +0000
From:   Al Viro <viro@...IV.linux.org.uk>
To:     SF Markus Elfring <elfring@...rs.sourceforge.net>
Cc:     linux-alpha@...r.kernel.org,
        Ivan Kokshaysky <ink@...assic.park.msu.ru>,
        Jan-Benedict Glaw <jbglaw@...-owl.de>,
        Matt Turner <mattst88@...il.com>,
        Nicolas Pitre <nicolas.pitre@...aro.org>,
        Richard Cochran <richardcochran@...il.com>,
        Richard Henderson <rth@...ddle.net>,
        Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>,
        kernel-janitors@...r.kernel.org
Subject: Re: alpha: Checking source code positions for the setting of error
 codes

On Wed, Jan 18, 2017 at 04:41:10PM +0100, SF Markus Elfring wrote:
> >> A local variable was set to an error code in two cases before a concrete
> >> error situation was detected. Thus move the corresponding assignment into
> >> an if branch to indicate a software failure there.
> >>
> >> This issue was detected by using the Coccinelle software.
> > 
> > Why the hell is that an issue?
> 
> * Can misplaced variable assignments result in unwanted run time consequences
>   because of the previous approach for a control flow specification?

More like the opposite.
	load constant to register
	test
	branch usually not taken
is considerably cheaper than
	test
	branch usually taken

Something like
	if (unlikely(foo)) {
		err = -ESOMETHING;
		goto sod_off;
	}
would be more or less on par (and quite possibly would be compiled into
the same code - depends upon the scheduling details for processor,
but speculative load of constant can be an optimization).  However, that
has an effect of splattering the source with tons of those unlikely() *and*
visually cluttering the common path.

> * How do you think about to achieve that error codes will only be set
>   after a specific software failure was detected?

Sounds like an arbitrary requirement, TBH...

Again, loading a constant into register tends to be cheap and easy to
combine with other instructions at CPU pipeline level.  If anything, this
pattern is a microoptimization, often in spots that are not on hotpaths
by any stretch of imagination.  But estimating whether a given place is
on a hot path takes a lot more delicate analysis than feasible for
cocci scripts.  And visual cluttering of the common execution path remains -
it doesn't matter for compiler, but it can matter a lot for human readers.