[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ping: [PATCH] flask: fix gcov build with gcc14+
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 21 Jan 2026 07:14:50 -0600
- Arc-authentication-results: i=1; mx.zohomail.com; dkim=pass header.i=apertussolutions.com; spf=pass smtp.mailfrom=dpsmith@xxxxxxxxxxxxxxxxxxxx; dmarc=pass header.from=<dpsmith@xxxxxxxxxxxxxxxxxxxx>
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1769001295; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=uns7QSNwfZ2z5ZOIiY2IgtVjluIMmOQ+/lgCVL/SR2s=; b=PHiKR95QYygf4n9MGF4LTShg5fT2SY31QGxkEpfJITFDtJswzjGRxDZVKG0cSVoSEaLIUOPWEJjgiGDeTpocArdV/dqL34RLXSwaut3OIPncsXAPyanY+lPc4DMRSpi64S/10NkMutrHd48/qd42SZev42/DheZnCrl/wNMF0JU=
- Arc-seal: i=1; a=rsa-sha256; t=1769001295; cv=none; d=zohomail.com; s=zohoarc; b=M2yZL+1bpzKrs0V2Fz/Y16XnbdlmdquZ4u5jQF3ieN4G3gguEzobiZrG+OOi4es8K3UYPz4QsJZi7WO77B0U5MYAXjeIrhuQ/FxEqslqxlIAuql04UfxmWASCnhBtQGFyc7e4FMkumO5V4uMqDDizzMGlC63xBCn0hNrVFdL6mU=
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Wed, 21 Jan 2026 13:15:09 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
Jan,
Apologies, I've been on travel for the last two weeks and I wasn't comfortable acking this with just a read of the diff. The thing that bothers me that I want to understand better is why only after the else does it worry about null terminated. Additionally, stepping back, a casual reader of the code is going to wonder why only after some reads into the buffer does it need a null while others do not. I think most people would find that as a red flag that an underlying issue is getting papers papered over. I will be back from travel this weekend and I will sit down and review with more context.
V/r, DPS
On January 19, 2026 8:50:02 AM CST, Jan Beulich <jbeulich@xxxxxxxx> wrote:
Daniel,
On 08.01.2026 10:18, Jan Beulich wrote:
Gcc's "threading" of conditionals can lead to undue warnings, as reported in e.g. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116519 (no matter that the overall situation is different there). While my gcc15 complains ("buf[2] may be used uninitialized in this function") about only two of the three instances (not about the one in type_read()), adjust all three to be on the safe side. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
any chance of an ack (or otherwise)?
Thanks, Jan
While auditing uses of next_entry(), I noticed POLICYDB_VERSION_ROLETRANS dependent ones in policydb_read(): How come the 4th slot isn't used at all there (not even checked for being e.g. zero, i.e. holding no useful data)? Then again other instances can be found where data is read but outright ignored.
--- a/xen/xsm/flask/ss/policydb.c +++ b/xen/xsm/flask/ss/policydb.c @@ -1271,7 +1271,10 @@ static int cf_check role_read(struct pol if ( ver >= POLICYDB_VERSION_BOUNDARY ) rc = next_entry(buf, fp, sizeof(buf[0]) * 3); else + { rc = next_entry(buf, fp, sizeof(buf[0]) * 2); + buf[2] = cpu_to_le32(0); /* gcc14 onwards */ + } if ( rc < 0 ) goto bad; @@ -1342,7 +1345,10 @@ static int cf_check type_read(struct pol if ( ver >= POLICYDB_VERSION_BOUNDARY ) rc = next_entry(buf, fp, sizeof(buf[0]) * 4); else + { rc = next_entry(buf, fp, sizeof(buf[0]) * 3); + buf[3] = cpu_to_le32(0); /* gcc14 onwards */ + } if ( rc < 0 ) goto bad; @@ -1436,7 +1442,10 @@ static int cf_check user_read(struct pol if ( ver >= POLICYDB_VERSION_BOUNDARY ) rc = next_entry(buf, fp, sizeof(buf[0]) * 3); else + { rc = next_entry(buf, fp, sizeof(buf[0]) * 2); + buf[2] = cpu_to_le32(0); /* gcc14 onwards */ + } if ( rc < 0 ) goto bad;
|