Re: some more info about ?? hangs

2019-04-27 Thread Jonathan Gray
On Sat, Apr 27, 2019 at 04:55:50PM +0300, Gregory Edigarov wrote:
> attached please find  dmesg and backtrace of X when that happen again
> hope this bug report will be more useful than previous one.
> 
> thank you.
> --
> With best regards,
>   Gregory Edigarov

Likely fixed by

xenocara/xserver/hw/xfree86/common/xf86VGAarbiterPriv.h


revision 1.9
date: 2019/04/28 03:12:53;  author: jsg;  state: Exp;  lines: +13 -7;  
commitid: gMqza1DBk6OCnvP4;
Backport cf7517675d988c2d1ff967d6d162a17acbdad46 from xserver 1.20
xfree86: Hold input_lock across SPRITE functions in VGA arbiter

Fixes stack overflow crash with VGA arbiter used with multi GPU systems.
Report and fix identified by 'Joe M' on misc@. ok matthieu@




Re: Patch for X crash on 6.4 and 6.5

2019-04-27 Thread Jonathan Gray
On Fri, Apr 26, 2019 at 11:57:14AM -0700, Joe M wrote:
> Hello,
> 
> I had this same issue with 6.4 and 6.5. Applying this patch has fixed
> the issue. I am using 2 radeon gpu's.
> 
> https://patchwork.freedesktop.org/series/28284/

Thanks for the report and tracking this down.  I've committed this patch
to xenocara in -current.

