Re: Why not use malloc S by default?

[Stefan Sperling]

On Tue, Nov 22, 2016 at 10:18:32PM +0100, Benjamin Baier wrote:
> On Tue, 22 Nov 2016 19:44:48 +0100
> "minek van"  wrote:
> 
> > So why isn't "S" enabled by default? It is the "most secure" solution for 
> > the
> > malloc settings, no? 
> > Or are there still programs that will crash when "S" is used? 
> > What are those? 
> 
> Adding new printer on the CUPS webinterface does not "like" this 
> malloc option. It doesn't crash, it just doesn't work.
> 
> Subtle breakage like this might occure when you "set and forget" this
> feature. I guess thats why it is labled "for security auditing".
> 
> Greetings Ben
> 

Yes the 'S' setting finds all sorts of problems in ports.

Last time I ran into one, gnome-shell crashed on startup and since gdm
uses gnome-shell there was no graphical login.

If you enable 'S' prepare for debugging complicated third party
software on your own.

Re: Why not use malloc S by default?

[Philippe Meunier]

Otto Moerbeek wrote:
>It is not a problem of crashing or not, S does incur a performance hit
>that we are not willing accept by default.

I've seen this claim several times on this mailing list over the past
few years but does anyone have actual data about it?  How much of a
performance hit is it in practice for, say, some typical tasks
(whatever "typical" means)?  I'm asking because I've been using S on
my 10 year old laptop for 2.5 years now and I don't remember seeing any
noticeable difference (or am I just very tolerant of low performance?)

Out of curiosity, here's the result of running "time /bin/sh
/etc/daily" three times in a row with /etc/malloc.conf -> S:

5m37.69s real 0m48.49s user 0m44.67s system
5m17.96s real 0m48.06s user 0m41.99s system
5m21.30s real 0m49.89s user 0m43.91s system

(the faster second and third results are probably due to caching effects)
and with no /etc/malloc.conf:

5m04.51s real 0m45.32s user 0m30.61s system
5m07.56s real 0m46.62s user 0m31.22s system
5m05.88s real 0m45.81s user 0m30.47s system

So it's a performance hit of about 15 seconds out of more than five
minutes, so about 5%.  Not great but not something that a human would
be likely to notice without actually timing it.  Granted, /etc/daily
might not be a perfect example because it seems to be mainly I/O bound
(and my computer is not really representative of today's machines
anyway), but I'd guess that a CPU bound program would probably
allocate memory up front and have a low hit in the long run, while a
memory intensive program (say, a language interpreter) would probably
have its own GC system making the speed of malloc not so much of a
problem.  Does anyone know of a relatively common program for which S
is a human-noticeable performance hit?

Cheers,

Philippe

Simple question on routing for IPSEC

[Bob Jones]

Hi,

Sorry for the dumb question but I'm suffering from config-writer's block !

OpenBSD6 if it makes any difference to the answers.

Let's say I've got the following in ipsec.conf on my local gateway :

"ike esp from 198.51.100.0/24 to any"

Given that "any" is a catch-all, how do I, for example specify to
route "203.0.113.0/24" via the ipsec gateway ?

e.g. something like the below (where 192.0.2.1 is the remote gateway)

doas route add -inet 203.0.113.0/24 192.0.2.1
add net 203.0.113.0/24: gateway 192.0.2.1: Network is unreachable

Bob

Re: Why not use malloc S by default?

[Otto Moerbeek]

On Wed, Nov 23, 2016 at 06:55:52AM -0500, Philippe Meunier wrote:

> Otto Moerbeek wrote:
> >It is not a problem of crashing or not, S does incur a performance hit
> >that we are not willing accept by default.
> 
> I've seen this claim several times on this mailing list over the past
> few years but does anyone have actual data about it?  How much of a
> performance hit is it in practice for, say, some typical tasks
> (whatever "typical" means)?  I'm asking because I've been using S on
> my 10 year old laptop for 2.5 years now and I don't remember seeing any
> noticeable difference (or am I just very tolerant of low performance?)
> 
> Out of curiosity, here's the result of running "time /bin/sh
> /etc/daily" three times in a row with /etc/malloc.conf -> S:
> 
> 5m37.69s real 0m48.49s user 0m44.67s system
> 5m17.96s real 0m48.06s user 0m41.99s system
> 5m21.30s real 0m49.89s user 0m43.91s system
> 
> (the faster second and third results are probably due to caching effects)
> and with no /etc/malloc.conf:
> 
> 5m04.51s real 0m45.32s user 0m30.61s system
> 5m07.56s real 0m46.62s user 0m31.22s system
> 5m05.88s real 0m45.81s user 0m30.47s system
> 
> So it's a performance hit of about 15 seconds out of more than five
> minutes, so about 5%.  Not great but not something that a human would
> be likely to notice without actually timing it.  Granted, /etc/daily
> might not be a perfect example because it seems to be mainly I/O bound
> (and my computer is not really representative of today's machines
> anyway), but I'd guess that a CPU bound program would probably
> allocate memory up front and have a low hit in the long run, while a
> memory intensive program (say, a language interpreter) would probably
> have its own GC system making the speed of malloc not so much of a
> problem.  Does anyone know of a relatively common program for which S
> is a human-noticeable performance hit?
> 
> Cheers,
> 
> Philippe

