[Bug c/26457] New: -fstack-protector leaks the upper bits of RAX

[Bug c/26457] New: -fstack-protector leaks the upper bits of RAX

[arjan at linux dot intel dot com]

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

[Bug target/26457] -fstack-protector leaks the upper bits of RAX

[jakub at gcc dot gnu dot org]

------- 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

[Bug target/26457] -fstack-protector leaks the upper bits of RAX

[pinskia at gcc dot gnu dot org]

------- 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

[Bug target/26457] -fstack-protector leaks the upper bits of RAX

[pinskia at gcc dot gnu dot org]

------- 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

[Bug target/26457] -fstack-protector leaks the upper bits of RAX

[pluto at agmk dot net]

------- 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

[Bug target/26457] -fstack-protector leaks the upper bits of RAX

[jakub at gcc dot gnu dot org]

------- 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