> 
> This is the gdb backtrace of the crashed core file.
> 
> joe:10201$ d gdb /usr/X11R6/bin/X Xorg.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.5"...
> Core was generated by `Xorg'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /usr/lib/libpthread.so.26.1...done.
> Loaded symbols for /usr/lib/libpthread.so.26.1
> Loaded symbols for /usr/X11R6/bin/X
> Symbols already loaded for /usr/lib/libpthread.so.26.1
> Reading symbols from /usr/X11R6/lib/libpciaccess.so.2.0...done.
> Loaded symbols for /usr/X11R6/lib/libpciaccess.so.2.0
> Reading symbols from /usr/X11R6/lib/libdrm.so.7.6...done.
> Loaded symbols for /usr/X11R6/lib/libdrm.so.7.6
> Reading symbols from /usr/X11R6/lib/libpixman-1.so.36.0...done.
> Loaded symbols for /usr/X11R6/lib/libpixman-1.so.36.0
> Reading symbols from /usr/X11R6/lib/libXfont2.so.1.0...done.
> Loaded symbols for /usr/X11R6/lib/libXfont2.so.1.0
> Reading symbols from /usr/X11R6/lib/libfontenc.so.4.0...done.
> Loaded symbols for /usr/X11R6/lib/libfontenc.so.4.0
> Reading symbols from /usr/X11R6/lib/libfreetype.so.29.0...done.
> Loaded symbols for /usr/X11R6/lib/libfreetype.so.29.0
> Reading symbols from /usr/lib/libz.so.5.0...done.
> Loaded symbols for /usr/lib/libz.so.5.0
> Reading symbols from /usr/X11R6/lib/libXau.so.10.0...done.
> Loaded symbols for /usr/X11R6/lib/libXau.so.10.0
> Reading symbols from /usr/X11R6/lib/libxshmfence.so.0.0...done.
> Loaded symbols for /usr/X11R6/lib/libxshmfence.so.0.0
> Reading symbols from /usr/X11R6/lib/libXdmcp.so.11.0...done.
> Loaded symbols for /usr/X11R6/lib/libXdmcp.so.11.0
> Reading symbols from /usr/lib/libkvm.so.17.0...done.
> Loaded symbols for /usr/lib/libkvm.so.17.0
> Reading symbols from /usr/lib/libm.so.10.1...done.
> Loaded symbols for /usr/lib/libm.so.10.1
> Reading symbols from /usr/lib/libc.so.95.0...done.
> Loaded symbols for /usr/lib/libc.so.95.0
> Reading symbols from /usr/libexec/ld.so...done.
> Loaded symbols for /usr/libexec/ld.so
> Reading symbols from /usr/X11R6/lib/modules/extensions/libglx.so...done.
> Loaded symbols for /usr/X11R6/lib/modules/extensions/libglx.so
> Reading symbols from /usr/X11R6/lib/libGL.so.17.1...done.
> Loaded symbols for /usr/X11R6/lib/libGL.so.17.1
> Reading symbols from /usr/lib/libexpat.so.12.0...done.
> Loaded symbols for /usr/lib/libexpat.so.12.0
> Reading symbols from /usr/X11R6/lib/libxcb-dri3.so.0.1...done.
> Loaded symbols for /usr/X11R6/lib/libxcb-dri3.so.0.1
> Reading symbols from /usr/X11R6/lib/libxcb-xfixes.so.1.2...done.
> Loaded symbols for /usr/X11R6/lib/libxcb-xfixes.so.1.2
> Reading symbols from /usr/X11R6/lib/libxcb-present.so.0.1...done.
> Loaded symbols for /usr/X11R6/lib/libxcb-present.so.0.1
> Reading symbols from /usr/X11R6/lib/libxcb-sync.so.1.2...done.
> Loaded symbols for /usr/X11R6/lib/libxcb-sync.so.1.2
> Reading symbols from /usr/X11R6/lib/libglapi.so.0.2...done.
> Loaded symbols for /usr/X11R6/lib/libglapi.so.0.2
> Reading symbols from /usr/X11R6/lib/libXdamage.so.4.0...done.
> Loaded symbols for /usr/X11R6/lib/libXdamage.so.4.0
> Reading symbols from /usr/X11R6/lib/libXfixes.so.6.0...done.
> Loaded symbols for /usr/X11R6/lib/libXfixes.so.6.0
> Reading symbols from /usr/X11R6/lib/libX11-xcb.so.2.0...done.
> Loaded symbols for /usr/X11R6/lib/libX11-xcb.so.2.0
> Reading symbols from /usr/X11R6/lib/libxcb-glx.so.1.1...done.
> Loaded symbols for /usr/X11R6/lib/libxcb-glx.so.1.1
> Reading symbols from /usr/X11R6/lib/libxcb-dri2.so.1.1...done.
> Loaded symbols for /usr/X11R6/lib/libxcb-dri2.so.1.1
> Reading symbols from /usr/X11R6/lib/libXxf86vm.so.6.0...done.
> Loaded symbols for /usr/X11R6/lib/libXxf86vm.so.6.0
> Reading symbols from /usr/X11R6/lib/libXext.so.13.0...done.
> Loaded symbols for /usr/X11R6/lib/libXext.so.13.0
> Reading symbols from /usr/X11R6/lib/libX11.so.16.1...done.
> Loaded symbols for /usr/X11R6/lib/libX11.so.16.1
> Reading symbols from /usr/X11R6/lib/libxcb.so.4.0...done.
> Loaded symbols for /usr/X11R6/lib/libxcb.so.4.0
> Reading symbols from /usr/X11R6/lib/modules/drivers/radeon_drv.so...done.
> Loaded symbols for /usr/X11R6/lib/modules/drivers/radeon_drv.so
> Reading symbols from /usr/X11R6/lib/libdrm_radeon.so.4.0...done.
> Loaded symbols for /usr/X11R6/lib/libdrm_radeon.so.4.0
> Reading symbols from /usr/X11R6/lib/libgbm.so.0.3...done.
> 

Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread Igor Podlesny
On Sun, 28 Apr 2019 at 02:43, Thomas Frohwein  wrote:
>
> On Sun, Apr 28, 2019 at 02:07:44AM +0700, Igor Podlesny wrote:
> [...]
> > Looks like decision made aren't subjects of discussing(?) Well, why
> > the hell you have those mail lists then(?) :)
>
> Igor:
> The actual purpose of misc@ is for us to learn that you are among the people 
> to
> ignore.

You don't understand what "to ignore" mean then. Or fail to do what
you say. Or learn too slow. ;-)

-- 
End of message. Next message?



Re: [website] Incorrect release date on the front page

2019-04-27 Thread Mihai Popescu
> I see that nothing has changed since the 70s, same moronic attitude towards 
> people confused > by Unix shit.

I guess the attitude from people asking is the same like '70. Just
asking, I came in this world a few years late.

> the release has a bug / funny morons

A few dozen people taking care of a release, doing it and one outsider
comes to tell them they may have a bug in that. Now, that was funny!



Re: [website] Incorrect release date on the front page

2019-04-27 Thread chohag
Anonymous writes:
> Some pointless bullshit or other

Turns out time's not as simple a concept as your average developer assumed.

Apparently you're going to have to learn some things. It could be a first!

Welcome to the real world.

Good luck.

Matthew



Re: [website] Incorrect release date on the front page

2019-04-27 Thread Anonymous
Theo de Raadt:
> cho...@jtan.com wrote:
> 
>> Anonymous writes:
>>> Otto Moerbeek:
 On Sat, Apr 27, 2019 at 03:13:00PM +, Anonymous wrote:

> Here too: https://www.openbsd.org/65.html

 Does it matter? It is very common for publications to be dated in the
 future. 

-Otto
>>>
>>> No, it's not common, neither for software releases nor for texts
>>> published online (blogposts, fiction, etc). Maybe you're talking about
>>> some niche. And yes, it matters because it's confusing: I opened the
>>> front page soon after the release but was in doubt whether it's for real
>>> because of the date.
>>
>> Well I'm not an author, editor, publisher or printer but I'm fairly sure
>> nobody's ever gone from "I'm going to write a book" to "this book has been
>> printed and is already on the shelves" in less than 24 hours, so
>> publishing "in advance" like this makes total sense.
>>
>> A bit weird but luckily I'm not a complete fucking moron so I'm able to
>> work out that when something says "released* on [future date]" that time
>> travel was not invented while I wasn't looking and that a week here or
>> there just doesn't matter.
>>
>> People pointing out spelling mistakes have more utility than this thread.
> 
> Looking closer, the release directory contains root.mail which is dated
> May 1.  That file is also contained in the base set for each
> architecture, which is hashed and signed.  Sometimes tar'd, hashed, and
> signed.  There are also many binaries and files throughout the release
> which aren't date May 1.  It is a pretty unkempt state of affairs.
> 
> Obviously to repair some of these issues, we should change the date in
> that file (and some other files also) and re-roll all the release
> builds.  Starting now.  Which will take some time.  Sadly, those
> repaired files will miss May 1, which is sure to elicit new complaints.
> 
> Ironic isn't it?  Just-in-time is difficult in the real world.
> 
> I suggest the OP learns to let it go.  Or visiting a clinic for some
> therapy, in most countries this is government subsidized.
> 
> The observant among you will have noticed that most errata+syspatch go
> out a day early also.  We've got a good justification for that though --
> we are pandering to folk on the early side of the dateline.  You can
> conclude the 6.5 release was made available on-time, as we are pandering
> to people on the early side of the weekline.  I'll probably pander to
> someone else for the 6.6 release.
> 
> I'm late, I'm late! For a very important date! No time to say `hello,
> goodbye,' I'm late, I'm late, I'm late!
The reason for concern is that if the date is wrong then the
infrastructure used to roll out the release has a bug which can have
whatever consequences so rushing to download is unwise. But yes, I see
that nothing has changed since the 70s, same moronic attitude towards
people confused by Unix shit. At least you are funny morons, I give you
that:)



Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread Consus
On 12:43 Sat 27 Apr, Thomas Frohwein wrote:
> Move along, nothing to see here.

