Re: botan i386 segfault [was Re: devel/monotone i386 breakage, maybe following libc++ update?]

[Theo de Raadt]

Alexander Bluhm  wrote:

> On Thu, Jun 27, 2019 at 10:08:37PM +0100, Stuart Henderson wrote:
> > #0  0x082eefff in botan_sha160_x86_32_compress () from 
> > /usr/local/lib/libbotan-1.10.so.1.1
> 
> This code is at a page boundary, so it traps into the kernel.  There
> it is detected that the esp register is currently not on the stack.
> 
> The hand written assembler code in src/hash/sha1_x86_32/sha1_x86_32_imp.S
> uses esp as a regular register.  Its content is safed at the beginning
> of the function and restored at the end.  If there is a trap due
> to a page boundary, the kernel stack guard kicks in and aborts the
> process.
> 
> Botan-1 is end of life.  Perhaps we should just replace the i386
> assembler implementation with the regular C code.

Someone over-optimized without considering the consequences.  Having
such instruction code on a unaligned-instruction architecture is just
too ripe for ROP gadget exploitation.  I hope that .S code dies.

Not going to delete the opportunistic ROP-pivot prevention mechanism

Re: botan i386 segfault [was Re: devel/monotone i386 breakage, maybe following libc++ update?]

[Alexander Bluhm]

On Thu, Jun 27, 2019 at 10:08:37PM +0100, Stuart Henderson wrote:
> #0  0x082eefff in botan_sha160_x86_32_compress () from 
> /usr/local/lib/libbotan-1.10.so.1.1

This code is at a page boundary, so it traps into the kernel.  There
it is detected that the esp register is currently not on the stack.

The hand written assembler code in src/hash/sha1_x86_32/sha1_x86_32_imp.S
uses esp as a regular register.  Its content is safed at the beginning
of the function and restored at the end.  If there is a trap due
to a page boundary, the kernel stack guard kicks in and aborts the
process.

Botan-1 is end of life.  Perhaps we should just replace the i386
assembler implementation with the regular C code.

bluhm

botan i386 segfault [was Re: devel/monotone i386 breakage, maybe following libc++ update?]

[Stuart Henderson]

On 2019/06/20 16:59, Stuart Henderson wrote:
> devel/monotone now fails to build on i386. During the build it runs
> its own-built "mtn" binary to produce manpages, which fails (segfaults),
> fails to produce the manpage file, so packaging fails, making the problem
> noticable.
> 
> It uses C++ and the failure started after the libc++ update. Seems
> repeatable.
> 

This appears to be a problem with botan, the segfault in the devel/monotone
build is in botan code:

$ egdb ./fake-i386/usr/local/bin/mtn 
GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-unknown-openbsd6.5".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./fake-i386/usr/local/bin/mtn...done.
(gdb) set args manpage
(gdb) r
Starting program: /usr/obj/ports/monotone-1.1/fake-i386/usr/local/bin/mtn 
manpage

Program received signal SIGSEGV, Segmentation fault.
0x082eefff in botan_sha160_x86_32_compress () from 
/usr/local/lib/libbotan-1.10.so.1.1
(gdb) bt
#0  0x082eefff in botan_sha160_x86_32_compress () from 
/usr/local/lib/libbotan-1.10.so.1.1
#1  0x in ?? ()


And I see the same stack trace in botan's own regression tests.

devel/monotone i386 breakage, maybe following libc++ update?

[Stuart Henderson]

devel/monotone now fails to build on i386. During the build it runs
its own-built "mtn" binary to produce manpages, which fails (segfaults),
fails to produce the manpage file, so packaging fails, making the problem
noticable.

It uses C++ and the failure started after the libc++ update. Seems
repeatable.

i386 breakage: lang/fsharp, devel/mono-addins

[Stuart Henderson]

mono-addins:

