linux-kernel - Re: [git patches 1/2] warnings: attack valid cases spotted by warnings

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: <adamyxuo2w6.fsf@cisco.com>
Date:	Tue, 17 Jul 2007 19:35:05 -0700
From:	Roland Dreier <rdreier@...co.com>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	akpm@...ux-foundation.org, torvalds@...ux-foundation.org,
	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org,
	chas@....nrl.navy.mil, rolandd@...co.com, dwmw2@...radead.org,
	gregkh@...e.de
Subject: Re: [git patches 1/2] warnings: attack valid cases spotted by warnings

 > I don't buy that performance argument, in this case.  You are already
 > dirtying the same cacheline with other variable initializations.
 > 
 > Like I noted in the changeset description (hey, this is precisely why
 > I included it, so that we could have this discussion), IMO the flow of
 > control makes it not only impossible for the compiler to understand
 > the full value range of 'f0', but also difficult for humans as well.
 > 
 > I could perhaps understand initializing the variable to some poison
 > value rather than zero, but IMO the code is stronger with f0 set to a
 > sane value.

The more I think about it, the less sense initializing f0 to 0 makes.
The whole problem with an uninitialized variable is that a random
value from the stack might be used.  So setting a variable to
something meaningless (guaranteeing that a garbage value is used in
case of a bug) just to shut up a warning makes no sense -- it's no
safer than leaving the code as is.  uninitialized_var() gets rid of
the warning, saves a little text and instruction cache, and documents
things better.

(BTW, I agree the code is a little confusing as written.  I think
things could be cleaned up and made more efficient by getting rid of
the initialization of size0 too -- I'll look at doing that)

Anyway, I queued this up for my next merge with Linus:

commit 6d7d080e9f7cd535a8821efd3835c5cfa5223ab6
Author: Roland Dreier <rolandd@...co.com>
Date:   Tue Jul 17 19:30:51 2007 -0700

    IB/mthca: Use uninitialized_var() for f0
    
    Commit 9db48926 ("drivers/infiniband/hw/mthca/mthca_qp: kill uninit'd
    var warning") added "= 0" to the declarations of f0 to shut up gcc
    warnings.  However, there's no point in making the code bigger by
    initializing f0 to a random value just to get rid of a warning;
    setting f0 to 0 is no safer than just using uninitialized_var(), which
    documents the situation better and gives smaller code too.  For example,
    on x86_64:
    
    add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-16 (-16)
    function                                     old     new   delta
    mthca_tavor_post_send                       1352    1344      -8
    mthca_arbel_post_send                       1489    1481      -8
    
    Signed-off-by: Roland Dreier <rolandd@...co.com>

diff --git a/drivers/infiniband/hw/mthca/mthca_qp.c b/drivers/infiniband/hw/mthca/mthca_qp.c
index 11f1d99..0e9ef24 100644
--- a/drivers/infiniband/hw/mthca/mthca_qp.c
+++ b/drivers/infiniband/hw/mthca/mthca_qp.c
@@ -1591,7 +1591,13 @@ int mthca_tavor_post_send(struct ib_qp *ibqp, struct ib_send_wr *wr,
 	int i;
 	int size;
 	int size0 = 0;
-	u32 f0 = 0;
+	/*
+	 * f0 is only used if nreq != 0, and f0 will be initialized
+	 * the first time through the main loop, since size0 == 0 the
+	 * first time through.  So nreq cannot become non-zero without
+	 * initializing f0, and f0 is in fact never used uninitialized.
+	 */
+	u32 uninitialized_var(f0);
 	int ind;
 	u8 op0 = 0;
 
@@ -1946,7 +1952,13 @@ int mthca_arbel_post_send(struct ib_qp *ibqp, struct ib_send_wr *wr,
 	int i;
 	int size;
 	int size0 = 0;
-	u32 f0 = 0;
+	/*
+	 * f0 is only used if nreq != 0, and f0 will be initialized
+	 * the first time through the main loop, since size0 == 0 the
+	 * first time through.  So nreq cannot become non-zero without
+	 * initializing f0, and f0 is in fact never used uninitialized.
+	 */
+	u32 uninitialized_var(f0);
 	int ind;
 	u8 op0 = 0;
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/