I want to see more butthurting Theo!



Re: [website] Incorrect release date on the front page

2019-04-27 Thread Theo de Raadt
cho...@jtan.com wrote:

> Anonymous writes:
> > Otto Moerbeek:
> > > On Sat, Apr 27, 2019 at 03:13:00PM +, Anonymous wrote:
> > > 
> > >> Here too: https://www.openbsd.org/65.html
> > > 
> > > Does it matter? It is very common for publications to be dated in the
> > > future. 
> > > 
> > >   -Otto
> >
> > No, it's not common, neither for software releases nor for texts
> > published online (blogposts, fiction, etc). Maybe you're talking about
> > some niche. And yes, it matters because it's confusing: I opened the
> > front page soon after the release but was in doubt whether it's for real
> > because of the date.
> 
> Well I'm not an author, editor, publisher or printer but I'm fairly sure
> nobody's ever gone from "I'm going to write a book" to "this book has been
> printed and is already on the shelves" in less than 24 hours, so
> publishing "in advance" like this makes total sense.
> 
> A bit weird but luckily I'm not a complete fucking moron so I'm able to
> work out that when something says "released* on [future date]" that time
> travel was not invented while I wasn't looking and that a week here or
> there just doesn't matter.
> 
> People pointing out spelling mistakes have more utility than this thread.

Looking closer, the release directory contains root.mail which is dated
May 1.  That file is also contained in the base set for each
architecture, which is hashed and signed.  Sometimes tar'd, hashed, and
signed.  There are also many binaries and files throughout the release
which aren't date May 1.  It is a pretty unkempt state of affairs.

Obviously to repair some of these issues, we should change the date in
that file (and some other files also) and re-roll all the release
builds.  Starting now.  Which will take some time.  Sadly, those
repaired files will miss May 1, which is sure to elicit new complaints.

Ironic isn't it?  Just-in-time is difficult in the real world.

I suggest the OP learns to let it go.  Or visiting a clinic for some
therapy, in most countries this is government subsidized.

The observant among you will have noticed that most errata+syspatch go
out a day early also.  We've got a good justification for that though --
we are pandering to folk on the early side of the dateline.  You can
conclude the 6.5 release was made available on-time, as we are pandering
to people on the early side of the weekline.  I'll probably pander to
someone else for the 6.6 release.