===>  Building for mono-addins-1.2
Making all in Mono.Addins
gmake[1]: Entering directory 
'/usr/obj/ports/mono-addins-1.2/mono-addins-mono-addins-1.2/Mono.Addins'
sed -e "s/@ASSEMBLY_NAME@/Mono.Addins/" -e "s/@POLICY@/0.2/" ../policy.config > 
policy.0.2.config
/usr/local/bin/al -link:policy.0.2.config -out:policy.0.2.Mono.Addins.dll 
-keyfile:../mono-addins.snk
ALINK: warning A9: Path 'policy.0.2.config' in the resource name is not 
supported. Using just file name 'policy.0.2.config'
sed -e "s/@ASSEMBLY_NAME@/Mono.Addins/" -e "s/@POLICY@/0.3/" ../policy.config > 
policy.0.3.config
/usr/local/bin/al -link:policy.0.3.config -out:policy.0.3.Mono.Addins.dll 
-keyfile:../mono-addins.snk
ALINK: warning A9: Path 'policy.0.3.config' in the resource name is not 
supported. Using just file name 'policy.0.3.config'
sed -e "s/@ASSEMBLY_NAME@/Mono.Addins/" -e "s/@POLICY@/0.4/" ../policy.config > 
policy.0.4.config
/usr/local/bin/al -link:policy.0.4.config -out:policy.0.4.Mono.Addins.dll 
-keyfile:../mono-addins.snk
ALINK: warning A9: Path 'policy.0.4.config' in the resource name is not 
supported. Using just file name 'policy.0.4.config'
sed -e "s/@ASSEMBLY_NAME@/Mono.Addins/" -e "s/@POLICY@/0.5/" ../policy.config > 
policy.0.5.config
/usr/local/bin/al -link:policy.0.5.config -out:policy.0.5.Mono.Addins.dll 
-keyfile:../mono-addins.snk
ALINK: warning A9: Path 'policy.0.5.config' in the resource name is not 
supported. Using just file name 'policy.0.5.config'
sed -e "s/@ASSEMBLY_NAME@/Mono.Addins/" -e "s/@POLICY@/0.6/" ../policy.config > 
policy.0.6.config
/usr/local/bin/al -link:policy.0.6.config -out:policy.0.6.Mono.Addins.dll 
-keyfile:../mono-addins.snk
ALINK: warning A9: Path 'policy.0.6.config' in the resource name is not 
supported. Using just file name 'policy.0.6.config'
Building Mono.Addins.csproj
Cannot transition thread 0x2fd8b9a0 from RUNNING with FINISH_ASYNC_SUSPEND
Cannot transition thread 0x7f1c2b28 from RUNNING with FINISH_ASYNC_SUSPEND
Cannot transition thread 0x88a0cd28 from RUNNING with FINISH_ASYNC_SUSPEND
Cannot transition thread 0x86083028 from RUNNING with FINISH_ASYNC_SUSPEND
Cannot transition thread 0x7f1c2428 from RUNNING with FINISH_ASYNC_SUSPEND
Abort trap (core dumped) 
gmake[1]: Leaving directory 
'/usr/obj/ports/mono-addins-1.2/mono-addins-mono-addins-1.2/Mono.Addins'
gmake[1]: *** [Makefile:558: csproj_build] Error 134
gmake: *** [Makefile:340: all-recursive] Error 1


===>  Building for fsharp-4.0.1.1
gmake -C src/fsharp all
gmake[1]: Entering directory 
'/usr/obj/ports/fsharp-4.0.1.1/fsharp-4.0.1.1/src/fsharp'
gmake build-proto
gmake[2]: Entering directory 
'/usr/obj/ports/fsharp-4.0.1.1/fsharp-4.0.1.1/src/fsharp'
cp -p 
/usr/obj/ports/fsharp-4.0.1.1/fsharp-4.0.1.1/lib/bootstrap/4.0/FSharp.Core.dll 
/usr/obj/ports/fsharp-4.0.1.1/fsharp-4.0.1.1//lib/proto/FSharp.Core.dll
cp -p 
/usr/obj/ports/fsharp-4.0.1.1/fsharp-4.0.1.1/lib/bootstrap/4.0/FSharp.Core.sigdata
 /usr/obj/ports/fsharp-4.0.1.1/fsharp-4.0.1.1//lib/proto/FSharp.Core.sigdata
cp -p 
/usr/obj/ports/fsharp-4.0.1.1/fsharp-4.0.1.1/lib/bootstrap/4.0/FSharp.Core.optdata
 /usr/obj/ports/fsharp-4.0.1.1/fsharp-4.0.1.1//lib/proto/FSharp.Core.optdata