Your assumptions on on memoryb intensive applications doing smart
thing re memory is not true in general.

If you look at the actual user and system time in the daily runs,
you'll see that usertime + systemtime goes from about 77s to 90s.
About 16% more cycles are used when S is active.

I think that's enough evidence to see that S has a real performeace inpact.

Another test (I have C in /etc/malloc.conf so I need to switch it off
explicitly) is e.g. building. This we do a lot as developers. On a
fast machine with SSD this is CPU bound:

$ pwd
/usr/src/bin/ksh
$ MALLOC_OPTIONS=c time make
5.50 real 4.63 user 0.89 sys
$ make clean
$ MALLOC_OPTIONS=S time make
9.28 real 5.40 user 3.94 sys

Here the difference is even bigger (about 68%). I think that shows
enough why S isn't the default (apart from buggy third party
software).

-Otto

Re: Why not use malloc S by default?

[Philippe Meunier]

Otto Moerbeek wrote:
>Here the difference is even bigger (about 68%). I think that shows
>enough why S isn't the default (apart from buggy third party
>software).

Fair enough.

Cheers,

Philippe

Re: Why not use malloc S by default?

[Theo Buehler]

On Wed, Nov 23, 2016 at 06:55:52AM -0500, Philippe Meunier wrote:
> Otto Moerbeek wrote:
> >It is not a problem of crashing or not, S does incur a performance hit
> >that we are not willing accept by default.
> 
> I've seen this claim several times on this mailing list over the past
> few years but does anyone have actual data about it?  How much of a
> performance hit is it in practice for, say, some typical tasks
> (whatever "typical" means)?

[...]

> Does anyone know of a relatively common program for which S
> is a human-noticeable performance hit?

I now see that otto already gave the same example, but since I ran the
tests, here's some more numbers.

In my experience, build times are increased by something between 50% and
100% when I switch from CJ (what I usually run) to S.  Here's five
consecutive runs of 'make -j4' of GENERIC.MP on my otherwise mostly idle
T420 with 4 cores: Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz, 2691.64 MHz.

CJ  1m56.34s real 5m28.56s user 1m04.40s system
S   4m10.98s real 6m03.39s user 8m45.45s system

CJ  1m50.48s real 5m38.03s user 1m03.00s system
S   4m06.88s real 5m59.65s user 7m57.17s system

none1m41.22s real 5m16.35s user 1m02.65s system

Re: strange behaviour with route-to, default route, and ping -I

[Kenneth Gober]

On Mon, Nov 21, 2016 at 12:10 PM, Stefan Sperling  wrote:
> On Mon, Nov 21, 2016 at 10:43:17AM -0500, Kenneth Gober wrote:
>> I get the impression that route-to is applied when a packet enters the
>> router,
>> e.g. as part of a "pass in" rule, and that it is used to forcibly direct the
>> packet to a particular interface for "pass out" rather than relying on the
>> default routing table for the entry interface.
>>
>> This means that if the "pass out" rule is the first time you are seeing the
>> packet (i.e. because it originated from the router itself) then the routing
>> decision has already been made and it is now too late to route again.
>
> route-to takes effect when a state is created by a matched rule.
> It is possible to use route-to on 'pass out' rules (at least, over here,
> it works :)

Prompted by Stefan, I made some time to test this myself and I can
confirm that this works.

I started with this rule in pf.conf:

pass in log quick on em0 from em0:network to 8.8.8.8 route-to pppoe0
tagged TBD tag FORWARD

And "ping 8.8.8.8" from the internal network got redirected to pppoe0
(default route is em2)
but the same command issued at the router did not get redirected.  I
do not show the pass out
rule here but I have a later one that will pass out (with NAT)
anything tagged FORWARD.

Adding this rule as well:

pass out log quick on em2 to 8.8.8.8 route-to pppoe0

Caused "ping 8.8.8.8" originating from the router itself to be
redirected just like the
corresponding internal traffic.

-ken

Re: strange behaviour with route-to, default route, and ping -I

[Janne Johansson]

Isn't that because your pings aren't originating from em0:network?

Your rule need to apply in order to work, and the originating ip of the ping
will not be correct in the first place, and neither does the ping come in
on em0,
as you state in the rule.

"if incoming packets on em0 matches addresses em0:network and dest is
8.8.8.8.." and so on.


2016-11-23 15:04 GMT+01:00 Kenneth Gober :