I'm late, I'm late! For a very important date! No time to say `hello,
goodbye,' I'm late, I'm late, I'm late!



Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread chohag
Otto Moerbeek writes:
>
> The mechanism is in the docs as well, not only in the code. You

You are of course correct, and OpenBSD has some of the best documentation
I've ever seen, but I've spent so long in linux land that whenever I'm
met with the question of how *exactly* something works, I just go straight
to the source. Source code can't lie (trusting trust notwithstanding).

> ignored my post about the symlink being confusing and error prone
> since the time it is read (before or after the chroot) is program
> dependent. It might even depend on options gives to a program when the
> first malloc call happens, making it even more unclear which symlink
> is being used.  Add the complexity with respect to unveil and pledge
> and it is clear why we replaced it. 

And I'm grateful. Having options - and such low-level options at
that! - encoded in such a weird way has always felt extremely
unopenbsd-like. This is another step toward sanity.

Simplicity! Thank you, devs.

Matthew



Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread Thomas Frohwein
On Sun, Apr 28, 2019 at 02:07:44AM +0700, Igor Podlesny wrote:
[...]
> Looks like decision made aren't subjects of discussing(?) Well, why
> the hell you have those mail lists then(?) :)

Igor:
The actual purpose of misc@ is for us to learn that you are among the people to
ignore.

Everyone else:
Move along, nothing to see here.



Re: [website] Incorrect release date on the front page

2019-04-27 Thread chohag
Anonymous writes:
> Otto Moerbeek:
> > On Sat, Apr 27, 2019 at 03:13:00PM +, Anonymous wrote:
> > 
> >> Here too: https://www.openbsd.org/65.html
> > 
> > Does it matter? It is very common for publications to be dated in the
> > future. 
> > 
> > -Otto
>
> No, it's not common, neither for software releases nor for texts
> published online (blogposts, fiction, etc). Maybe you're talking about
> some niche. And yes, it matters because it's confusing: I opened the
> front page soon after the release but was in doubt whether it's for real
> because of the date.

Well I'm not an author, editor, publisher or printer but I'm fairly sure
nobody's ever gone from "I'm going to write a book" to "this book has been
printed and is already on the shelves" in less than 24 hours, so
publishing "in advance" like this makes total sense.

A bit weird but luckily I'm not a complete fucking moron so I'm able to
work out that when something says "released* on [future date]" that time
travel was not invented while I wasn't looking and that a week here or
there just doesn't matter.

People pointing out spelling mistakes have more utility than this thread.

Sheesh,

Matthew

[*] past tense



Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread chohag
Igor Podlesny writes:
> On Sun, 28 Apr 2019 at 00:59,  wrote:
> [...]
> > >
> > > Oh, those hypocrite wankers here and there..
> >
> > If you actually read the code (I know, right? Who DOES that?) you'll see 
> > how omalloc_
> init perfectly embarrasses you. In 6.4 it would read the symlink, then 
> checked the envi
> ronment, and then consider the global variable malloc_options. In 6.5 it is 
> ... exactly
>  the same except that now sysctl is used instead of readlink (and hooray for 
> sanity).
> >
> > At no time was any attempt ever made by libc to force a programme to use 
> > only the set
> tings from sysctl née malloc.conf. If you had been using the environment 
> variable from 
> the beginning you would have been in _exactly_ the same position all that 
> time as you a
> re now. The security you think you've been relying on and have now lost was 
> never there
> . You have been protecting yourself with security theatre.
> >
> > Matthew
>
> Matthew, LOL, what?
> Read the code?
> You didn't even read the whole comment thread where I did explain that
> I was mostly concerned with cleared up environment other than changed
> options of that variable.

No, I did. I dismissed your arguments because they come from someone
who plainly has no idea what "the environment" even is.

malloc.c is quite lucid. Your continuing to spout off having clearly not
even glanced at it is a sorry state of affairs. But this is unix. We'll
continue to hand you as much rope as you like.

> Actually, I'd say that preparing chroots with malloc.conf as a symlink
> is more straightforward, more enforcing and easier to verify other
> than putting that as an environment option that would actually have to
> be read before target is running.

How in the ... Stay the hell away from my servers.

> And (of course) given with symlink
> it can't be so easily vanished when the whole environment is cleared
> up by user space.

/etc/malloc.conf can disappear exactly as easily as /etc/profile and
/etc/login.conf. More easily, in fact, if a tool to "handle" broken
symlinks gets involved.

> All-in-all, I didn't rely on this anyways.
> My question was purely theoretical and reaction was practically clumsy. :)

No, the reaction was dismissive of your complete lack of research and
understanding. Why should the developers or us other list members take
the time to read and understand the code you can't be arsed to?

In order to find out exactly how malloc handles its various
configuration sources took approximately 5 minutes of browsing on
cvsweb.openbsd.org to find the appropriate function and I don't even
know C that well. Your unwillingness to do even that is why you're being
treated with such derision.

> Looks like decision made aren't subjects of discussing(?) Well, why
> the hell you have those mail lists then(?) :)

Building something as large as OpenBSD simply cannot be done without
discussion so this is either a poor quality attempt at derision or
some sort of delusion. In fact I imagine that intellient discussion is
restricted to places where the general public are not permitted so that
it remain intelligent - for which I am most grateful. It's quite clear
why you've not been invited.

tl;dr: You don't understand and your ranting is just turning you into a
spectacle. Please do continue; I have popcorn.

Matthew



Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread Otto Moerbeek
On Sun, Apr 28, 2019 at 02:07:44AM +0700, Igor Podlesny wrote:

> On Sun, 28 Apr 2019 at 00:59,  wrote:
> [...]
> > >
> > > Oh, those hypocrite wankers here and there..
> >
> > If you actually read the code (I know, right? Who DOES that?) you'll see 
> > how omalloc_init perfectly embarrasses you. In 6.4 it would read the 
> > symlink, then checked the environment, and then consider the global 
> > variable malloc_options. In 6.5 it is ... exactly the same except that now 
> > sysctl is used instead of readlink (and hooray for sanity).
> >
> > At no time was any attempt ever made by libc to force a programme to use 
> > only the settings from sysctl née malloc.conf. If you had been using the 
> > environment variable from the beginning you would have been in _exactly_ 
> > the same position all that time as you are now. The security you think 
> > you've been relying on and have now lost was never there. You have been 
> > protecting yourself with security theatre.
> >
> > Matthew
> 
> Matthew, LOL, what?
> Read the code?
> You didn't even read the whole comment thread where I did explain that
> I was mostly concerned with cleared up environment other than changed
> options of that variable.
> 
> Actually, I'd say that preparing chroots with malloc.conf as a symlink
> is more straightforward, more enforcing and easier to verify other
> than putting that as an environment option that would actually have to
> be read before target is running. And (of course) given with symlink
> it can't be so easily vanished when the whole environment is cleared
> up by user space.
> 
> All-in-all, I didn't rely on this anyways.
> My question was purely theoretical and reaction was practically clumsy. :)
> Looks like decision made aren't subjects of discussing(?) Well, why
> the hell you have those mail lists then(?) :)
> For users to come and thank you and say you did all the best possible
> way only? :)
> To never question any decision? Seriously? No, really? C'mon, you
> gotta be kidding.
> 
> -- 
> End of message. Next message?
> 

The mechanism is in the docs as well, not only in the code. You
ignored my post about the symlink being confusing and error prone
since the time it is read (before or after the chroot) is program
dependent. It might even depend on options gives to a program when the
first malloc call happens, making it even more unclear which symlink
is being used.  Add the complexity with respect to unveil and pledge
and it is clear why we replaced it. 

-Otto






Re: [website] Incorrect release date on the front page

2019-04-27 Thread Anonymous
Otto Moerbeek:
> On Sat, Apr 27, 2019 at 03:13:00PM +, Anonymous wrote:
> 
>> Here too: https://www.openbsd.org/65.html
> 
> Does it matter? It is very common for publications to be dated in the
> future. 
> 
>   -Otto

No, it's not common, neither for software releases nor for texts
published online (blogposts, fiction, etc). Maybe you're talking about
some niche. And yes, it matters because it's confusing: I opened the
front page soon after the release but was in doubt whether it's for real
because of the date.



Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread Igor Podlesny
On Sun, 28 Apr 2019 at 00:59,  wrote:
[...]
> >
> > Oh, those hypocrite wankers here and there..
>
> If you actually read the code (I know, right? Who DOES that?) you'll see how 
> omalloc_init perfectly embarrasses you. In 6.4 it would read the symlink, 
> then checked the environment, and then consider the global variable 
> malloc_options. In 6.5 it is ... exactly the same except that now sysctl is 
> used instead of readlink (and hooray for sanity).
>
> At no time was any attempt ever made by libc to force a programme to use only 
> the settings from sysctl née malloc.conf. If you had been using the 
> environment variable from the beginning you would have been in _exactly_ the 
> same position all that time as you are now. The security you think you've 
> been relying on and have now lost was never there. You have been protecting 
> yourself with security theatre.
>
> Matthew

Matthew, LOL, what?
Read the code?
You didn't even read the whole comment thread where I did explain that
I was mostly concerned with cleared up environment other than changed
options of that variable.

Actually, I'd say that preparing chroots with malloc.conf as a symlink
is more straightforward, more enforcing and easier to verify other
than putting that as an environment option that would actually have to
be read before target is running. And (of course) given with symlink
it can't be so easily vanished when the whole environment is cleared
up by user space.

All-in-all, I didn't rely on this anyways.
My question was purely theoretical and reaction was practically clumsy. :)
Looks like decision made aren't subjects of discussing(?) Well, why
the hell you have those mail lists then(?) :)
For users to come and thank you and say you did all the best possible
way only? :)
To never question any decision? Seriously? No, really? C'mon, you
gotta be kidding.

-- 
End of message. Next message?



Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread chohag
Igor Podlesny writes:
> On Sat, 27 Apr 2019 at 18:09, Marc Espie  wrote:
> >
> > On Sat, Apr 27, 2019 at 12:34:01PM +0700, Igor Podlesny wrote:
> > > On Sat, 27 Apr 2019 at 12:26, Sebastien Marie  wrote:
> > > > On Sat, Apr 27, 2019 at 12:17:21PM +0700, Igor Podlesny wrote:
> > > > > Previously users could have different behaviour of malloc 
> > > > > simultaneously: one i
> n
> > > > > global FS, others in chroots. Say, in global it could be more relaxed
> > > [...]
> > > > malloc(3) man page mentions several ways to set malloc options:
> > > >
> > > > - globally with vm.malloc_conf sysctl(2)
> > > > - externally per apps with environment variable MALLOC_OPTIONS
> > > > - internally per apps with global variable malloc_options in the program
> > > >
> > > > So I suppose you want to look at exported MALLOC_OPTIONS environment
> > > > variable.
> > >
> > > Wrong. Environment is easy to be changed by any non-privileged process.
> > > OTOH, root owned /etc/malloc.conf is not.
> >
> > Man, you have some really strange delusions about how to harden things.
>
> %  man malloc.conf | grep -i security
>  S   Enable all options suitable for security auditing.
>
> Oh, those hypocrite wankers here and there..

If you actually read the code (I know, right? Who DOES that?) you'll see how 
omalloc_init perfectly embarrasses you. In 6.4 it would read the symlink, then 
checked the environment, and then consider the global variable malloc_options. 
In 6.5 it is ... exactly the same except that now sysctl is used instead of 
readlink (and hooray for sanity).

At no time was any attempt ever made by libc to force a programme to use only 
the settings from sysctl née malloc.conf. If you had been using the environment 
variable from the beginning you would have been in _exactly_ the same position 
all that time as you are now. The security you think you've been relying on and 
have now lost was never there. You have been protecting yourself with security 
theatre.

Matthew



some more info about Х hangs

2019-04-27 Thread Gregory Edigarov
attached please find  dmesg and backtrace of X when that happen again
hope this bug report will be more useful than previous one.

thank you.
--
With best regards,
  Gregory Edigarov


dmesg
Description: Binary data


x.backtrace
Description: Binary data


Re: [website] Incorrect release date on the front page

2019-04-27 Thread Otto Moerbeek
On Sat, Apr 27, 2019 at 03:13:00PM +, Anonymous wrote:

> Here too: https://www.openbsd.org/65.html

Does it matter? It is very common for publications to be dated in the
future. 

-Otto



[website] Incorrect release date on the front page

2019-04-27 Thread Anonymous
Here too: https://www.openbsd.org/65.html



Re: headphone volume levels cannot be manipulated by mixerctl

2019-04-27 Thread joshua stein
On Sat, 27 Apr 2019 at 14:20:32 -, Christian Weisgerber wrote:
> However, as in this example, I think you will only get a few generic
> controls.
> 
> It is my theoretical understanding that USB audio gadgets typically
> come with a uhid(4) device, as does yours above, and you would use
> usbhidctl(1) to list and manipulate the available controls.
> 
> In practice, I only get some variant of
> 
> usbhidctl: USB_GET_REPORT (probably not supported by device): Input/output 
> error
> 
> when I try this.  So either I'm mistaken or there is a problem
> somewhere.

Some devices just don't supply hardware volume controls, so it must 
be done in software on the sending device.

With sndiod, you can use aucatctl to change the software volume 
per-application (or the master volume).

It's all kind of complicated though.  If you plug in a new USB audio 
device like this, you have to restart sndiod and pass in a new 
device name, then use aucatctl to adjust the volume.  But if you 
unplug the USB device, you have to restart sndiod again to use the 
default audio device and use mixerctl instead.



Re: headphone volume levels cannot be manipulated by mixerctl

2019-04-27 Thread Christian Weisgerber
On 2019-04-27, Levente  wrote:

> The headphone in question is the Platronics RIG 500 HD, which connects 
> through the USB port (instead of 3.5mm jacks).

> mixerctl output is provided below along with dmesg.

Your headphones, which are really a USB audio adapter with attached
headphones, are a separate audio device.  Here are the relevant
parts from your dmesg:

> audio0 at azalia0
> ppb0 at pci0 dev 28 function 0 "Intel 6 Series PCIE" rev 0xb4: msi
> pci1 at ppb0 bus 2

That's the built-in azalia(4) audio of the laptop that supplies the
speakers and the headphone jack.

> uaudio0 at uhub3 port 2 configuration 1 interface 1 "Plantronics Plantronics 
> HD1" rev 2.00/1.14 addr 3
> uaudio0: class v1, full-speed, sync, channels: 2 play, 2 rec, 9 ctls
> audio1 at uaudio0
> uhidev0 at uhub3 port 2 configuration 1 interface 3 "Plantronics Plantronics 
> HD1" rev 2.00/1.14 addr 3
> uhidev0: iclass 3/0, 1 report id
> uhid0 at uhidev0 reportid 1: input=15, output=15, feature=0

And these are your uaudio(4) headphones.

By default, mixerctl accesses /dev/mixer -> /dev/mixer0, which is
the built-in audio.  You can access the mixer associated with your
USB headphones by choosing the appropriate device:

$ mixerctl -f /dev/mixer1 
outputs.play=0,0
outputs.play_loud=on
outputs.play_mute=off
record.enable=sysctl

However, as in this example, I think you will only get a few generic
controls.

It is my theoretical understanding that USB audio gadgets typically
come with a uhid(4) device, as does yours above, and you would use
usbhidctl(1) to list and manipulate the available controls.

In practice, I only get some variant of

usbhidctl: USB_GET_REPORT (probably not supported by device): Input/output error

when I try this.  So either I'm mistaken or there is a problem
somewhere.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de



Re: Is there any supported watchdog hardware straight out of the box?

2019-04-27 Thread Igor Podlesny
On Sat, 27 Apr 2019 at 17:55, Stuart Henderson  wrote:
[...]
> It is not true. They don't have *wide* support but there is some
> supported hw. If someone wants to change this, I suggest adding acpi
> watchdog support would give the best return for time spent.

Got it.

> Also I don't see what this has to do with watchdogs

Well, it's just due to:
> >> Recompiling would be needed.

> you would normally
> not want to wait until userland starts and LKMs are loaded before arming
> the watchdog.

Well, in theory it couldn't be more correct. In practice though hangs
aren't happening that
often so a module won't have time to load and start. At least if it
would be that bad
I won't rely on watchdogs at all.

Thank you nonetheless. :)

-- 
End of message. Next message?



Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread Igor Podlesny
On Sat, 27 Apr 2019 at 20:38, Vincent Legoll  wrote:
>
> On Sat, Apr 27, 2019 at 3:32 PM Igor Podlesny  wrote:
> > On Sat, 27 Apr 2019 at 18:09, Marc Espie  wrote:
> > > Man, you have some really strange delusions about how to harden things.
> >
> > %  man malloc.conf | grep -i security
> >  S   Enable all options suitable for security auditing.
> >
> > Oh, those hypocrite wankers here and there..
>
> Looks like auditing and hardening are not exactly the same thing.

And I didn't say "hardening". That's a delusion courtesy of Marc Espie
"the wako". ;-)

Although I can say "harder auditing" if you like. ;-)

-- 
End of message. Next message?



Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread Vincent Legoll
On Sat, Apr 27, 2019 at 3:32 PM Igor Podlesny  wrote:
> On Sat, 27 Apr 2019 at 18:09, Marc Espie  wrote:
> > Man, you have some really strange delusions about how to harden things.
>
> %  man malloc.conf | grep -i security
>  S   Enable all options suitable for security auditing.
>
> Oh, those hypocrite wankers here and there..

Looks like auditing and hardening are not exactly the same thing.

-- 
Vincent Legoll



Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread Igor Podlesny
On Sat, 27 Apr 2019 at 18:09, Marc Espie  wrote:
>
> On Sat, Apr 27, 2019 at 12:34:01PM +0700, Igor Podlesny wrote:
> > On Sat, 27 Apr 2019 at 12:26, Sebastien Marie  wrote:
> > > On Sat, Apr 27, 2019 at 12:17:21PM +0700, Igor Podlesny wrote:
> > > > Previously users could have different behaviour of malloc 
> > > > simultaneously: one in
> > > > global FS, others in chroots. Say, in global it could be more relaxed
> > [...]
> > > malloc(3) man page mentions several ways to set malloc options:
> > >
> > > - globally with vm.malloc_conf sysctl(2)
> > > - externally per apps with environment variable MALLOC_OPTIONS
> > > - internally per apps with global variable malloc_options in the program
> > >
> > > So I suppose you want to look at exported MALLOC_OPTIONS environment
> > > variable.
> >
> > Wrong. Environment is easy to be changed by any non-privileged process.
> > OTOH, root owned /etc/malloc.conf is not.
>
> Man, you have some really strange delusions about how to harden things.

%  man malloc.conf | grep -i security
 S   Enable all options suitable for security auditing.

Oh, those hypocrite wankers here and there..

-- 
End of message. Next message?



Re: One-shot upgrade script

2019-04-27 Thread Christian Weisgerber
On 2019-04-27, Kevin Chadwick  wrote:

> How difficult would it be to have a sysupgrade flag to

What sysupgrade and the unattended upgrade do is they automate an
upgrade with ALL DEFAULT settings.  Like only pressing enter in the
installer's (U)pgrade mode.

If you want non-defaults, then you need to run a manual upgrade.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de



support new

2019-04-27 Thread Rolf

0
C Belgium
P Oost-Vlaanderen
T Dendermonde
Z 9200
O MetaData
I Rolf
A Oliestraat 50
M sa...@metadata.be
U https://metadata.be/
B +32 477 29 76 04
X N/A
N Network consulting, installation and maintenance. Hosting services.



Re: One-shot upgrade script

2019-04-27 Thread Otto Moerbeek
On Sat, Apr 27, 2019 at 01:48:38PM +0100, Kevin Chadwick wrote:

> On 4/25/19 9:27 PM, Christian Weisgerber wrote:
> > ... and this has now been supplanted by /usr/sbin/sysupgrade.
> 
> How difficult would it be to have a sysupgrade flag to make the upgrade newfs
> /usr, to save having to rm the files shown in upgrade.html. (I guess it should
> work for all users with sane partition setups, but is quite a dangerous/severe
> action?)
> 
> Just wondering if it is easy or problematic to accomplish.
> 

Way too dangerous. If a file really needs to go, the upgrade script
will take care. But only for files that would cause harm.

-Otto



Re: One-shot upgrade script

2019-04-27 Thread Kevin Chadwick
On 4/25/19 9:27 PM, Christian Weisgerber wrote:
> ... and this has now been supplanted by /usr/sbin/sysupgrade.

How difficult would it be to have a sysupgrade flag to make the upgrade newfs
/usr, to save having to rm the files shown in upgrade.html. (I guess it should
work for all users with sane partition setups, but is quite a dangerous/severe
action?)

Just wondering if it is easy or problematic to accomplish.



Re: headphone volume levels cannot be manipulated by mixerctl

2019-04-27 Thread Marc Espie
If you want to be read, configure your email to send normal messages.

All I see is "Signed data", and I'm not necessarily going to open attachments
to see what you're saying on a public mailing-list.



Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread Marc Espie
On Sat, Apr 27, 2019 at 12:34:01PM +0700, Igor Podlesny wrote:
> On Sat, 27 Apr 2019 at 12:26, Sebastien Marie  wrote:
> > On Sat, Apr 27, 2019 at 12:17:21PM +0700, Igor Podlesny wrote:
> > > Previously users could have different behaviour of malloc simultaneously: 
> > > one in
> > > global FS, others in chroots. Say, in global it could be more relaxed
> [...]
> > malloc(3) man page mentions several ways to set malloc options:
> >
> > - globally with vm.malloc_conf sysctl(2)
> > - externally per apps with environment variable MALLOC_OPTIONS
> > - internally per apps with global variable malloc_options in the program
> >
> > So I suppose you want to look at exported MALLOC_OPTIONS environment
> > variable.
> 
> Wrong. Environment is easy to be changed by any non-privileged process.
> OTOH, root owned /etc/malloc.conf is not.

Man, you have some really strange delusions about how to harden things.

I would suggest you go to another operating system. There are lots of wackos
out there with similar mixes of paranoia and wishful thinking.



Re: No more KDE's dolphin after upgrade to 6.5

2019-04-27 Thread Stuart Henderson
On 2019-04-26, Luke A. Call  wrote:
> On 04-26 21:47, Rafael Sadowski wrote:
>> []
>> update all packages with the following PKG_PATH example:
>> 
>> env PKG_PATH=https://ftp.openbsd.org/pub/OpenBSD/6.5/packages/ pkg_add -u -v 
>> -Dinstalled
>> 
>> It looks like you mixed packages for 6.4 and 6.5 and/or -current.
>
> I had to run a pkg_add command equivalent to that, to get mutt and sox play
> to run.  This happened when I upgraded to 6.4 as well, with libreoffice,
> that not everything required was updated somehow, with just pkg_add -u.

You shouldn't have to do that. Proper bug report including output from pkg_add
next time, please..




Re: No more KDE's dolphin after upgrade to 6.5

2019-04-27 Thread Stuart Henderson
On 2019-04-26, Federico Giannici  wrote:
>
> casa:/home/giannici> konsole
> ld.so: konsole: can't load library 'libc++.so.1.0'
> Killed

Running that with LD_DEBUG set in the environment might give a clue.
Likely there will be a lot of output, so have plenty of scrollback buffer,
or use script(1). In this case it's pulling in something from OpenBSD 6.3
era.

> casa:/home/giannici# dolphin
> dolphin:/usr/local/lib/libattica.so.1.0: 
> /usr/local/lib/libKF5Attica.so.3.3 : WARNING: 
> symbol(_ZN6Attica15ProviderManager16staticMetaObjectE) size mismatch, 
> relink your program

Same for LD_DEBUG with this. In this case something tries to pull in
kde4 and kf5 versions of attica which conflict.




Re: Is there any supported watchdog hardware straight out of the box?

2019-04-27 Thread Stuart Henderson
On 2019-04-27, Igor Podlesny  wrote:
> On Fri, 26 Apr 2019 at 22:58, Stuart Henderson  wrote:
>> On 2019-04-26, Igor Podlesny  wrote:
>> > Or would kernel's recompiling be needed anyways?
> [...]
>> Recompiling would be needed.
>>
>> If you want to try it, see faq 5 about fetching the source tree,
>> add "ichwdt* at pci?" to /sys/arch/amd64/conf/GENERIC. then see faq 5
>> about building a kernel.
>
> Thanks for confirmation and brief how-to even. I'd like to clarify the matter 
> in
> more general ways though.
>
> 1) Is it true that more or less fresh OpenBSD generic kernels come with
> no support of any watchdog hw?

It is not true. They don't have *wide* support but there is some
supported hw. If someone wants to change this, I suggest adding acpi
watchdog support would give the best return for time spent.

> 2) I heard that kernel modules were intentionally rid of in OpenBSD
> primarily due
> security concerns -- did it really happen for that reason? If so, and
> I assume that
> happened long ago, were there any developer's opinions to undo this? Actually
> even not taking crypto verification approach (modules signing) one
> could always have
> secure level increased high enough to cut down this vector of attacks
> completely.

LKM added a bunch of complexity to all kernels with only a small benefit
to a small subset of users, and there's a viable alternative (build your
own kernels rather than just the module). It's not like a kernel build
takes all that long.

> OTOH, it's well known that dynamic loading approach greatly expands
> functionality of
> OS and makes it more convenient to use.

They also gave an easy way for people to add crap to their kernels.
At least with static kernels we can identify from dmesg when somebody
reporting a problem is running something other than a standard kernel
build. With LKMs this is gone, the most we'll have is a printf, but
people reporting bugs have a tendency to remove things they don't want
to show or think are unimportant.

Also I don't see what this has to do with watchdogs, you would normally
not want to wait until userland starts and LKMs are loaded before arming
the watchdog.



Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread Kevin Chadwick
On 4/27/19 8:23 AM, Otto Moerbeek wrote:
> Additionally, in many cases using a symlink has unclear effects, since
> it is hard to determine if the first malloc call (malloc inits itself
> on first use) happens before of after the chroot call. I would argue
> that in many cases people were thinking they had per-chroot settings,
> while actually they had not.

Also, as Otto informed me on twitter, base is quite happy with the stronger
settings.

The code that really needs weaker settings inside the chroot, probably needs the
stronger settings the most, technically (if it didn't break). I like the more
convenient sysctl.

Be careful though, S cost me a couple of hours last night. After much success on
many systems without issue. I foolishly enabled S at the same time as PHP5 with
suhosin to php7 upgrade, All the statically built pledged parts, femail, PHP
output and reop, worked individually but femail would not send the mail when
directly sent from PHP. I still don't understand how malloc S could cause that
but turning back to the default, solved the breakage.

In any case, the inherent clarity of what is happening under the hood in golang
(php sh flags etc.) and the loss of php suhosin function whitelist feature
(again) that has avoided so many CVEs has affirmed moving to golang. Therefore,
I am not so bothered about finding why unless it helps OpenBSD somehow, which I
doubt?



Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread Consus
I like reading misc@ mostly due to the constanst BUTTHURT that is going
on here.

But seriously though, each program can change it's own malloc flags
either by calling setenv(3) or just by updating static malloc_options
variable. So there is really *NO* difference between your old way
(/etc/malloc.conf) and your new way (setenv MALLOC_OPTIONS). There is a
possibility that a program will reset it's own env, but it would most
likely not.



headphone volume levels cannot be manipulated by mixerctl

2019-04-27 Thread Levente


signature.asc
Description: OpenPGP digital signature


Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread Otto Moerbeek
On Fri, Apr 26, 2019 at 11:46:17PM -0600, Theo de Raadt wrote:

> Igor Podlesny  wrote:
> 
> > On Sat, 27 Apr 2019 at 12:37, Anthony J. Bentley  wrote:
> > >
> > > You didn't check the manpage.
> > 
> > you didn't think it over.
> > https://www.mail-archive.com/misc@openbsd.org/msg167012.html
> 
> No, you didn't think it through at all.
> 
> You are expecting the malloc settings to provide security gaurantees.
> They do not.  They detect corruption.  That is not the same as
> a security gaurantee.
> 
> Then you wish to use this inside a chroot jail, and make it tighter.
> 
> Fine.
> 
> Next you argue but what if the program inside the jail adjusts
> it's environment.  Well then all bets are off.  Why would that
> program modify it's environment variable only, rather than just
> doing anything else it wants to do?
> 
> Why would it restrict itself to adjusting this specific environment
> variable only, and why would you consider that to impact security?
> 
> 
> The malloc configuration was moved to a sysctl to make it compatible
> with pledge+unveil.  It has tightened the security in many programs.
> 
> The change has weakened security in your configurations because
> you designed them wrong.

Additionally, in many cases using a symlink has unclear effects, since
it is hard to determine if the first malloc call (malloc inits itself
on first use) happens before of after the chroot call. I would argue
that in many cases people were thinking they had per-chroot settings,
while actually they had not.

-Otto


> 
> Finally Igor you are being a jerk.  Cut it out.
> 



Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread Igor Podlesny
On Sat, 27 Apr 2019 at 12:55, Theo de Raadt  wrote:
> Igor Podlesny  wrote:
> > On Sat, 27 Apr 2019 at 12:37, Anthony J. Bentley  wrote:
> > > You didn't check the manpage.
> >
> > you didn't think it over.
> > https://www.mail-archive.com/misc@openbsd.org/msg167012.html
>
> Igor, talking back to the developers of the operating system you use is
> never a good idea.

Theo, if you can't read your mail list w/o losing your shit, don't
make it public.

-- 
End of message. Next message?