gmake -C FSharp.Build-proto Configuration=proto build-proto
gmake[3]: Entering directory 
'/usr/obj/ports/fsharp-4.0.1.1/fsharp-4.0.1.1/src/fsharp/FSharp.Build-proto'
MONO_ENV_OPTIONS= /usr/local/bin/xbuild /p:Configuration=Proto
XBuild Engine Version 14.0
Mono, Version 4.6.1.0
Copyright (C) 2005-2013 Various Mono authors

Build started 11/02/2016 05:21:01.
__
Project 
"/usr/obj/ports/fsharp-4.0.1.1/fsharp-4.0.1.1/src/fsharp/FSharp.Build-proto/FSharp.Build-proto.fsproj"
 (default target(s)):
Target CallFsSrGen:
Created directory "obj/proto/./"
Tool 
/usr/obj/ports/fsharp-4.0.1.1/fsharp-4.0.1.1/src/fsharp/FSharp.Build-proto/../../../lib/bootstrap/4.0/fssrgen.exe
 execution started with arguments:  
/usr/obj/ports/fsharp-4.0.1.1/fsharp-4.0.1.1/src/fsharp/FSharp.Build/FSBuild.txt
  obj/proto/./FSBuild.fs  FSBuild.resx 
Target PrepareForBuild:
Configuration: Proto Platform: AnyCPU
Target GenerateResources:
Tool /usr/local/lib/mono/4.5/resgen.exe execution started with 
arguments: /useSourcePath /compile "FSBuild.resx,obj/proto/./FSBuild.resources" 
Target GenerateSatelliteAssemblies:
No input files were specified for target GenerateSatelliteAssemblies, 
skipping.
Target CoreCompile:
Tool 
/usr/obj/ports/fsharp-4.0.1.1/fsharp-4.0.1.1/lib/bootstrap/4.0/fsc.exe 
execution started with arguments: -o:obj/proto/./FSharp.Build-proto.dll -g 
--noframework --define:CROSS_PLATFORM_COMPILER --define:DEBUG 
--define:NO_STRONG_NAMES --define:NO_STRONG_NAMES --define:BUILDING_WITH_LKG 
--define:OPEN_BUILD --define:FSHARP_CORE_4_5 --define:FX_ATLEAST_40 
--define:FX_ATLEAST_35 --define:FX_ATLEAST_LINQ 

Re: NAnt progress (was: i386 breakage in last build)

[Ryan Boggs]

Hi,

Good news,  I was able to fix NAnt with an updated App.config file
from the projects master branch in github.com.  The problem was that
the old C# compilers that mono used to ship with (gmcs, dmcs, etc)
were removed in mono 3.0 replaced with 1 executable with target
argument.  The problem was resolved in one of the more recent commits
at github.

Bad news, it is now hanging during regression testing.  It stops at
the same place everytime.  I wanna work on this further before I
submit a formal diff update unless there are any objections.

I'll keep you posted.

Thanks,
Ryan

On Mon, Sep 15, 2014 at 5:21 PM, Ryan Boggs rmbo...@gmail.com wrote:
 Hi,

 On Sep 15, 2014 4:57 PM, Stuart Henderson st...@openbsd.org wrote:

 databases/hs-HDBC-mysql mysql-mariadb
 databases/mydumper  mysql-mariadb
 databases/mysqlcc   mysql-mariadb
 devel/hs-type-level long long time_t
 devel/hs-vector long long time_t
 devel/nant  IIRC this was broken since the mono update
 I'll look into NAnt this week.

 lang/obc(i386)  tclsh8.5: No such file or directory
 running camldep
 security/volatility (plist issue, already fixed)
 www/seamonkey,,-main(i386)  SSSE3


 Thanks,
 Ryan

i386 breakage in last build

[Stuart Henderson]

databases/hs-HDBC-mysql mysql-mariadb
databases/mydumper  mysql-mariadb
databases/mysqlcc   mysql-mariadb
devel/hs-type-level long long time_t
devel/hs-vector long long time_t
devel/nant  IIRC this was broken since the mono update
lang/obc(i386)  tclsh8.5: No such file or directory running 
camldep
security/volatility (plist issue, already fixed)
www/seamonkey,,-main(i386)  SSSE3

Re: i386 breakage in last build