> On Mon, Nov 21, 2016 at 12:10 PM, Stefan Sperling  wrote:
> > On Mon, Nov 21, 2016 at 10:43:17AM -0500, Kenneth Gober wrote:
> >> I get the impression that route-to is applied when a packet enters the
> >> router,
> >> e.g. as part of a "pass in" rule, and that it is used to forcibly
> direct the
> >> packet to a particular interface for "pass out" rather than relying on
> the
> >> default routing table for the entry interface.
> >>
> >> This means that if the "pass out" rule is the first time you are seeing
> the
> >> packet (i.e. because it originated from the router itself) then the
> routing
> >> decision has already been made and it is now too late to route again.
> >
> > route-to takes effect when a state is created by a matched rule.
> > It is possible to use route-to on 'pass out' rules (at least, over here,
> > it works :)
>
> Prompted by Stefan, I made some time to test this myself and I can
> confirm that this works.
>
> I started with this rule in pf.conf:
>
> pass in log quick on em0 from em0:network to 8.8.8.8 route-to pppoe0
> tagged TBD tag FORWARD
>
> And "ping 8.8.8.8" from the internal network got redirected to pppoe0
> (default route is em2)
> but the same command issued at the router did not get redirected.  I
> do not show the pass out
> rule here but I have a later one that will pass out (with NAT)
> anything tagged FORWARD.
>
> Adding this rule as well:
>
> pass out log quick on em2 to 8.8.8.8 route-to pppoe0
>
> Caused "ping 8.8.8.8" originating from the router itself to be
> redirected just like the
> corresponding internal traffic.
>
> -ken
>
>


-- 
May the most significant bit of your life be positive.

Re: Why not use malloc S by default?

[Stuart Henderson]

On 2016-11-23, Philippe Meunier  wrote:
>   Does anyone know of a relatively common program for which S
> is a human-noticeable performance hit?

vim with syntax highlighting. As a simple example just opening a file, the
visible effect is a small extra delay, and easy to time:

$ time (for i in `jot 10`; do vim '+:q!' 
/usr/ports/infrastructure/mk/bsd.port.mk; done)   
0m00.45s real 0m00.34s user 0m00.11s system

$ time (for i in `jot 10`; do MALLOC_OPTIONS=S vim '+:q!' 
/usr/ports/infrastructure/mk/bsd.port.mk; done) 
0m01.27s real 0m00.40s user 0m00.85s system

For interactive use, deleting lines in such a file (causing it to re-highlight
as it goes) becomes very painful.

[FOSDEM] [CFP] FOSDEM 2017 - Distributions Devroom - Extended

[Brian Exelbierd]

FOSDEM 2017 - Distributions Devroom Call for Participation (new
deadline)

The Distributions devroom will take place 4 February, 2017 at FOSDEM, in
room K.4.601 at Université Libre de Bruxelles, in Brussels, Belgium.

Distributions are more than just hosted collections of software from
various
upstreams. Each distribution is responsible for problem-solving in
building,
testing, and releasing software as well as managing the lifecycle of
each
application in the collection. Additionally, distributions do very
important
work in ensuring that various versions of upstream software work well
together
and can co-exist. Distribution are also, often responsible, for
"de-vendoring"
upstream software so that security fixes can be applied more quickly.

We welcome submissions targeted at contributors interested in issues
unique to
distributions, especially in the following topics:

- Managing Build/Test/Release processes around shared ideas and
resources

- Lifecycle management, especially in the areas of sandboxing,
  containerization, vendoring, and bundling

- Distribution construction tools and infrastructure development and
  implementation (building, signing, testing, distribution, etc.)

- Cross-distribution collaboration on common issues, eg: content
distribution,
  infrastructure, and documentation

- Working with vendors and including them in the community

- Building trust and code relationships with the upstream components of
a
  distribution and between distributions

- The future of distributions, emerging trends and evolving user demands
from
  the idea of a platform

- The place of distributions in today's world (including concepts of
  containerization, IoT, etc.)

- Onboarding new users and mentorship, facilitating technical growth
within the
  contributor base

- Solving traditional problems like package management, and content
management
  (eg. rpm/dpkg/ostree/coreos )

- Integration technologies like installers, deployment facilitation (
eg. cloud
  contextualisation )

- Principals of Rolling Releases, Long Term Supported Releases (LTS),
Feature
  gated releases, and calendar releases

Ideal submissions are actionable and opinionated. Submissions may be in
the
form of 25 or 50 minute talks, panel sessions, round-table discussions,
or
Birds of a Feather (BoF) sessions.

Due to popular demand, We are extending the CFP for the Distributions
Devroom until Friday 02-December-2016. We plan to maintain the rest of
the schedule (e.g. notification dates) as-is. We look forward to your
submissions.

Revised Dates
--
Submission Deadline: 02-Dec-2016
Acceptance Notification: 5-Dec-2016
Final Schedule Posted: 11-Dec-2016

How to submit
--
Visit https://penta.fosdem.org/submission/FOSDEM17

1.) If you do not have an account, create one here
2.) Click 'Create Event'
3.) Enter your presentation details
4.) Be sure to select the Distributions Devroom track!
5.) Submit

What to include
---
- The title of your submission
- A 1-paragraph Abstract
- A longer description including the benefit of your talk to your target
  audience, including a definition of your target audience.
- Approximate length / type of submission (talk, BoF, ...)
- Links to related websites/blogs/talk material (if any)

