GCC diff needs testing on multiple arches

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

GCC diff needs testing on multiple arches

Matthew Dempsky-3
First, make sure you're using a reasonably up to date snapshot.
You're up to date if "nm /usr/lib/crtbegin.o" mentions __guard_local.

Next, apply the patch below to GCC, recompile, and install:

  $ cd /usr/src/gnu/gcc/gcc
  $ patch < /path/to/diff
  $ cd /usr/src/gnu/usr.bin/cc
  $ make depend && make && make install

Finally, test that stuff still works after you build it. :) In
particular, make sure that you can still do a full "make build" by
following release(8).

Please email me back with test reports.  I'm interested in getting a
variety of (ELF) architectures before committing this.

Thanks!


Index: targhooks.c
===================================================================
RCS file: /cvs/src/gnu/gcc/gcc/targhooks.c,v
retrieving revision 1.2
diff -u -p -r1.2 targhooks.c
--- targhooks.c 9 May 2010 11:48:50 -0000 1.2
+++ targhooks.c 29 Aug 2012 18:05:48 -0000
@@ -372,7 +372,7 @@ default_stack_protect_guard (void)
 
   if (t == NULL)
     {
-      t = build_decl (VAR_DECL, get_identifier ("__guard"), ptr_type_node);
+      t = build_decl (VAR_DECL, get_identifier ("__guard_local"), ptr_type_node);
       TREE_STATIC (t) = 1;
       TREE_PUBLIC (t) = 1;
       DECL_EXTERNAL (t) = 1;
@@ -380,6 +380,8 @@ default_stack_protect_guard (void)
       TREE_THIS_VOLATILE (t) = 1;
       DECL_ARTIFICIAL (t) = 1;
       DECL_IGNORED_P (t) = 1;
+      DECL_VISIBILITY (t) = VISIBILITY_HIDDEN;
+      DECL_VISIBILITY_SPECIFIED (t) = 1;
 
       stack_chk_guard_decl = t;
     }

Reply | Threaded
Open this post in threaded view
|

Re: GCC diff needs testing on multiple arches

Matthew Dempsky-3
Just pinging this again since I've only received one test report so
far, and this really needs more testing on architectures other than
just amd64.  alpha and hppa don't have -fstack-protector, so really
that means arm, i386, mips, powerpc, sh, and sparc64.  Please please
please test if you have one of these machines!

Making sure this works is an important step towards enabling
-fstack-protector-all.  It also makes -fstack-protector emit slightly
smaller, slightly faster, and slightly more secure code for shared
libraries, all of which are nice perks.


On Wed, Aug 29, 2012 at 11:16:16AM -0700, Matthew Dempsky wrote:

> First, make sure you're using a reasonably up to date snapshot.
> You're up to date if "nm /usr/lib/crtbegin.o" mentions __guard_local.
>
> Next, apply the patch below to GCC, recompile, and install:
>
>   $ cd /usr/src/gnu/gcc/gcc
>   $ patch < /path/to/diff
>   $ cd /usr/src/gnu/usr.bin/cc
>   $ make depend && make && make install
>
> Finally, test that stuff still works after you build it. :) In
> particular, make sure that you can still do a full "make build" by
> following release(8).
>
> Please email me back with test reports.  I'm interested in getting a
> variety of (ELF) architectures before committing this.
>
> Thanks!
>
>
> Index: targhooks.c
> ===================================================================
> RCS file: /cvs/src/gnu/gcc/gcc/targhooks.c,v
> retrieving revision 1.2
> diff -u -p -r1.2 targhooks.c
> --- targhooks.c 9 May 2010 11:48:50 -0000 1.2
> +++ targhooks.c 29 Aug 2012 18:05:48 -0000
> @@ -372,7 +372,7 @@ default_stack_protect_guard (void)
>  
>    if (t == NULL)
>      {
> -      t = build_decl (VAR_DECL, get_identifier ("__guard"), ptr_type_node);
> +      t = build_decl (VAR_DECL, get_identifier ("__guard_local"), ptr_type_node);
>        TREE_STATIC (t) = 1;
>        TREE_PUBLIC (t) = 1;
>        DECL_EXTERNAL (t) = 1;
> @@ -380,6 +380,8 @@ default_stack_protect_guard (void)
>        TREE_THIS_VOLATILE (t) = 1;
>        DECL_ARTIFICIAL (t) = 1;
>        DECL_IGNORED_P (t) = 1;
> +      DECL_VISIBILITY (t) = VISIBILITY_HIDDEN;
> +      DECL_VISIBILITY_SPECIFIED (t) = 1;
>  
>        stack_chk_guard_decl = t;
>      }