[Ryan Boggs]

Hi,

On Sep 15, 2014 4:57 PM, Stuart Henderson st...@openbsd.org wrote:

 databases/hs-HDBC-mysql mysql-mariadb
 databases/mydumper  mysql-mariadb
 databases/mysqlcc   mysql-mariadb
 devel/hs-type-level long long time_t
 devel/hs-vector long long time_t
 devel/nant  IIRC this was broken since the mono update
I'll look into NAnt this week.

 lang/obc(i386)  tclsh8.5: No such file or directory
running camldep
 security/volatility (plist issue, already fixed)
 www/seamonkey,,-main(i386)  SSSE3


Thanks,
Ryan

Re: i386 breakage

[Andreas Vögele]

Hannah Schroeter wrote:


On Thu, Feb 16, 2006 at 11:50:41AM +0100, steven mestdagh wrote:

from a bulk build started Feb 13: 6 packages not building on i386:



clisp-2.33.2p0  Cannot map memory...


Issues with randomized mmap/malloc, [...] There were different
suggestions for workarounds, among them was the suggestion to use the
(IIRC (s)brk based) gmalloc which is included in the clisp tree
anyway.

I'm not sure though whether I'll have the time to actually try this 
out and submit patches in time for the release.


I've attached a simple patch that enables the included malloc.  CLISP 
can be built successfully with this patch and regression tests pass.
Index: Makefile
===
RCS file: /cvs/ports/lang/clisp/Makefile,v
retrieving revision 1.25
diff -u -r1.25 Makefile
--- Makefile16 Feb 2006 20:56:58 -  1.25
+++ Makefile18 Feb 2006 07:55:31 -
@@ -1,12 +1,11 @@
 # $OpenBSD: Makefile,v 1.25 2006/02/16 20:56:58 naddy Exp $
 
-BROKEN=does not handle randomized mmap()
 ONLY_FOR_ARCHS=i386
 
 COMMENT=   ANSI Common Lisp compiler
 
 DISTNAME=  clisp-2.33.2
-PKGNAME=   ${DISTNAME}p0
+PKGNAME=   ${DISTNAME}p1
 CATEGORIES=lang
 HOMEPAGE=  http://clisp.cons.org/
 
Index: patches/patch-src_configure
===
RCS file: /cvs/ports/lang/clisp/patches/patch-src_configure,v
retrieving revision 1.1
diff -u -r1.1 patch-src_configure
--- patches/patch-src_configure 11 Feb 2005 12:14:37 -  1.1
+++ patches/patch-src_configure 18 Feb 2006 07:55:31 -
@@ -1,6 +1,15 @@
 $OpenBSD: patch-src_configure,v 1.1 2005/02/11 12:14:37 alek Exp $
 src/configure.orig Thu Feb 10 00:43:19 2005
-+++ src/configure  Thu Feb 10 00:43:34 2005
+--- src/configure.orig Wed Jun  2 23:56:55 2004
 src/configure  Sat Feb 18 08:34:03 2006
+@@ -11437,7 +11437,7 @@ if test $cross_compiling = no; then
+ # Both are broken. When used with CLISP, the one in the default libc.a
+ # leads to a SIGSEGV, the one in libmalloc.a leads to a SIGBUS.
+ case $host_os in
+-  hpux*) cl_cv_func_malloc_broken=yes ;;
++  hpux*|openbsd*) cl_cv_func_malloc_broken=yes ;;
+   *) cl_cv_func_malloc_broken=no ;;
+ esac
+ else
 @@ -24255,7 +24255,7 @@ s,@host@,$host,;t t
  s,@host_cpu@,$host_cpu,;t t
  s,@host_vendor@,$host_vendor,;t t

Re: i386 breakage

[Moritz Grimm]

steven mestdagh wrote:

from a bulk build started Feb 13:
6 packages not building on i386:


[...]

qt4-4.1.0p0 tries to package nonexistent files


I suspect a hidden dependency here; I rebuilt it manually yesterday and 
it worked just fine for me (i386.) The filenames that don't exist for 
packaging might provide a clue about this dependency.



Moritz

Re: i386 breakage

[steven mestdagh]