Administrative Notes

We will be live-streaming and recording the Distributions Devroom.
Presenting
at FOSDEM implies permission to record your session and distribute the
recording afterwards. All videos will be made available under the
standard
FOSDEM content license (CC-BY).

If you have any questions, feel free to contact the devroom organizers:
distributions-devr...@lists.fosdem.org
(https://lists.fosdem.org/listinfo/distributions-devroom)

Cheers!

Brian Exelbierd (twitter: @bexelbie) and Brian Stinson (twitter:
@bstinsonmhk)
for and on behalf of The Distributions Devroom Program Committee

VMM with Hapertown?

[alexmcwhirter]

I have some systems with Hapertown CPUS that support VT-x, but not EPT. 
Does vmm currently require EPT to work?

unknown hostname on ssh tunnel end causes 'administratively prohibited: open failed'

[Jiri B]

I was using ssh socks5 tunnel (-D) today and I saw many:

  channel 4: open failed: administratively prohibited: open failed

messages. It seems non-resolvable hostnames on my gw (ie. end of ssh
socks5 tunnel) is passed to client as "prohibited" event.

This seems odd and confusing. GW is an older 6.0-current amd64.

j.

Firefox with SOCKS5 tunnel (ssh -D $gw). Than I opened an url,
ie. wiki.brq.example.com:

~~~
debug1: Connection to port  forwarding to socks port 0 requested.
debug2: fd 11 setting TCP_NODELAY
debug3: fd 11 is O_NONBLOCK
debug3: fd 11 is O_NONBLOCK
debug1: channel 4: new [dynamic-tcpip]
debug2: channel 4: pre_dynamic: have 0
debug2: channel 4: pre_dynamic: have 3
debug2: channel 4: decode socks5
debug2: channel 4: socks5 auth done
debug2: channel 4: pre_dynamic: need more
debug2: channel 4: pre_dynamic: have 0
debug2: channel 4: pre_dynamic: have 26
debug2: channel 4: decode socks5
debug2: channel 4: socks5 post auth
debug2: channel 4: dynamic request: socks5 host wiki.brq.example.com port 80 
command 1
debug3: send packet: type 90
debug3: receive packet: type 92
channel 4: open failed: administratively prohibited: open failed
   ^
debug2: channel 4: zombie
debug2: channel 4: garbage collecting
debug1: channel 4: free: direct-tcpip: listening port  for 
wiki.brq.example.com port 80, connect from 127.0.0.1 port 30421 to 127.0.0.1 
port , nchannels 5
debug3: channel 4: status: The following connections are open:
  #2 client-session (t4 r0 i0/0 o0/0 fd 7/8 cc -1)
  #3 direct-tcpip: listening port  for www.google.com port 443, connect 
from 127.0.0.1 port 24731 to 127.0.0.1 port  (t4 r1 i0/0 o0/0 fd 10/10 cc 
-1)
~~~

part of auth.log:

~~~
Nov 23 19:24:04 gw sshd[20891]: error: connect_to wiki.brq.example.com: unknown 
host (no address associated with name)


~~~

my sshd_config part:

~~~
Match Address 
192.168.1.0/24,192.168.2.0/24,192.168.254.0/24,2xx.0.0.0/8,2001:470:::/64 
User jirib
  PasswordAuthentication no
  AuthenticationMethods publickey
  AuthorizedKeysFile /etc/ssh/authorized_keys.d/%u
  AllowTcpForwarding yes
  PermitTunnel yes
  AllowAgentForwarding yes
  GatewayPorts yes
  X11Forwarding yes
~~~

Re: VMM with Hapertown?

[Mike Larkin]

On Wed, Nov 23, 2016 at 01:03:07PM -0500, alexmcwhir...@triadic.us wrote:
> I have some systems with Hapertown CPUS that support VT-x, but not EPT. Does
> vmm currently require EPT to work?
>

for the time being, yes. 

Making sense of ktrace

[Jeff Ross]

Hi all,

I've got a program that seg faults on OpenBSD 6.0 AMD64 release that 
runs fine on 5.9 i386.


I'm checking to see if will also run on 5.9 AMD64 right now but it 
doesn't appear to be w^x related.  To be sure I've mounted that 
partition with wxallowed.


Here are the last few lines from kdump--would sure appreciate it if 
someone could shed some light on what's happening.


 47868 fastforward CALL 
mmap(0,0x1000,0x3,0x1002,-1,0)

 47868 fastforward RET   mmap 9049032314880/0x83ae45b5000
 47868 fastforward CALL 
mmap(0,0x1000,0x3,0x1002,-1,0)

 47868 fastforward RET   mmap 9049215606784/0x83aef482000
 47868 fastforward CALL 
mmap(0,0xa000,0x3,0x1002,-1,0)

 47868 fastforward RET   mmap 9047796883456/0x83a9ab82000
 47868 fastforward CALL  mprotect(0x83b09fd2000,0x1000,0x1)
 47868 fastforward RET   mprotect 0
 47868 fastforward CALL  munmap(0x83a9ab82000,0xa000)
 47868 fastforward RET   munmap 0
 47868 fastforward CALL  mprotect(0x83870f07000,0x1000,0x1)
 47868 fastforward RET   mprotect 0
 47868 fastforward CALL  getthrid()
 47868 fastforward RET   getthrid 1047868/0xffd3c
 47868 fastforward CALL  __set_tcb(0x83b14ce3600)
 47868 fastforward RET   __set_tcb 0
 47868 fastforward CALL 
mmap(0,0x1000,0x3,0x1002,-1,0)

 47868 fastforward RET   mmap 9049102131200/0x83ae884a000
 47868 fastforward CALL  mprotect(0x83ae884a000,0x1000,0x1)
 47868 fastforward RET   mprotect 0
 47868 fastforward CALL 
mprotect(0x83ae884a000,0x1000,0x3)

 47868 fastforward RET   mprotect 0
 47868 fastforward CALL  mprotect(0x83ae884a000,0x1000,0x1)
 47868 fastforward RET   mprotect 0
 47868 fastforward CALL  sigaction(SIGPIPE,0x7f7cdec0,0)
 47868 fastforward STRU  struct sigaction { handler=SIG_IGN, mask=0<>, 
flags=0<> }

 47868 fastforward RET   sigaction 0
 47868 fastforward PSIG  SIGSEGV SIG_DFL code SEGV_MAPERR<1> 
addr=0x71008620 trapno=6

 47868 fastforward NAMI  "fastforward.core"

I've re-compiled this also with what I found on the internet to make a 
core file that gdb can use but that's even more of a mystery to me than 
ktrace.  Is there a better debugger that I can use?


Thanks,

Jeff Ross

Re: umb(4) connection issues

[Ingo Feinerer]

On Tue, Nov 22, 2016 at 12:06:30PM -0800, Bryan Vyhmeister wrote:
> On Tue, Nov 22, 2016 at 06:14:28PM +0100, Ingo Feinerer wrote:
> > --8<-
> > umb0: flags=8851 mtu 1500
> > index 5 priority 0 llprio 3
> > roaming disabled registration home network
> > state up cell-class custom rssi -69dBm speed 5.5Mps up 20.0Mps down
> > SIM initialized PIN valid
> > subscriber-id 012345678901234 ICC-id 0123456789012345689 provider 3 
> > AT
> > device KRD 131 30/123 - R1A IMEI 012345689012345 firmware R3C11 
> > (Pro), R4A10 (App)
> > APN drei.at
> > dns 213.94.78.17 213.94.78.16
> > status: active
> > inet 10.72.61.158 --> 10.72.61.155 netmask 0xfff8
> > --8<-
> 
> Due to some conflicts with umb(4) and MP safe work going on, a default
> route is not automatically created for a umb(4) connection. You have to
> do it manually like the following for your example above:
> 
> route add -ifp umb0 default 10.72.61.155
> 
> I created a shell script to set this up.

Thanks for the pointer.

Indeed, it works for me when an appropriate (default) route is manually
added and the listed DNS entries are manually set in /etc/resolv.conf.

Best regards,
Ingo

Re: Making sense of ktrace

[Otto Moerbeek]

On Wed, Nov 23, 2016 at 12:37:12PM -0700, Jeff Ross wrote:

> Hi all,
> 
> I've got a program that seg faults on OpenBSD 6.0 AMD64 release that runs
> fine on 5.9 i386.
> 
> I'm checking to see if will also run on 5.9 AMD64 right now but it doesn't
> appear to be w^x related.  To be sure I've mounted that partition with
> wxallowed.
> 
> Here are the last few lines from kdump--would sure appreciate it if someone
> could shed some light on what's happening.
> 
>  47868 fastforward CALL
> mmap(0,0x1000,0x3,0x1002,-1,0)
>  47868 fastforward RET   mmap 9049032314880/0x83ae45b5000
>  47868 fastforward CALL
> mmap(0,0x1000,0x3,0x1002,-1,0)
>  47868 fastforward RET   mmap 9049215606784/0x83aef482000
>  47868 fastforward CALL
> mmap(0,0xa000,0x3,0x1002,-1,0)
>  47868 fastforward RET   mmap 9047796883456/0x83a9ab82000
>  47868 fastforward CALL  mprotect(0x83b09fd2000,0x1000,0x1)
>  47868 fastforward RET   mprotect 0
>  47868 fastforward CALL  munmap(0x83a9ab82000,0xa000)
>  47868 fastforward RET   munmap 0
>  47868 fastforward CALL  mprotect(0x83870f07000,0x1000,0x1)
>  47868 fastforward RET   mprotect 0
>  47868 fastforward CALL  getthrid()
>  47868 fastforward RET   getthrid 1047868/0xffd3c
>  47868 fastforward CALL  __set_tcb(0x83b14ce3600)
>  47868 fastforward RET   __set_tcb 0
>  47868 fastforward CALL
> mmap(0,0x1000,0x3,0x1002,-1,0)
>  47868 fastforward RET   mmap 9049102131200/0x83ae884a000
>  47868 fastforward CALL  mprotect(0x83ae884a000,0x1000,0x1)
>  47868 fastforward RET   mprotect 0
>  47868 fastforward CALL
> mprotect(0x83ae884a000,0x1000,0x3)
>  47868 fastforward RET   mprotect 0
>  47868 fastforward CALL  mprotect(0x83ae884a000,0x1000,0x1)
>  47868 fastforward RET   mprotect 0
>  47868 fastforward CALL  sigaction(SIGPIPE,0x7f7cdec0,0)
>  47868 fastforward STRU  struct sigaction { handler=SIG_IGN, mask=0<>,
> flags=0<> }
>  47868 fastforward RET   sigaction 0
>  47868 fastforward PSIG  SIGSEGV SIG_DFL code SEGV_MAPERR<1> addr=0x71008620
> trapno=6
>  47868 fastforward NAMI  "fastforward.core"

The program is aborted by a SIGSEGV. Thta means it is accessing a
memory location that is not  allocated by the program.

> 
> I've re-compiled this also with what I found on the internet to make a core
> file that gdb can use but that's even more of a mystery to me than ktrace.
> Is there a better debugger that I can use?
> 
> Thanks,
> 
> Jeff Ross

$ gdb fastforward fastforward.core
then type the command bt, should give you some clue, if the stack isn't
damaged too much.

-Otto

Re: Making sense of ktrace

[Jeff Ross]

On 11/23/16 1:16 PM, Otto Moerbeek wrote:

On Wed, Nov 23, 2016 at 12:37:12PM -0700, Jeff Ross wrote:


Hi all,

I've got a program that seg faults on OpenBSD 6.0 AMD64 release that runs
fine on 5.9 i386.

I'm checking to see if will also run on 5.9 AMD64 right now but it doesn't
appear to be w^x related.  To be sure I've mounted that partition with
wxallowed.

Here are the last few lines from kdump--would sure appreciate it if someone
could shed some light on what's happening.

 47868 fastforward CALL
mmap(0,0x1000,0x3,0x1002,-1,0)
 47868 fastforward RET   mmap 9049032314880/0x83ae45b5000
 47868 fastforward CALL
mmap(0,0x1000,0x3,0x1002,-1,0)
 47868 fastforward RET   mmap 9049215606784/0x83aef482000
 47868 fastforward CALL
mmap(0,0xa000,0x3,0x1002,-1,0)
 47868 fastforward RET   mmap 9047796883456/0x83a9ab82000
 47868 fastforward CALL  mprotect(0x83b09fd2000,0x1000,0x1)
 47868 fastforward RET   mprotect 0
 47868 fastforward CALL  munmap(0x83a9ab82000,0xa000)
 47868 fastforward RET   munmap 0
 47868 fastforward CALL  mprotect(0x83870f07000,0x1000,0x1)
 47868 fastforward RET   mprotect 0
 47868 fastforward CALL  getthrid()
 47868 fastforward RET   getthrid 1047868/0xffd3c
 47868 fastforward CALL  __set_tcb(0x83b14ce3600)
 47868 fastforward RET   __set_tcb 0
 47868 fastforward CALL
mmap(0,0x1000,0x3,0x1002,-1,0)
 47868 fastforward RET   mmap 9049102131200/0x83ae884a000
 47868 fastforward CALL  mprotect(0x83ae884a000,0x1000,0x1)
 47868 fastforward RET   mprotect 0
 47868 fastforward CALL
mprotect(0x83ae884a000,0x1000,0x3)
 47868 fastforward RET   mprotect 0
 47868 fastforward CALL  mprotect(0x83ae884a000,0x1000,0x1)
 47868 fastforward RET   mprotect 0
 47868 fastforward CALL  sigaction(SIGPIPE,0x7f7cdec0,0)
 47868 fastforward STRU  struct sigaction { handler=SIG_IGN, mask=0<>,
flags=0<> }
 47868 fastforward RET   sigaction 0
 47868 fastforward PSIG  SIGSEGV SIG_DFL code SEGV_MAPERR<1> addr=0x71008620
trapno=6
 47868 fastforward NAMI  "fastforward.core"


The program is aborted by a SIGSEGV. Thta means it is accessing a
memory location that is not  allocated by the program.



I've re-compiled this also with what I found on the internet to make a core
file that gdb can use but that's even more of a mystery to me than ktrace.
Is there a better debugger that I can use?

Thanks,

Jeff Ross


$ gdb fastforward fastforward.core
then type the command bt, should give you some clue, if the stack isn't
damaged too much.

-Otto


Thank you, Otto!

The stack may indeed be too damaged--I get the following but it doesn't 
look very helpful:


jross@luna:/package/mail/sqmail/sqmail-3.2.13 $ sudo gdb 
/var/qmail/bin/fastforward fastforward.core

GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.

Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd6.0"...(no debugging 
symbols found)


