amd64/163710: setjump in userboot.so causes stack corruption

[Russell Cattelan]

The following reply was made to PR amd64/163710; it has been noted by GNATS.

From: Russell Cattelan <cattelan at thebarn.com>
To: Peter Wemm <peter at wemm.org>
Cc: freebsd-gnats-submit at freebsd.org
Subject: Re: amd64/163710: setjump in userboot.so causes stack corruption
Date: Fri, 16 Mar 2012 17:54:56 -0500

 This is a multi-part message in MIME format.
 --------------070204030709090807020609
 Content-Type: text/plain; charset=ISO-8859-1
 Content-Transfer-Encoding: 7bit
 
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 On 3/16/12 5:35 PM, Peter Wemm wrote:
 > 2012/3/16 Russell Cattelan <cattelan at thebarn.com>:
 >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
 >> 
 >> On 3/16/12 3:51 PM, Peter Wemm wrote:
 >>> 2012/3/16 Russell Cattelan <cattelan at thebarn.com>:
 >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
 >>>> 
 >>>> On 3/16/12 11:56 AM, Peter Wemm wrote:
 >>>>> On Thu, Mar 15, 2012 at 2:40 PM, Russell Cattelan 
 >>>>> <cattelan at thebarn.com> wrote:
 >>>>>> The following reply was made to PR amd64/163710; it has
 >>>>>> been noted by GNATS.
 >>>>> [..]
 >>>>>> Does the last patch seem acceptable?
 >>>>>> 
 >>>>>> Can we close this issue out?
 >>>>> 
 >>>>> Sadly not,
 >>>>> 
 >>>>> +no-machine: + rm -f   ${.CURDIR}/../../ficl/machine
 >>>>> 
 >>>>> .. this is definitely bogus no matter what. This attempts
 >>>>> to modify the source tree which may be read only, and
 >>>>> should never even have a "machine->..." symlink in it to
 >>>>> remove in the first place.
 >>>> The sym link is created by the build of ficl for the loader.
 >>>> See: boot/ficl/Makefile machine: ln -sf
 >>>> ${.CURDIR}/../../i386/include machine
 >>>> 
 >>>> Are you suggesting that is incorrect and should be fixed?
 >>> 
 >>> No, you're reading it wrong: "ln -sf
 >>> ${.CURDIR}/../../i386/include machine" creates
 >>> ${.OBJDIR}/machine"
 >>> 
 >>> Your patch does a "rm -f   ${.CURDIR}/../../ficl/machine" which
 >>> is in the source tree, not the obj tree, so it would never
 >>> exist.  And if it does, then something is wrong with your build
 >>> environment.
 >>> 
 >> This is pretty easy to reproduce. cd /sys/boot make
 > 
 > You don't do that without a 'make obj' first.
 So this is the only supported build model?
 
 
 > 
 >> there will be a symlink in /sys/boot/ficl/machine that points to 
 >> i386/include.
 > 
 > And this is user error.  Don't do that.
 if an inplace build is not supported then shouldn't it just
 be flat out disabled?!!
 What is wrong with making the build more robust to odd error are
 not possible vs says "ohh ya don't do that"?
 
 
 - -Russell
 
 fwiw this is what happens if ficl/machine exists
 
 
 (gdb) print sizeof(jmp_buf)
 $1 = 48
 (gdb) ptype jmp_buf
 type = struct _jmp_buf {
     int _jb[12];
 } [1]
 (gdb)
 
 vs
 (gdb) ptype jmp_buf
 type = struct _jmp_buf {
     long int _jb[12];
 } [1]
 (gdb) print sizeof(jmp_buf)
 $1 = 96
 
 
 
 > 
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.11 (Darwin)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
 iEYEARECAAYFAk9jxMAACgkQNRmM+OaGhBiYTgCePFkTFRB78B9l/zgJ3xcV8JTe
 5GgAn2yRdVK/vEWTSSRswCyU1E6j0jq5
 =2JNI
 -----END PGP SIGNATURE-----
 
 --------------070204030709090807020609
 Content-Type: text/x-vcard; charset=utf-8;
  name="cattelan.vcf"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
  filename="cattelan.vcf"
 
 begin:vcard
 fn:Russell Cattelan
 n:Cattelan;Russell
 email;internet:cattelan at thebarn.com
 tel;cell:612 805 3144
 x-mozilla-html:FALSE
 version:2.1
 end:vcard
 
 
 --------------070204030709090807020609--