On Thu, Feb 16, 2006 at 12:38:17PM +0100, Moritz Grimm wrote:
 steven mestdagh wrote:
 from a bulk build started Feb 13:
 6 packages not building on i386:
 
 [...]
 qt4-4.1.0p0 tries to package nonexistent files
 
 I suspect a hidden dependency here; I rebuilt it manually yesterday and 
 it worked just fine for me (i386.) The filenames that don't exist for 
 packaging might provide a clue about this dependency.

here they are

===  Building package for qt4-4.1.0p0
Error in package:
/usr/obj/ports/qt4-4.1.0/fake-i386//usr/local/lib/qt4/mkspecs
/openbsd-g++/qmake.conf does not exist
Error in package:
/usr/obj/ports/qt4-4.1.0/fake-i386//usr/local/lib/qt4/mkspecs
/openbsd-g++/qplatformdefs.h does not exist

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Re: i386 breakage

[Hannah Schroeter]

Hello!

On Thu, Feb 16, 2006 at 11:50:41AM +0100, steven mestdagh wrote:
from a bulk build started Feb 13:
6 packages not building on i386:

clisp-2.33.2p0  Cannot map memory...

Issues with randomized mmap/malloc, which clobbers all over the
address space (instead of more limited randomization), disallowing
clisp to map its memory image where it belongs, and the memory image
isn't relocatable (and if it were, it would lose sharing between
different clisp processes). There were different suggestions for
workarounds, among them was the suggestion to use the (IIRC (s)brk
based) gmalloc which is included in the clisp tree anyway.

I'm not sure though whether I'll have the time to actually try this
out and submit patches in time for the release.

gcc-3.3.6p1 No rule to make target `gnatlib_and_tools'
gmt-4.0 changed distfile
gprolog-1.2.16p0cannot open input file /tmp/...
maxima-5.9.0p1  clisp
qt4-4.1.0p0 tries to package nonexistent files

Any dependents on qt4 in the ports tree?

Kind regards,

Hannah.

Re: i386 breakage

[Thorsten Glaser]

Hannah Schroeter dixit:

There were different suggestions for
workarounds, among them was the suggestion to use the (IIRC (s)brk
based) gmalloc which is included in the clisp tree anyway.

Is that better than the old sbrk based BSD malloc?

//mirabile
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt

Re: i386 breakage

[steven mestdagh]

On Thu, Feb 16, 2006 at 11:50:41AM +0100, steven mestdagh wrote:
 from a bulk build started Feb 13:
 6 packages not building on i386:
 
 clisp-2.33.2p0  Cannot map memory...
 gcc-3.3.6p1 No rule to make target `gnatlib_and_tools'
 gmt-4.0 changed distfile
 gprolog-1.2.16p0cannot open input file /tmp/...
 maxima-5.9.0p1  clisp
 qt4-4.1.0p0 tries to package nonexistent files

clisp and gprolog have been marked broken, gmt fix is on the way.
naddy didn't see breakage on gcc and qt4 so something may have gone
wrong in my build.

steven

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Re: i386 breakage

[STeve Andre']

On Friday 17 February 2006 00:18, steven mestdagh wrote:
 On Thu, Feb 16, 2006 at 11:50:41AM +0100, steven mestdagh wrote:
  from a bulk build started Feb 13:
  6 packages not building on i386:
 
  clisp-2.33.2p0  Cannot map memory...
  gcc-3.3.6p1 No rule to make target `gnatlib_and_tools'
  gmt-4.0 changed distfile
  gprolog-1.2.16p0cannot open input file /tmp/...
  maxima-5.9.0p1  clisp
  qt4-4.1.0p0 tries to package nonexistent files

 clisp and gprolog have been marked broken, gmt fix is on the way.
 naddy didn't see breakage on gcc and qt4 so something may have gone
 wrong in my build.

 steven

My build of the ports tree had no problems with qt4-4.1.0p0.

--STeve Andre'

Re: i386 breakage

[bsd]

On 30 June 2005 at 20:34, [EMAIL PROTECTED] (Christian Weisgerber) wrote:

 sysutils/cfengine   SIOCADDRT

I'm working on this, hopefully done soon...

Re: i386 breakage

[Nuno Morgadinho]

From the latest i386 package build:

 lang/gprologmmap

I'll be looking into this next week or so..


-- nuno