linux-kernel - Re: AMD-IOMMU and problem with _

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:	Tue, 29 Sep 2015 19:17:41 +0200
From:	Alexander Holler <holler@...oftware.de>
To:	Joerg Roedel <joro@...tes.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: AMD-IOMMU and problem with __init(data)?

Am 29.09.2015 um 17:06 schrieb Joerg Roedel:
> As expected it is no bug in the AMD IOMMU driver, but in your code.
>
> On Wed, Sep 23, 2015 at 09:04:31PM +0200, Alexander Holler wrote:
>> struct _annotated_initcall {
>> 	initcall_t initcall;
>> 	unsigned driver_id;
>> 	unsigned *dependencies;
>> 	struct device_driver *driver;
>> };
>
> This struct gets aligned on a 32 bytes boundary.
>
>> +#define ANNOTATED_INITCALLS						\
>> +		VMLINUX_SYMBOL(__annotated_initcall_start) = .;		\
>> +		*(.annotated_initcall.init)				\
>> +		VMLINUX_SYMBOL(__annotated_initcall_end) = .;
>
> But this section does not.
>
>> +	ac = __annotated_initcall_start;
>> +	pr_info("ac %p ID %u\n", ac, ac->driver_id);
>> +	BUG_ON(ac->driver_id != 23);
>
> So when you access __annotated_initcall_start here, you don't access the
> first element of your array, but actually the zero padding before your
> struct.
>
> On my system the section was aligned on an 8 bytes boundary, which means
> there were 24 bytes of padding before the symbol you try to access.

Hmm. Thanks a lot. Also I've checked the alignment (at least twice) and 
remember it was 32bit. But maybe I've checked something different or 
looked at some file for ARM or x86(_32) or was confused or similar. But 
now, when I look at ARM the initcall section seems to be aligned to 8 
too. So I wonder why the stuff works on ARM (v5 and v7) and on an Intel 
Atom (32bit). I think at least the armv5 box should have trapped (fatal) 
too, but maybe that changed.

Sorry for not having looked at the alignment at least once more. 
Alignment bugs are always hard to see and I've already assumed such, 
especially because any other kernel seems to work, but I was obviously 
unable to see it.

Again, thanks a lot.

Regards,

Alexander Holler
--
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/