Core was generated by `fastforward'.
Program terminated with signal 11, Segmentation fault.
(no debugging symbols found)
Loaded symbols for /var/qmail/bin/fastforward
Reading symbols from /usr/lib/libc.so.88.0...done.
Loaded symbols for /usr/lib/libc.so.88.0
Reading symbols from /usr/libexec/ld.so...done.
Loaded symbols for /usr/libexec/ld.so
#0  0x0115d4803035 in ?? () from /var/qmail/bin/fastforward
(gdb) bt
#0  0x0115d4803035 in ?? () from /var/qmail/bin/fastforward
#1  0x0115d4802545 in ?? () from /var/qmail/bin/fastforward
#2  0x0115d48015f2 in ?? () from /var/qmail/bin/fastforward
#3  0x in ?? ()
(gdb)

I built fastforward with

cc -g -O0  -include /usr/include/errno.h -pipe

is there a better incantation?

Thanks again!
Jeff

Re: umb(4) connection issues

[Bryan Vyhmeister]

On Wed, Nov 23, 2016 at 08:37:04PM +0100, Ingo Feinerer wrote:
> Indeed, it works for me when an appropriate (default) route is manually
> added and the listed DNS entries are manually set in /etc/resolv.conf.

I forgot to mention about DNS. The script I came up with just grabs the
values from the ifconfig output and adds the default route and then puts
the DNS entries in place.

Bryan

Re: Making sense of ktrace

[Andy Bradford]

Thus said Jeff Ross on Wed, 23 Nov 2016 15:42:08 -0700:

> The  stack may  indeed  be too  damaged--I get  the  following but  it
> doesn't look very helpful:

More likely the symbols were stripped.

Assuming this was installed from sources,  edit conf-cc and add -g, then
edit conf-ld and remove the -s:

$ head -1 conf-cc
cc -O2 -g
$ head -1 conf-ld
cc
$ 

Then recompile  and try  again (e.g.  get a  new core  file and  run gdb
again).

Andy
-- 
TAI64 timestamp: 4000583654c6

Re: Making sense of ktrace

[Jeremie Courreges-Anglas]

"Andy Bradford"  writes:

> Thus said Jeff Ross on Wed, 23 Nov 2016 15:42:08 -0700:
>
>> The  stack may  indeed  be too  damaged--I get  the  following but  it
>> doesn't look very helpful:
>
> More likely the symbols were stripped.
>
> Assuming this was installed from sources,  edit conf-cc and add -g, then
> edit conf-ld and remove the -s:
>
> $ head -1 conf-cc
> cc -O2 -g
> $ head -1 conf-ld
> cc

Better add -g here too.

> $ 
>
> Then recompile  and try  again (e.g.  get a  new core  file and  run gdb
> again).
>
> Andy

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: unknown hostname on ssh tunnel end causes 'administratively prohibited: open failed'

[Darren Tucker]

On Wed, Nov 23, 2016 at 01:35:17PM -0500, Jiri B wrote:
> I was using ssh socks5 tunnel (-D) today and I saw many:
> 
>   channel 4: open failed: administratively prohibited: open failed
> 
> messages. It seems non-resolvable hostnames on my gw (ie. end of ssh
> socks5 tunnel) is passed to client as "prohibited" event.
> 
> This seems odd and confusing. GW is an older 6.0-current amd64.

The code in sshd where the response is composed doesn't know what the
reason for the failure is.  I suspect thid dates back to the original
Protocol 1 code becuase Protocol 1 didn't (I think) have a reason field.
This passes the reason back up the stack and sends it to the client.

Index: channels.c
===
RCS file: /cvs/src/usr.bin/ssh/channels.c,v
retrieving revision 1.356
diff -u -p -r1.356 channels.c
--- channels.c  18 Oct 2016 17:32:54 -  1.356
+++ channels.c  24 Nov 2016 04:36:58 -
@@ -3038,7 +3038,7 @@ channel_input_port_open(int type, u_int3
}
packet_check_eom();
c = channel_connect_to_port(host, host_port,
-   "connected socket", originator_string);
+   "connected socket", originator_string, NULL, NULL);
free(originator_string);
free(host);
if (c == NULL) {
@@ -3995,7 +3995,8 @@ channel_connect_ctx_free(struct channel_
 
 /* Return CONNECTING channel to remote host:port or local socket path */
 static Channel *
-connect_to(const char *name, int port, char *ctype, char *rname)
+connect_to(const char *name, int port, char *ctype, char *rname, int *reason,
+char **errmsg)
 {
struct addrinfo hints;
int gaierr;
@@ -4036,7 +4037,12 @@ connect_to(const char *name, int port, c
hints.ai_family = IPv4or6;
hints.ai_socktype = SOCK_STREAM;
snprintf(strport, sizeof strport, "%d", port);
-   if ((gaierr = getaddrinfo(name, strport, &hints, &cctx.aitop)) 
!= 0) {
+   if ((gaierr = getaddrinfo(name, strport, &hints, &cctx.aitop))
+   != 0) {
+   if (errmsg != NULL)
+   *errmsg = ssh_gai_strerror(gaierr);
+   if (reason != NULL)
+   *reason = SSH2_OPEN_CONNECT_FAILED;
error("connect_to %.100s: unknown host (%s)", name,
ssh_gai_strerror(gaierr));
return NULL;
@@ -4076,7 +4082,8 @@ channel_connect_by_listen_address(const 
return permitted_opens[i].downstream;
return connect_to(
permitted_opens[i].host_to_connect,
-   permitted_opens[i].port_to_connect, ctype, rname);
+   permitted_opens[i].port_to_connect, ctype, rname,
+   NULL, NULL);
}
}
error("WARNING: Server requests forwarding for unknown listen_port %d",
@@ -4093,7 +4100,8 @@ channel_connect_by_listen_path(const cha
if (open_listen_match_streamlocal(&permitted_opens[i], path)) {
return connect_to(
permitted_opens[i].host_to_connect,
-   permitted_opens[i].port_to_connect, ctype, rname);
+   permitted_opens[i].port_to_connect, ctype, rname,
+   NULL, NULL);
}
}
error("WARNING: Server requests forwarding for unknown path %.100s",
@@ -4103,7 +4111,8 @@ channel_connect_by_listen_path(const cha
 
 /* Check if connecting to that port is permitted and connect. */
 Channel *
-channel_connect_to_port(const char *host, u_short port, char *ctype, char 
*rname)
+channel_connect_to_port(const char *host, u_short port, char *ctype,
+char *rname, int *reason, char **errmsg)
 {
int i, permit, permit_adm = 1;
 
@@ -4128,9 +4137,10 @@ channel_connect_to_port(const char *host
if (!permit || !permit_adm) {
logit("Received request to connect to host %.100s port %d, "
"but the request was denied.", host, port);
+   *reason = SSH2_OPEN_ADMINISTRATIVELY_PROHIBITED;
return NULL;
}
-   return connect_to(host, port, ctype, rname);
+   return connect_to(host, port, ctype, rname, reason, errmsg);
 }
 
 /* Check if connecting to that path is permitted and connect. */
@@ -4162,7 +4172,7 @@ channel_connect_to_path(const char *path
"but the request was denied.", path);
return NULL;
}
-   return connect_to(path, PORT_STREAMLOCAL, ctype, rname);
+   return connect_to(path, PORT_STREAMLOCAL, ctype, rname, NULL, NULL);
 }
 
 void
Index: channels.h
===
RCS file: /cvs/src/usr.bin/ssh/channels.h,v
retrieving revision 1.120
diff -u -p -r1

relayd with multiple pools

[mxb]

Hello list,
following relayd setup exists in prod:

relay int_health_check {
listen on 127.0.0.1 port 78
protocol http_relay
forward to  port 80 mode roundrobin check http "/" code 200
forward to  port 80 mode roundrobin check  http "/" code
503
forward to  port 80 mode roundrobin check http "/" code 301
forward to  port 9800 mode roundrobin check http "/" code
503
}

table  { 192.168.10.31 parent 1, 192.168.10.32 parent 2, \
192.168.10.33 parent 3, 192.168.10.34 parent 4, \
192.168.10.35 parent 5, 192.168.10.36 parent 6 \
}

table  { 10.2.128.34 parent 9, 10.2.128.35 parent 10, \
10.2.128.36 parent 11, 10.2.128.37 parent 12, \
10.2.128.38 parent 13, 10.2.128.39 parent 14 \
}

table  { 192.168.10.83 parent 7, 192.168.10.84 parent 8 }

The dance above, if unclear, is done to eliminate number of health checks per
relay and copy the
state of machines into each relay using those pools. We have several relays.
Below is one of those.

relay se_m_tls {
listen on $VIP22 port 443 tls
listen on $VIP23 port 443 tls
protocol tls_accel
forward to  port 80 mode roundrobin check http "/" code
200
forward to  port 80 mode roundrobin check tcp
forward to  port 80 mode roundrobin check tcp
}

The idea here is obvious, is to fall through until client reaches
.

With relay above, status is following:
m_vm_pool is enabled
m_hw_pool is disabled
fallback_copy is enabled

We decided to test fallback_copy and thus I disabled m_vm_pool as well.
Expected result is that all traffic
should end up in fallback_copy and display very simple index.html. Actual
result is that relay continued to operate
as usual, eg. serving PHP generated content.
This test was done from a different location so no prev. states existed in
PF.
Eg. disable first, then surf.

Is this expected behavior ?

I also noted, that if I disable parent table, eg for example , hosts
within the pool never get status UNKNOWN and thus
appear UP in all child tables ().
My understanding is that if table is disabled, relayd will stop checking hosts
within table
and those eventually should switch status to UNKNOWN. As well as the rest on
child tables using this parent table.
As in the test above, disabling child table should override status of hosts
within the table and those should become UNKNOW,
which should prevent usage of this child table.


Any clarification regarding this scenario is appreciated.

P.S.
This is 6.0-stable

Br
//mxb