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:57:23 -0500

 This is a multi-part message in MIME format.
 --------------020508000404040706000903
 Content-Type: text/plain; charset=ISO-8859-1
 Content-Transfer-Encoding: 7bit
 
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 On 3/16/12 5:49 PM, Peter Wemm wrote:
 > On Fri, Mar 16, 2012 at 3:35 PM, Peter Wemm <peter at wemm.org>
 > 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.
 >> 
 >>> there will be a symlink in /sys/boot/ficl/machine that points
 >>> to i386/include.
 >> 
 >> And this is user error.  Don't do that.
 > 
 > More specifically..  You can't put code in the Makefiles that
 > modifies the source tree explicitly.
 > 
 > If sys/boot/userboot/ficl needs a different "#include <machine/*>" 
 > then sys/boot/userboot/ficl needs to create the machine link there
 > and set the -I paths so that one has precedence.
 userboot/ficl does build correctly without sym links
 
 It sounds like what you are saying it ficl/Makefile should
 be fixed to *NOT* create the symlink like it is stand currently.
 
 
 - -Russell
 
 > 
 > But reaching over and trying to modify another tool's build area
 > is always wrong, aside from the obvious problem of it trying to
 > modify the source tree.  If you're pulling the wrong include files
 > into userboot/ficl, then that's because machine and -I aren't being
 > set correctly in userboot/ficl/Makefile.
 > 
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.11 (Darwin)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
 iEYEARECAAYFAk9jxVMACgkQNRmM+OaGhBgfnACfbUGvWuaEoo/35nTUmWgNV4yz
 vCcAoIKVu0/DnZiahKN9gZWnk9JeUzXR
 =d1jj
 -----END PGP SIGNATURE-----
 
 --------------020508000404040706000903
 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
 
 
 --------------020508000404040706000903--