Reply | Threaded
Open this post in threaded view
|

Re: GCC diff needs testing on multiple arches

Matthew Dempsky-3
In reply to this post by Matthew Dempsky-3
On Wed, Aug 29, 2012 at 11:16 AM, Matthew Dempsky <[hidden email]> wrote:
> First, make sure you're using a reasonably up to date snapshot.
> You're up to date if "nm /usr/lib/crtbegin.o" mentions __guard_local.

At least two people have commented that the snapshots they downloaded
don't have __guard_local yet.  Here's are some extra preliminary steps
to help users with old snapshots:

First, binutils needs to be up to date (i.e., less than 9 days old).
If it's up to date, then "ld --verbose | grep -c randomdata" will
print a non-zero value.  If it prints zero, follow the steps at
http://www.openbsd.org/faq/current.html#20120823 to update it.

Next, your C runtime files need to be up to date.  If it's up to date,
then "nm /usr/lib/crtbegin.o | grep -c __guard_local" will print a
non-zero value.  If it prints zero, follow these steps to update them:

    $ cd /usr/src/lib/csu
    $ make depend && make && make install

You can now follow my original steps for patching GCC.

Reply | Threaded
Open this post in threaded view
|

Re: GCC diff needs testing on multiple arches

Theo de Raadt
> On Wed, Aug 29, 2012 at 11:16 AM, Matthew Dempsky <[hidden email]> wrote:
> > First, make sure you're using a reasonably up to date snapshot.
> > You're up to date if "nm /usr/lib/crtbegin.o" mentions __guard_local.
>
> At least two people have commented that the snapshots they downloaded
> don't have __guard_local yet.  Here's are some extra preliminary steps
> to help users with old snapshots:

Hmm, that sounds unlikely.  Almost all the architectures crossed
over a few days ago, so..

Reply | Threaded
Open this post in threaded view
|

Re: GCC diff needs testing on multiple arches

Paulm-7
On Thu, Aug 30, 2012 at 04:29:26PM -0600, Theo de Raadt wrote:

> > On Wed, Aug 29, 2012 at 11:16 AM, Matthew Dempsky <[hidden email]> wrote:
> > > First, make sure you're using a reasonably up to date snapshot.
> > > You're up to date if "nm /usr/lib/crtbegin.o" mentions __guard_local.
> >
> > At least two people have commented that the snapshots they downloaded
> > don't have __guard_local yet.  Here's are some extra preliminary steps
> > to help users with old snapshots:
>
> Hmm, that sounds unlikely.  Almost all the architectures crossed
> over a few days ago, so..
>

In case it matters (from 8/25 snapshot on sparc64):


#  nm /usr/lib/crtbegin.o              
         U _GLOBAL_OFFSET_TABLE_
         U _Jv_RegisterClasses
00000000 d __CTOR_LIST__
00000000 d __DTOR_LIST__
00000000 d __EH_FRAME_BEGIN__
00000000 d __JCR_LIST__
00000000 D __dso_handle
00000000 T __fini
00000000 T __init
00000000 W __register_frame_info
         U atexit
0000000c d finalized.2264
00000008 d initialized.2258
00000000 b object.2259




OpenBSD 5.2-current (GENERIC.MP) #3: Sat Aug 25 15:54:01 MDT 2012
    [hidden email]:/usr/src/sys/arch/sparc64/compile/GENERIC.MP
