public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/26457] New: -fstack-protector leaks the upper bits of RAX
@ 2006-02-24 15:08 arjan at linux dot intel dot com
2006-02-24 15:12 ` [Bug target/26457] " jakub at gcc dot gnu dot org
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: arjan at linux dot intel dot com @ 2006-02-24 15:08 UTC (permalink / raw)
To: gcc-bugs
The following code snippet, compiled with -Os -fstack-protector:
#include <string.h>
int StringChecksum(char *s)
{
char buffer[2048];
int i;
int checksum = 0;
memset(buffer, 0, 2048);
strcpy(buffer, s);
for (i=0; i<2048; i++)
checksum += buffer[i];
return checksum;
}
leads to the following snippet of assembly for the part where gcc puts the
canary value on the stack: (part of the full assembly of the function)
movq %rsp, %rdi
movq %fs:40, %rax
movq %rax, 2056(%rsp)
xorl %eax, %eax
call memset
the key instruction for this bug is the "xorl %eax, %eax". The intent of that
instruction seems to be to not leak the canary value into the actual function
code; however the canary value is 64 bits and in RAX, while the XOR is only
zeroing the lower 32 bits. For consistency and information security, this XOR
should, I think, clear all of RAX (which is same-cost anyway both in size and
execution)
--
Summary: -fstack-protector leaks the upper bits of RAX
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: arjan at linux dot intel dot com
GCC host triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26457
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug target/26457] -fstack-protector leaks the upper bits of RAX
2006-02-24 15:08 [Bug c/26457] New: -fstack-protector leaks the upper bits of RAX arjan at linux dot intel dot com
@ 2006-02-24 15:12 ` jakub at gcc dot gnu dot org
2006-02-24 15:20 ` pinskia at gcc dot gnu dot org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: jakub at gcc dot gnu dot org @ 2006-02-24 15:12 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from jakub at gcc dot gnu dot org 2006-02-24 15:11 -------
To my knowledge xorl %eax, %eax is just a shorter form of xorq %rax, %rax,
both clear all 64 bits of %rax.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26457
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug target/26457] -fstack-protector leaks the upper bits of RAX
2006-02-24 15:08 [Bug c/26457] New: -fstack-protector leaks the upper bits of RAX arjan at linux dot intel dot com
2006-02-24 15:12 ` [Bug target/26457] " jakub at gcc dot gnu dot org
@ 2006-02-24 15:20 ` pinskia at gcc dot gnu dot org
2006-03-02 14:00 ` pinskia at gcc dot gnu dot org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-02-24 15:20 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-24 15:12 -------
This is an issue of agrument passing really as eax is used to pass 0 to memset
though I don't know if this is really an issue or not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26457
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug target/26457] -fstack-protector leaks the upper bits of RAX
2006-02-24 15:08 [Bug c/26457] New: -fstack-protector leaks the upper bits of RAX arjan at linux dot intel dot com
2006-02-24 15:12 ` [Bug target/26457] " jakub at gcc dot gnu dot org
2006-02-24 15:20 ` pinskia at gcc dot gnu dot org
@ 2006-03-02 14:00 ` pinskia at gcc dot gnu dot org
2006-03-02 14:32 ` pluto at agmk dot net
2006-03-02 14:48 ` jakub at gcc dot gnu dot org
4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-03-02 14:00 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-02 14:00 -------
CCing Honza, maybe he knows the answer but I cannot find it in the ISA
documention.
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hubicka at gcc dot gnu dot
| |org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26457
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug target/26457] -fstack-protector leaks the upper bits of RAX
2006-02-24 15:08 [Bug c/26457] New: -fstack-protector leaks the upper bits of RAX arjan at linux dot intel dot com
` (2 preceding siblings ...)
2006-03-02 14:00 ` pinskia at gcc dot gnu dot org
@ 2006-03-02 14:32 ` pluto at agmk dot net
2006-03-02 14:48 ` jakub at gcc dot gnu dot org
4 siblings, 0 replies; 6+ messages in thread
From: pluto at agmk dot net @ 2006-03-02 14:32 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from pluto at agmk dot net 2006-03-02 14:32 -------
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24592.pdf
page 33:
[ Zero-Extension of 32-Bit Results. ]
(...) when performing 32-bit operations with a GPR destination
in 64-bit mode, the processor zero-extends the 32-bit result
into the full 64-bit destination. 8-bit and 16-bit operations on GPRs
preserve all unwritten upper bits of the destination GPR.
This is consistent with legacy 16-bit and 32-bit semantics for
partial-width results.
Software should explicitly sign-extend the results of 8-bit, 16-
bit, and 32-bit operations to the full 64-bit width before using
the results in 64-bit address calculations.
--
pluto at agmk dot net changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pluto at agmk dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26457
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug target/26457] -fstack-protector leaks the upper bits of RAX
2006-02-24 15:08 [Bug c/26457] New: -fstack-protector leaks the upper bits of RAX arjan at linux dot intel dot com
` (3 preceding siblings ...)
2006-03-02 14:32 ` pluto at agmk dot net
@ 2006-03-02 14:48 ` jakub at gcc dot gnu dot org
4 siblings, 0 replies; 6+ messages in thread
From: jakub at gcc dot gnu dot org @ 2006-03-02 14:48 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from jakub at gcc dot gnu dot org 2006-03-02 14:48 -------
(define_insn "*movdi_xor_rex64"
[(set (match_operand:DI 0 "register_operand" "=r")
(match_operand:DI 1 "const0_operand" "i"))
(clobber (reg:CC FLAGS_REG))]
"TARGET_64BIT && (!TARGET_USE_MOV0 || optimize_size)
&& reload_completed"
"xor{l}\t{%k0, %k0|%k0, %k0}"
[(set_attr "type" "alu1")
(set_attr "mode" "SI")
(set_attr "length_immediate" "0")])
and say:
long foo (void) { return 0; }
with -m64 -O2 gives:
xorl %eax, %eax
ret
If xorl %eax, %eax did not zero extend to 64-bits, GCC compiled code wouldn't
really work.
--
jakub at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26457
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-03-02 14:48 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-02-24 15:08 [Bug c/26457] New: -fstack-protector leaks the upper bits of RAX arjan at linux dot intel dot com
2006-02-24 15:12 ` [Bug target/26457] " jakub at gcc dot gnu dot org
2006-02-24 15:20 ` pinskia at gcc dot gnu dot org
2006-03-02 14:00 ` pinskia at gcc dot gnu dot org
2006-03-02 14:32 ` pluto at agmk dot net
2006-03-02 14:48 ` jakub at gcc dot gnu dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).