linux-kernel - Re: [RFC] Coverity 1128445 - Reliance on integer endianness

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]

Date:	Tue, 12 Nov 2013 15:30:24 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Geyslan Gregório Bem <geyslan@...il.com>
Cc:	paulus@...ba.org, Ingo Molnar <mingo@...hat.com>,
	acme@...stprotocols.net, kernel-br <kernel-br@...glegroups.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] Coverity 1128445 - Reliance on integer endianness

On Tue, Nov 12, 2013 at 12:19:13PM -0200, Geyslan Gregório Bem wrote:
> Hi,
> 
> Coverity detected in 'arch/x86/kernel/cpu/perf_event_intel_uncore.c' a
> possible reliance on integer endianness. Is that a positive one?
> 
> static u64 ivt_uncore_irp_read_counter(struct intel_uncore_box *box,
> struct perf_event *event)
> 1369{
> 1370        struct pci_dev *pdev = box->pci_dev;
> 1371        struct hw_perf_event *hwc = &event->hw;
> 1372        u64 count = 0;
> 1373
> 
> CID 1128445 (#1 of 1): Reliance on integer endianness
> (INCOMPATIBLE_CAST)incompatible_cast: Pointer "&count" points to an
> object whose effective type is "unsigned long long" (64 bits,
> unsigned) but is dereferenced as a narrower "unsigned int" (32 bits,
> unsigned). This may lead to unexpected results depending on machine
> endianness.[show details]
> 
> 1374        pci_read_config_dword(pdev, ivt_uncore_irp_ctrs[hwc->idx],
> (u32 *)&count);
> 1375        pci_read_config_dword(pdev, ivt_uncore_irp_ctrs[hwc->idx]
> + 4, (u32 *)&count + 1);
> 1376
> 1377        return count;
> 1378}

Right, its a bit ugly but since its all arch code (x86) we can indeed
assume endianness (little).

So yes Coverity is right but we can also ignore it since machine
endianness is fixed here.

The code loads the u64 in two pci dword reads and assumes the high dword
lives at the higher address, this is correct for little endian.
--
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/