real mem = 2147483648 (2048MB)
avail mem = 2101051392 (2003MB)
mainbus0 at root: Sun Ultra 80 UPA/PCI (4 X UltraSPARC-II 450MHz)
cpu0 at mainbus0: SUNW,UltraSPARC-II (rev 10.0) @ 450.061 MHz
cpu0: physical 16K instruction (32 b/l), 16K data (32 b/l), 4096K external (64 b/l)
cpu1 at mainbus0: SUNW,UltraSPARC-II (rev 10.0) @ 450.061 MHz
cpu1: physical 16K instruction (32 b/l), 16K data (32 b/l), 4096K external (64 b/l)
cpu2 at mainbus0: SUNW,UltraSPARC-II (rev 10.0) @ 450.061 MHz
cpu2: physical 16K instruction (32 b/l), 16K data (32 b/l), 4096K external (64 b/l)
cpu3 at mainbus0: SUNW,UltraSPARC-II (rev 10.0) @ 450.061 MHz
cpu3: physical 16K instruction (32 b/l), 16K data (32 b/l), 4096K external (64 b/l)
psycho0 at mainbus0 addr 0xfffb4000: SUNW,psycho, impl 0, version 4, ign 7c0
psycho0: bus range 0-0, PCI bus 0
psycho0: dvma map fe000000-ffffffff, STC0 enabled
pci0 at psycho0
ebus0 at pci0 dev 1 function 0 "Sun PCIO EBus2" rev 0x01
auxio0 at ebus0 addr 726000-726003, 728000-728003, 72a000-72a003, 72c000-72c003, 72f000-72f003
power0 at ebus0 addr 724000-724003 ivec 0x25
"SUNW,pll" at ebus0 addr 504000-504002 not configured
uperf0 at ebus0 addr 500000-500007: model SUNW,sc-qp (0/1) ports 9
sab0 at ebus0 addr 400000-40007f ivec 0x2b: rev 3.2
sabtty0 at sab0 port 0: console
sabtty1 at sab0 port 1
comkbd0 at ebus0 addr 3083f8-3083ff ivec 0x29: no keyboard
comms0 at ebus0 addr 3062f8-3062ff ivec 0x2a
wsmouse0 at comms0 mux 0
lpt0 at ebus0 addr 3043bc-3043cb, 300398-300399, 700000-70000f ivec 0x22: polled
clock1 at ebus0 addr 0-1fff: mk48t59
"flashprom" at ebus0 addr 0-fffff not configured
audioce0 at ebus0 addr 200000-2000ff, 702000-70200f, 704000-70400f, 722000-722003 ivec 0x23 ivec 0x24: nvaddrs 0
audio0 at audioce0
hme0 at pci0 dev 1 function 1 "Sun HME" rev 0x01: ivec 0x7e1, address 08:00:20:c5:13:64
luphy0 at hme0 phy 1: LU6612 10/100 PHY, rev. 1
siop0 at pci0 dev 3 function 0 "Symbios Logic 53c875" rev 0x14: ivec 0x7e0, using 4K of on-board RAM
scsibus0 at siop0: 16 targets, initiator 7
sd0 at scsibus0 targ 0 lun 0: <SEAGATE, ST39205LC, 5063> SCSI3 0/direct fixed serial.SEAGATE_ST39205LC_3DG03R1M00007145H81B
sd0: 8750MB, 512 bytes/sector, 17921835 sectors
sd1 at scsibus0 targ 1 lun 0: <SEAGATE, ST318404LSUN18G, 4207> SCSI3 0/direct fixed serial.SEAGATE_ST318404LSUN18G_3BT1BYE5000071099TSK
sd1: 17274MB, 512 bytes/sector, 35378533 sectors
cd0 at scsibus0 targ 6 lun 0: <TOSHIBA, DVD-ROM SD-M1401, 1009> SCSI2 5/cdrom removable
siop1 at pci0 dev 3 function 1 "Symbios Logic 53c875" rev 0x14: ivec 0x7e6, using 4K of on-board RAM
scsibus1 at siop1: 16 targets, initiator 7
psycho1 at mainbus0 addr 0xfffc6000: SUNW,psycho, impl 0, version 4, ign 7c0
psycho1: bus range 128-128, PCI bus 128
psycho1: dvma map fe000000-ffffffff, STC0 enabled, STC1 enabled
pci1 at psycho1
"counter-timer" at mainbus0 addr 0xfff9fc00 not configured
creator0 at mainbus0 addr 0xfebc0000: Creator3D, model SUNW,501-4788, dac 10
wsdisplay0 at creator0 mux 1
wsdisplay0: screen 0 added (std, sun emulation)
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
siop0: target 0 now using tagged 16 bit 20.0 MHz 16 REQ/ACK offset xfers
siop0: target 1 now using tagged 16 bit 20.0 MHz 16 REQ/ACK offset xfers
bootpath: /pci@1f,4000/scsi@3,0/disk@1,0
root on sd1a (6cc13f05b7e755cc.a) swap on sd1b dump on sd1b