linux-kernel - Re: somebody dropped a (warning) bomb

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:	Fri, 9 Feb 2007 23:05:36 +0100 (MET)
From:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
To:	"linux-os (Dick Johnson)" <linux-os@...logic.com>
cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	David Rientjes <rientjes@...gle.com>,
	Jeff Garzik <jeff@...zik.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: somebody dropped a (warning) bomb


On Feb 9 2007 15:29, linux-os (Dick Johnson) wrote:
>>
>> I was referring to "absolute memory", not the offset magic that assembler
>> allows. After all, (reg+relativeOffset) will yield an absolute address.
>> What I was out at: for machines that have more than 2 GB of memory, you
>> don't call the address that is given by 0x80000000U actually "byte
>> -2147483648", but "byte 2147483648".
>
>Don't make any large bets on that!
>
>char foo()
>{
>    volatile char *p = (char *)0x80000000;
>    return *p;
>}
>Optimized....
> 	.file	"zzz.c"
> 	.text
> 	.p2align 2,,3
>.globl foo
> 	.type	foo, @function
>foo:
> 	pushl	%ebp
> 	movb	-2147483648, %al
> 	movl	%esp, %ebp
> 	movsbl	%al,%eax
> 	leave
> 	ret
> 	.size	foo, .-foo
> 	.section	.note.GNU-stack,"",@progbits
> 	.ident	"GCC: (GNU) 3.3.3 20040412 (Red Hat Linux 3.3.3-7)"

00000000 <foo>:
   0:   55                      push   %ebp
   1:   0f b6 05 00 00 00 80    movzbl 0x80000000,%eax
   8:   89 e5                   mov    %esp,%ebp
   a:   5d                      pop    %ebp
   b:   0f be c0                movsbl %al,%eax
   e:   c3                      ret    

You do know that there is a bijection between the set of signed [32bit] 
integers and unsigned [32bit] integers, don't you?
For the CPU, it's just bits. Being signed or unsigned is not important 
when just accessing memory. It will, when a comparison is involved, but 
that was not the point here. void* comparisons are unsigned. Period.
Because a compiler doing signed comparisons will "map" the memory [from 
2 GB to 4 GB] as part of the signed comparison before the memory [from 0 
GB to 2 GB], which collides with - let's call it - "the world view".


Jan
-- 
ft: http://freshmeat.net/p/chaostables/
-
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/