Re: Project: Creating an "immutable" OpenBSD disk image with Packer and Ansible

[Nick Holland]

On 03/31/16 03:55, Yann Hamon wrote:
> Hi,
> 
> I've been working for some time on a project to manage my router@home, 
> I'm sharing it here in the hope that it will be useful to someone else.
> 
> Here it is: https://github.com/yannh/openbsd_immutable_router
> 
> It contains a set of configuration scripts for Packer and Ansible that 
> make it easy to generate a disk image, that you can then copy to a USB 
> stick to boot from.
> 
> To minimize writes to the USB stick,

once again, I (and many others) will ask, "Why?"

> the root partition is mounted 
> read-only, and all folders that require writes are mounted as MFS.

My home FW systems have been running on the same USB sticks for quite
some time, one for a few years, the other probably at least a couple
years.  On the cheapest junk USB sticks I could find.

FWs don't write much.  And when they do, you might just want to see what
they have to say.

IF you are worried about reliability, put a second USB flash device in
place, use "ROOTBACKUP" (man daily) and dd over the other partitions
once a week (note: this is a place where DUIDs are not always your
friend).  (I tried softraid on the USB devices, it definitely worked,
but the writes were S SLW I really didn't like it.)
...
> This workflow allows me to regenerate an image, or do a system upgrade, 
> in about 20 minutes - packer build -var-file=config.json openbsd.json, 
> dd if=output-qemu/openbsd of=/dev/sdb, reboot. I procrastinate less when 
> doing my upgrades now :)

Again, I'm not seeing a benefit here.  20 minutes?  Ok, I'll admit I
don't install x*tgz or comp*tgz on my USB flash based firewalls (for
speed reasons only), but my upgrade times just doing things normally are
less than that...and with only a couple minutes of downtime where
packets don't get through.

Nick.

lyrics.html omellete --> omelette

[ropers]

http://www.openbsd.org/lyrics.html

s/omellete/omelette/g

Or omelet in American English.

Re: W^X enforcement

[Juan Francisco Cantero Hurtado]

On Thu, Mar 31, 2016 at 08:44:58AM -0600, Theo de Raadt wrote:
[...]
> I generally reject the addition of security knobs, and push towards
> making the security choice mandatory, as early as possible.  We are
> not quite in the position of making this choice.  (Maybe a ports
> developer can list some programs that require WX memory today)

There is an external project for Arch Linux which keeps a list of the
programs incompatible with PaX's equivalent to W^X.

https://github.com/thestinger/paxd/blob/master/paxd.conf

The programs marked with "m" are incompatible.

-- 
Juan Francisco Cantero Hurtado http://juanfra.info

Re: support new

[Kihaguru Gathura]

Please add me to the support list or advice accordingly. I had made the
same request on March 4th and this is a resend.

Thank you for the early release of 5.9 !

Forever grateful for the treasure that OpenBSD is.

regards,

Kihaguru

Re: Socklog on OpenBSD -current

[Stuart Henderson]

On 2016-03-30, Predrag Punosevac  wrote:
> On 3/29/16 5:42 PM, Stuart Henderson wrote:
>> On 2016-03-29, Jeff Ross  wrote:
>>> Greetings all!
>>>
>>> I've been away from OpenBSD for a while and for sure I've missed more
>>> than a few things.  Just updated a firewall in anticipation of
> upgrading
>>> my server but there are things that have changed.
>>>
>>> What has me puzzled now is the change to syslogd.  For literally
> years
>>> I've run socklog from ports to replace the stock syslog with no
> problems
>>> but now it simply doesn't work on 5.9 -current.
>>>
>>> My former installations of socklog all listen to /dev/log but when I
>>> couldn't get anything to work listening there I switched to listening
> to
>>> 0.0.0.0:514 but still no joy.
>>>
>>> If anyone out there is using socklog, or possibly any alternative to
>>> syslog, I'd sure appreciate a clue by four to get socklog running
> again.
>> OpenBSD's syslog functions now use sendsyslog(2) which doesn't use
>> /dev/log sockets any more.
>>
>> Here is where syslogd was modified to do things this way:
>>
> http://anoncvs.spacehopper.org/openbsd-src/commit/?id=c40e16771993e74275857863c928d7f9cffe3699
>> - it's probably not all that complex to convert other logging daemons,
>> but afaik nobody has yet felt the need to do this for any of the
>> alternative log daemons in ports.
>>
>> If you don't want to write code and want to stick with socklog,
>> the easiest way is probably a minimal syslogd(8) setup that
>> forwards everything via UDP.
>>
> Hi Stuart,
>
> Could you please clarify something to me? I am running a centralized
> logging server using syslog-ng from the ports. The way I read your
> e-mail is that I will no longer be able to log messages using syslog-ng
> from the local host but the port will continue to work as expected.

Yes, this isn't particularly new though, it changed in 5.6.

> Would I be able to run syslogd for the local host and syslog-ng for
> remote hosts simultaneously? IIRC I saw people posting on misc who were
> doing that in the past but I think when I played with it syslog-ng
> didn't want to start until I turned off syslogd.

You can run two simultaneously but you'll need to get one of them to
bind to a specific IP address.

>  How suitable is syslogd
> from the base as a centralized logging server. I know that it supports
> TCP and TLS now but does it play well with rsyslog or syslog-ng? I have
> bunch of Linux servers to log.

If you can get them to feed it syslog messages using either the usual
UDP-based syslog protocol or using a TCP/TLS protocol then that should
work fine (IIRC the TLS code was developed against one of these,
possibly rsyslog?). syslogd(8) / syslog.conf(5) gained +host/++host
matching that allows you to separate logs between different hosts
into different files which can be useful on a centralised log host.
There are lots of options of how to set this all up.

Fwd: support new

[Kihaguru Gathura]

-- Forwarded message --
From: Kihaguru Gathura 
Date: Fri, Mar 4, 2016 at 9:07 PM
Subject: support new
To: misc@openbsd.org


0
C Kenya
P Nairobi
T Nairobi
Z P.O Box 51348-00200
O Consultant
I Kihaguru Njenga
A
M kihaguru.nje...@gmail.com
U
B +254 706970697
X
N OpenBSD installations and maintenance. Web applications development
with OpenBSD-httpd web server and cgi in c.

Re: WAPBL?

[Walter Neto]

Hi Predrag,

2016-03-28 22:42 GMT-03:00 Predrag Punosevac :
> Walter Neto wrote:
>
>>
>> Hi,
>>
>> I'm not working on it for a while. Sadly I am with no time, but trying
>> to escape to return. :(
>>
>
> This is most regrettable. I was following your work on porting WAPBL and
> the correspondence on tech@openbsd with great interest. Do you think
> that a help from OpenBSD foundation could enable you to resume the work
> on porting WAPBL?
>

It would be perfect, but I need to finish some work commitments first.

>
> Predrag
>
>
>> 2016-03-26 16:27 GMT-03:00 Martijn Rijkeboer :
>> > Hi,
>> >
>> > Just out of curiosity, what has happend with WAPBL? There were some
>> patches
>> > floating around on tech@ in the last months of 2015, but then it
>> became
>> > quiet. I'm not complaining just curious.
>> >
>> > Kind regards,
>> >
>> >
>> > Martijn Rijkeboer

Re: date not respect for 5.8 and 5.9

[Vivek Vinod]

‎OpenBSD is based out of Canada. They run their power stations on renewable
energy.

This climate change is a big threat, though it worked in our favour this time.
Climate change caused heavy winds, which made the wind turbines turn a bit
faster, generating a lot of power. 

Canadian power equipment is also a bit sensitive to sudden spikes in
voltage/amperes. They sometimes discharge a few extra volts and assume nothing
bad will happen to end users equipment.

OpenBSD is compiled on processors (look up cell processors) which run faster
when supplied more power. Hence a few days early as the compilation happened
really fast. 

Regardless, I think it's climate change that we got to worry about more than
an early release date. 

Vivek  

Sent from my BlackBerry 10 smartphone.
  Original Message  
From: Max Power
Sent: Thursday 31 March 2016 14:46
To: misc@openbsd.org
Subject: date not respect for 5.8 and 5.9

Hi guys!
Why the release 5.8 and 5.9 did not comply with the canonical date
of the 1th November and of the 1th May?

Thanks in advance for your reply.

Re: W^X enforcement

[Theo de Raadt]

> In portable software, a grep for PROT_EXEC finds almost all the work
> which still needs to be done...

I am suggesting grep is enough because the four forms one will find in
code are:

mmap(... PROT_EXEC, ...)
mprotect(... PROT_EXEC, ...)

prot = PROT_EXEC ...
mmap(... prot, ... )

prot = PROT_EXEC ...
mprotect(... prot, )

To improve the situation, the roadmap would be to find those in the
ecosystem, and ask people in those software projects to consider a
fresh evaluation and improvement...

Some of them will not be easy.  But I've already mentioned chrome :)

Re: date not respect for 5.8 and 5.9

[Daniel Ouellet]

On 3/31/16 4:58 AM, Max Power wrote:
> Hi guys!
> Why the release 5.8 and 5.9 did not comply with the canonical date
> of the 1th November and of the 1th May?
> 
> Thanks in advance for your reply.

Because Buffy swim upstream with the salmons this year in the cold
rivers of Canada and felt he could take a break sooner then usual for
his considerable effort!

See Salmons dead after that and have laid their eggs, but our brave
Puffy survive the exercise and made a time leap forward.

Why can people not just say THANKS YOU and be grateful and appreciative
for a grace of an early release but question everything all the time is
beyond me...

Why should this comply with anything really?

I for one will say it as I haven;'t seen any yet on the list.

Thank you guys to release 5.9 sooner it very much appreciated!

Again THANK YOU

Long live Puffy.

Daniel

PS: Hmm. Now does this mean we will have some spiky little puffy/salmons
hybrid this season... I wonder.

Re: W^X enforcement

[Theo de Raadt]

> > because well.. firefox was asking for it until a few months ago...
> > 
> > I believe chrome / v8 still requires WX memory.
> 
> I guess webkits JIT that xombrero depends on requires WX still? The
> performance, features and simplicity of xombrero made it a no brainer
> but perhaps on OpenBSD 6? (threaded performance improvement) it may be
> time to re-evaluate the winner of my primary browser spot?

Firefox has aliased-backed W^X, but no sandboxing of any kind

Chrome has priv-seperation, with different pledge requests in each process

Both crews have work to do.

Re: W^X enforcement

[Theo de Raadt]

> > Therefore, W^X has always been a policy for software to follow.  Meaning,
> > the libraries won't ask for WX, ld.so won't ask for WX, nothing will.
> > If something wants to shoot itself in the foot, we could not stop it,
> > because well.. firefox was asking for it until a few months ago...
> 
> Yes, we actually have fairly strict W^X enforcement as an option (which
> can still be tricked by aliasing), and there's an exception for Firefox
> in it.

In OpenBSD, there is nowhere to "mark" a binary with a "knob" to say
whether it may do that, or not.  We don't have an outside subsystem
keeping track of knobs, nor does our filesystem have markers (because
NFS).  Only method which is really comparable is that pledge(2)'d
software cannot set X unless requesting "prot_exec".

We don't have such a marking mechanism, and never used it for previous
security advances.  we did not find it neccessary -- we simply jumped
forward and mandated the newer strict behaviour, or acceptance of
greater object randomization -- the rules changed, that thing you do
is no longer allowed, go fix your code...  yes, it is a luxury that we
can do this..

Mandatory W^X could be handled the same, but it requires heavy lifting
in the final pieces of (monster software) which request W|X, generally
these are JIT engines, I believe that is due to a meme which developed
back in ~2000 that mprotect X/W flips are expensive (they were on some
systems; that was a bug).

There are not many pieces of software left, but fixing them will
require investment.

> So that the process cannot make memory W|X even some code
> is injected into it, and use that to inject parasitic code?

If code has been injected, and then does a W|X allocation, what's the
point.  Code has already been injected, the attacker does not need to
do this.  There are other avenues for such an attacker, he does not
need to create a W|X memory segment to gain further benefit since he
already is running his own code.  mmap PROT_WRITE, place data,
mprotect PROT_EXEC.  In general once an attacker is in control, we
don't need to investigate complex avenues.

The prot parameter in code flow to reach mmap/mprotect is invariably
a static parameter, and not easily influenced.

> My expectation is that once an attacker can force a process to do that,
> they can also perform the mprotect after the copy of the injected code,
> or use some other mechanism to install the parasite (dlopen, for
> example).  Lack of a W|X mapping would not be a substantial hurdle at
> this point.

EXACTLY.

> And parasites probably aren't that relevant as a threat
> until you have an ecosystem of various forms of host-based intrusion
> detection.

Exactly.

And that's why W^X as a programmer policy has been effective.

The programs which still request W|X memory are essentially following
bad practice, and creating a knob which we set for the "good programs"
and leave off for the "bad programs" doesn't act as more than a
"quality assessment" marker.

Mandating W^X for chrome will simply break chrome.  Then the "knob"
gets turned off.  The existance of a knob will not influence the
chrome developers to move towards W^X policy, it is like waggling a
stick in front of them, with them laughing that all the users flip the
knob the other way.

We need to socialize mandatory W^X in such communities.  We've been
doing this for quite a while.

> Thanks for the explanation.  It would still be useful for testing
> purposes, I think, to find any transient W|X mappings which don't show
> up in /proc.

In portable software, a grep for PROT_EXEC finds almost all the work
which still needs to be done...

Fixing them, that's another matter.  W|X-using software tends to be on
the large side (liike chrome), and the communities around them have to
start believing in this policy and apply it to their software --
hopefully realizing that W|X mappings are not really on the hot-path
for most JIT engines.  Basically those projects have to invest time
making such changes.

But I am repeating myself..

> > Well, alias mappings are generally an unsafe practice; in a ROP attack
> > environment it is likely that variables -- pointing towards the
> > aliased space -- will be found in registers... or at least registers
> > pointing at some object ... which points at some object ... which
> > knows where the alias space is..
> 
> Oh.  But once one uses PC-relative addressing to reach data (both
> read-only and read-write), then data pointers leak code address
> information, too.  And if you don't use PC-relative addressing, the
> address has to come from somewhere else.

Imagine a pointer to a structure with { void *x_mem, void *w_mem; }
being valid at the point an attacker finds a bug, then all bets are
up.  From a high-level language, it is not possible to control nor
measure whether there is dangerous leakage.  Similar situations could
occur even if a high level programmer tries to be cautious and avoid
such a structure, because CPUs with a 

Re: W^X enforcement

[Kevin Chadwick]

> because well.. firefox was asking for it until a few months ago...
> 
> I believe chrome / v8 still requires WX memory.

I guess webkits JIT that xombrero depends on requires WX still? The
performance, features and simplicity of xombrero made it a no brainer
but perhaps on OpenBSD 6? (threaded performance improvement) it may be
time to re-evaluate the winner of my primary browser spot?

-- 

KISSIS - Keep It Simple So It's Securable

Re: W^X enforcement

[Florian Weimer]

On 03/31/2016 04:44 PM, Theo de Raadt wrote:

> Therefore, W^X has always been a policy for software to follow.  Meaning,
> the libraries won't ask for WX, ld.so won't ask for WX, nothing will.
> If something wants to shoot itself in the foot, we could not stop it,
> because well.. firefox was asking for it until a few months ago...

Yes, we actually have fairly strict W^X enforcement as an option (which
can still be tricked by aliasing), and there's an exception for Firefox
in it.

>From a security perspective, the main question is whether it makes sense
to deny processes the ability to request W|X mappings.  I see the value
in making sure they don't do this during regular operation, but is it
necessary to take away this ability by blocking the syscall with those
parameters?  So that the process cannot make memory W|X even some code
is injected into it, and use that to inject parasitic code?  My
expectation is that once an attacker can force a process to do that,
they can also perform the mprotect after the copy of the injected code,
or use some other mechanism to install the parasite (dlopen, for
example).  Lack of a W|X mapping would not be a substantial hurdle at
this point.  And parasites probably aren't that relevant as a threat
until you have an ecosystem of various forms of host-based intrusion
detection.

>> Is there a knob to enable W^X enforcement?
> 
> No, we don't have such a knob, because the greater ecosystem isn't
> clean enough yet to mandate it.  I'd like for us to get there.

Thanks for the explanation.  It would still be useful for testing
purposes, I think, to find any transient W|X mappings which don't show
up in /proc.

> Well, alias mappings are generally an unsafe practice; in a ROP attack
> environment it is likely that variables -- pointing towards the
> aliased space -- will be found in registers... or at least registers
> pointing at some object ... which points at some object ... which
> knows where the alias space is..

Oh.  But once one uses PC-relative addressing to reach data (both
read-only and read-write), then data pointers leak code address
information, too.  And if you don't use PC-relative addressing, the
address has to come from somewhere else.

Florian

Re: smtpctl(97175): syscall 141 ""

[Theo de Raadt]

> Fetching the lastest amd64-current snapshot or compiling with the latest
  ^^^
> sources results in the error message
> smtpctl(97175): syscall 141 ""
> 
> Any operation that requires root privileges via 'doas' or at startup
> terminate with
> Bad system call (core dumped)
> 
> Is this an issue already known or should I provide more information? I
> can 'ssh' to the machine. The last working dmesg is attached.

Your statement is incorrect.  You are not using a new snapshot.  Your
kernel is older, and lacks a new system call.

Re: W^X enforcement

[Theo de Raadt]

> I generally reject the addition of security knobs, and push towards
> making the security choice mandatory, as early as possible.  We are
> not quite in the position of making this choice.  (Maybe a ports
> developer can list some programs that require WX memory today)

I should stress this point I made earlier.

I believe that "applying pressure which cannot be turned off" is the
only way to pull the greater software ecosystem towards these kinds of
decisions.

Yes, there are pieces of software which are large and fight against
the pressure, because they lack someone to invest time into solving
the problem.

Re: ncurses and ncursesw share same header?

[Christian Weisgerber]

On 2016-03-31, Carsten Kunze  wrote:

> curses, ncurses and ncursesw library seem to be hard links to one
> file.  So that means that with the -l option I decide which functions
> I use and always simply include ?

It is all the same library and it uses the same header header file. 
Just include  and link with -lcurses.  The other names
are only for compatibility.

For wide curses functionality, just call the wide curses functions,
e.g. add_wch(3).

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

Re: W^X enforcement

[Theo de Raadt]

> This may be a bit of a silly question.  There is talk about an upcoming
> Common Criteria requirement that no memory may be executable and
> writable at the same time.

That comes a little late (meaning lots of software was written to
require this, over the last decades), but also a little early (lots
of software has been fixed... but not everything).

Firefox only became capable of running without WX pages a few months
ago.  Meaning, any operating system which ENFORCED W^X would be unable
to run it.

Therefore, W^X has always been a policy for software to follow.  Meaning,
the libraries won't ask for WX, ld.so won't ask for WX, nothing will.
If something wants to shoot itself in the foot, we could not stop it,
because well.. firefox was asking for it until a few months ago...

I believe chrome / v8 still requires WX memory.

>  OpenBSD is said to meet this requirement.

That requirement is a nice idea, but there is software in the ports
ecosystem which still requires it.

> However, I installed the amd64 variant of OpenBSD 5.9, and ran short
> test program which allocates a W|X page using:
> 
>   void *addr = mmap (NULL, page_size,
>  PROT_READ | PROT_WRITE | PROT_EXEC,
>  MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
> 
> mmap succeeds, and the page is writable and executable.  (The test case
> even writes it, executes, writes it again with different contents, and
> executes it again.)
> 
> Is there a knob to enable W^X enforcement?

No, we don't have such a knob, because the greater ecosystem isn't
clean enough yet to mandate it.  I'd like for us to get there.

I generally reject the addition of security knobs, and push towards
making the security choice mandatory, as early as possible.  We are
not quite in the position of making this choice.  (Maybe a ports
developer can list some programs that require WX memory today)

I hope no new software is being written to depend on WX allocations
working...

> Or does W^X just mean that you won't get W|X memory unless you ask
> for it explicitly?

Yes, in effect if you ask for it explicitly (either with mmap, or with
mprotect), we have to provide it.  I hate it, but the ecosystem is
still stuck there, until some investment happens to push a few pieces
of software into W^X mode, mostly on the JIT side.

We all know better now: JITs that follow W^X are not substantially
slower, and they are substantially more secure.

> (I know that historically, if you asked for W|R memory, say using
> malloc, you got W|R|X on i386 because there was no separate per-page
> flag for read and exec, and the segment size limit kludge wasn't
> invented yet.)

Oh it was worse than that!  Around 20 years ago, the heap was
executable, and there even was a small time when mmap-based malloc's
allocated PROT_READ | PROT_WRITE | PROT_EXEC memory.

> I understand that we (the larger ecosystem) still need to change some
> applications not to perform PROT_WRITE | PROT_EXEC (or the equivalent
> alias mapping kludge).

Well, alias mappings are generally an unsafe practice; in a ROP attack
environment it is likely that variables -- pointing towards the
aliased space -- will be found in registers... or at least registers
pointing at some object ... which points at some object ... which
knows where the alias space is..

Re: Syntax error in pf rules

[Marko Cupać]

On another occasion when Master Foo gave public instruction, an end
user, having heard tales of the Master's wisdom, came to him for
guidance.

He bowed three times to Master Foo. “I wish to learn the Great Way of
Unix,” he said “but the command line confuses me.”

Some of the onlooking neophytes began to mock the end user, calling him
“clueless” and saying that the Way of Unix is only for those of
discipline and intelligence.

The Master held up a hand for silence, and called the most obstreperous
of the neophytes who had mocked forward, to where he and the end user
sat.

“Tell me,” he asked the neophyte, “of the code you have written and the
works of design you have uttered.”

The neophyte began to stammer out a reply, but fell silent.

Master Foo turned to the end-user. “Tell me,” he inquired, “why do you
seek the Way?”

“I am discontent with the software I see around me,” the end user
replied. “It neither performs reliably nor pleases the eye and hand.
Having heard that the Unix way, though difficult, is superior, I seek
to cast aside all snares and delusions.”

“And what do you do in the world,” asked Master Foo, “that you must
strive with software?”

“I am a builder,” the end user replied, “Many of the houses of this
town were made under my chop.”

Master Foo turned back to the neophyte. “The housecat may mock the
tiger,” said the master, “but doing so will not make his purr into a
roar.”

Upon hearing this, the neophyte was enlightened.

http://catb.org/esr/writings/unix-koans/end-user.html
--
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Re: Syntax error in pf rules

[Paul Suh]

> On Mar 30, 2016, at 10:58 PM, Adam Smith  wrote:
> 
> Are you the owner of misc@openbsd.org?
> 
>> --- dera...@cvs.openbsd.org wrote:
>> 
>> From: Theo de Raadt 
>> To: ken...@dcemail.com
>> 
>>> I know. Do you have proof that I hadn't put in my minimum effort
>>> before jumping to conclusions?

This guy has clearly just provided proof! :-D 

Now where did I put that spray can of troll repellent? 


--Paul

[demime 1.01d removed an attachment of type application/pkcs7-signature which 
had a name of smime.p7s]

Re: Project: Creating an "immutable" OpenBSD disk image with Packer and Ansible

[Antoine Jacoutot]

On Thu, Mar 31, 2016 at 09:55:39AM +0200, Yann Hamon wrote:
> Hi,
> 
> I've been working for some time on a project to manage my router@home, I'm
> sharing it here in the hope that it will be useful to someone else.
> 
> Here it is: https://github.com/yannh/openbsd_immutable_router
> 
> It contains a set of configuration scripts for Packer and Ansible that make
> it easy to generate a disk image, that you can then copy to a USB stick to
> boot from.
> 
> To minimize writes to the USB stick, the root partition is mounted
> read-only, and all folders that require writes are mounted as MFS.
> 
> There is also some pf/dyndns/pppoe configuration that I left for learning
> purposes.
> 
> This workflow allows me to regenerate an image, or do a system upgrade, in
> about 20 minutes - packer build -var-file=config.json openbsd.json, dd
> if=output-qemu/openbsd of=/dev/sdb, reboot. I procrastinate less when doing
> my upgrades now :)

Oh that's funky. Thanks :-)

-- 
Antoine

W^X enforcement

[Florian Weimer]

This may be a bit of a silly question.  There is talk about an upcoming
Common Criteria requirement that no memory may be executable and
writable at the same time.  OpenBSD is said to meet this requirement.

However, I installed the amd64 variant of OpenBSD 5.9, and ran short
test program which allocates a W|X page using:

  void *addr = mmap (NULL, page_size,
 PROT_READ | PROT_WRITE | PROT_EXEC,
 MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);

mmap succeeds, and the page is writable and executable.  (The test case
even writes it, executes, writes it again with different contents, and
executes it again.)

Is there a knob to enable W^X enforcement?  Or does W^X just mean that
you won't get W|X memory unless you ask for it explicitly?  (I know that
historically, if you asked for W|R memory, say using malloc, you got
W|R|X on i386 because there was no separate per-page flag for read and
exec, and the segment size limit kludge wasn't invented yet.)

I understand that we (the larger ecosystem) still need to change some
applications not to perform PROT_WRITE | PROT_EXEC (or the equivalent
alias mapping kludge).

Thanks,
Florian

Re: OpenBSD misc

[Kevin Chadwick]

> Hi Jubjub Jenkins,
> 
> That's your name, isn't it? Or it's just a pseudonym behind which you hide 
> all your hatred towards humanity?
> 
> If you're the person in charge of misc@openbsd.org, just ban me from posting 
> to it.
> 
> Adam

Arch linux started moderating, it is a bad idea. Hard truths like ntp
could be insecure (knowing about the work behind OpenNTP) and fsck
should not fail from a dead bios battery should be heard and not called
out as trolling but there was thought behind it. A good example
because it turns out ntp was insecure. Other things were later
moderated that did turn out to be true too (I forget the details
and don't care enough to look them up but patches proved it).

That does not give u the right to be disrespectful of the rules of a
mailing list though even if I have been guilty of being lazy myself
before when snowed under.

http://www.openbsd.org/mail.html

Considering you top posted maybe you are just unconsiderate of other
peoples time, in which case people have short memories. OTOH is
kenhen@dcemail a reference to hen in the kennel trying to get everyone
to attack? If that is true then developers are doing important work
here and don't get enough for it but I expect that to change. The work
is certainly far more worthy than work done in FreeBSD.

You know I believe FreeBSD uses an old? PF by default these days so
maybe they like Apple and Blackberry owe OpenBSD some cash??

-- 

KISSIS - Keep It Simple So It's Securable

smtpctl(97175): syscall 141 ""

[Stefan Wollny]

Hi there!

Fetching the lastest amd64-current snapshot or compiling with the latest
sources results in the error message
smtpctl(97175): syscall 141 ""

Any operation that requires root privileges via 'doas' or at startup
terminate with
Bad system call (core dumped)

Is this an issue already known or should I provide more information? I
can 'ssh' to the machine. The last working dmesg is attached.

Best,
STEFAN

OpenBSD 5.9-current (GENERIC.MP) #1970: Mon Mar 28 17:02:06 MDT 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
RTC BIOS diagnostic error
f7
real mem = 8279707648 (7896MB)
avail mem = 8024420352 (7652MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe (43 entries)
bios0: vendor Apple Inc. version "IM91.88Z.008D.B08.0904271717" date
04/27/09
bios0: Apple Inc. iMac9,1
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC MCFG ASF! SBST ECDT SSDT SSDT SSDT
acpi0: wakeup devices EC__(S3) OHC1(S3) EHC1(S3) OHC2(S3) EHC2(S3) GIGE(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 2500 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU E8135 @ 2.66GHz, 1592.26 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
cpu0: 6MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 265MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU E8135 @ 2.66GHz, 1592.01 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
cpu1: 6MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 1
acpimcfg0 at acpi0 addr 0xf000, bus 0-255
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 3 (IXVE)
acpicpu0 at acpi0: !C3(100@57 mwait.3@0x31), !C2(500@1 mwait@0x10),
C1(1000@1 mwait), PSS
acpicpu1 at acpi0: !C3(100@57 mwait.3@0x31), !C2(500@1 mwait@0x10),
C1(1000@1 mwait), PSS
"APP0002" at acpi0 not configured
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: SLPB
"PNP0A08" at acpi0 not configured
"PNP0C02" at acpi0 not configured
"APP0001" at acpi0 not configured
"PNP0C09" at acpi0 not configured
"PNP0200" at acpi0 not configured
"PNP0103" at acpi0 not configured
"PNP" at acpi0 not configured
"PNP0C04" at acpi0 not configured
"PNP0C02" at acpi0 not configured
"PNP0B00" at acpi0 not configured
"PNP0100" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
"PNP0C0F" at acpi0 not configured
cpu0: Enhanced SpeedStep 1592 MHz: speeds: 2660, 2394, 2128, 1862, 1596 MHz
memory map conflict 0xffc0/0x40
pci0 at mainbus0 bus 0
0:3:5: mem address conflict 0xd350/0x8
pchb0 at pci0 dev 0 function 0 "NVIDIA MCP79 Host" rev 0xb1
"NVIDIA MCP79 Memory" rev 0xb1 at pci0 dev 0 function 1 not configured
pcib0 at pci0 dev 3 function 0 "NVIDIA MCP79 ISA" rev 0xb2
"NVIDIA MCP79 Memory" rev 0xb1 at pci0 dev 3 

Re: Supermicro X11SSL-F freezes probing USB 3

[Raul Miller]

On Thu, Mar 31, 2016 at 2:14 AM, Paul B. Henson  wrote:
> Eeew. We've got some HP gear that requires an extra cost license to make
> the remote kvm gui head work past the bootloader which is ridiculous
> (but technically, I don't think remote kvm is part of the base IPMI
> standard), but the IPMI SOL serial port??? That's just crazy. I've never
> used Dell and never will for servers; desktops/notebooks, sure, but
> servers? Nah. Sun gear was pretty good until Oracle killed them off, we
> used IBM for a while until they sold it off to Lenovo and policy
> wouldn't let us buy from a non-US company (like the gear itself doesn't
> come from China anyway). Right now we're using HP at my dayjob and it's
> working out ok. I pretty much use supermicro for personal gear and
> sidejobs, it's generally good stuff. At least my IPMI SOL port works :).

Trade agreements with China are complicated (and the Chinese
government has had *considerable* say in their structure and details -
perhaps more say than our own government).

I could go into some details on some of why things are this way, but
that's getting too far off-topic for this mailing list.

That said, I will say that there's some pretty good reasons (and some
pretty bad reasons) for why things are the way they are - but also,
that I expect things to change, and not all in ways that you might
appreciate.

Anyways, my point is, you might want to take advantage of the current
relatively lax policies while you can. (Or, ok, maybe for your
particular situation, things will actually get better - I don't
actually know the details of how this will play out...)

-- 
Raul

ncursesw header not found

[Carsten Kunze]

Hello,

in /usr/lib there seems to be the ncursesw library but I don't find a ncursesw 
header file (expected as something like .../ncursesw/curses.h).  I also don't 
find a curses package to install.  Is there ncursesw support for OpenBSD?  I 
found threads from 2010, but I'm not sure if they are still valid today.

--Carsten

Re: ncursesw header not found

[Christer Solskogen]

On Thu, Mar 31, 2016 at 10:22 AM, Carsten Kunze 
wrote:
> Hello,
>
> in /usr/lib there seems to be the ncursesw library but I don't find a
ncursesw header file (expected as something like .../ncursesw/curses.h).  I
also don't find a curses package to install.  Is there ncursesw support for
OpenBSD?  I found threads from 2010, but I'm not sure if they are still valid
today.
>

What about /usr/include/ncurses.h?

--
chs

ncurses and ncursesw share same header?

[Carsten Kunze]

curses, ncurses and ncursesw library seem to be hard links to one file.  So 
that means that with the -l option I decide which functions I use and always 
simply include ?  (At least this states the curses manpage.)

Re: date not respect for 5.8 and 5.9

[Otto Moerbeek]

Max Power  schreef op 31 maart 2016 10:58:00 CEST:
>Hi guys!
>Why the release 5.8 and 5.9 did not comply with the canonical date
>of the 1th November and of the 1th May?
>
>Thanks in advance for your reply.

Because we are Time Lords?
-Otto

date not respect for 5.8 and 5.9

[Max Power]

Hi guys!
Why the release 5.8 and 5.9 did not comply with the canonical date
of the 1th November and of the 1th May?

Thanks in advance for your reply.

new (again) support entries for BackWatcher, Inc.

[Kyle Amon]

Hello,

After many years "in the wilderness," I'm hanging "the shingle" back up, as
it were.  Therefore, please re-add my "OpenBSD Support and Consulting"
listing
to both the USA and Canada sections as follows...

USA...

0
C USA
P Florida
T Bradenton
Z 34203-7305
O BackWatcher, Inc.
I Kyle Amon
A 3819 Garden Lakes Terrace
M i...@backwatcher.com
U http://www.backwatcher.com/
B +1-425-584-UNIX
N While specialising in security, BackWatcher handles installation and
configuration, systems integration, performance tuning, disaster recovery,
network architecture, programming and general systems administration of
OpenBSD, NetBSD, FreeBSD, Dragonfly BSD, Linux and many commercial UNIX
flavors.

Canada...

0
C Canada
P British Columbia
T Campbell River
Z V9W 5T5
O BackWatcher, Inc.
I Kyle Amon
A 413-1434 Ironwood Street
M i...@backwatcher.ca
U http://www.backwatcher.ca/
B +1-778-819-UNIX
N While specialising in security, BackWatcher handles installation and
configuration, systems integration, performance tuning, disaster recovery,
network architecture, programming and general systems administration of
OpenBSD, NetBSD, FreeBSD, Dragonfly BSD, Linux and many commercial UNIX
flavors.

Thanks and Best Regards,

Kyle

--

  CA +1-778-819-UNIX  BackWatcher, Inc.
  US +1-425-584-UNIX  Information Security
SIPS am...@backwatcher.comwww.backwatcher.ca

 INUM +883-5100-0990-1657  |  ISN UNIX*1917  |  C*NET 1-731-UNIX

GPG ed25519/F57091DBD60FBBB8 [ed25519/D60FBBB8]
985C 5B61 4ACE C89A 0DEE  ECCD F570 91DB D60F BBB8

OTR E1A46361 9FD0D801 0132D21A FE2E96BE 39E3F069 : xmpp am...@backwatcher.com
5AB3E0B8 31F6ADB4 9A7D2FC2 A8235281 5776701E : silc silcnet

[demime 1.01d removed an attachment of type application/pgp-signature]

Re: Mouse click problems with firefox and firefox-esr

[Mihai Popescu]

It may be that your mouse it telling you it is dying.
Try it on a text file, out of firefox of course. Maybe there you can
see it misses the left click select or left click. It is a mechanical
contact after all.

Project: Creating an "immutable" OpenBSD disk image with Packer and Ansible

[Yann Hamon]

Hi,

I've been working for some time on a project to manage my router@home, 
I'm sharing it here in the hope that it will be useful to someone else.


Here it is: https://github.com/yannh/openbsd_immutable_router

It contains a set of configuration scripts for Packer and Ansible that 
make it easy to generate a disk image, that you can then copy to a USB 
stick to boot from.


To minimize writes to the USB stick, the root partition is mounted 
read-only, and all folders that require writes are mounted as MFS.


There is also some pf/dyndns/pppoe configuration that I left for 
learning purposes.


This workflow allows me to regenerate an image, or do a system upgrade, 
in about 20 minutes - packer build -var-file=config.json openbsd.json, 
dd if=output-qemu/openbsd of=/dev/sdb, reboot. I procrastinate less when 
doing my upgrades now :)


Regards,

Yann

Re: Supermicro X11SSL-F freezes probing USB 3

[Paul B. Henson]

On Wed, Mar 30, 2016 at 03:34:25PM -0400, Sonic wrote:

> Ahha! Who would have thought... com0 was the ticket. Thanks much!

Sweet, glad to hear you got it working. Usually the IPMI SOL comes after
the physical serial ports, I've never seen it be the first one. But hey,
it's Dell :).

Maybe now that 5.9 is out (a month early, nice, just in time for my new
box) one of the devs will have time to take a look at the skylake
usb 3 issues.

Re: Supermicro X11SSL-F freezes probing USB 3

[Paul B. Henson]

On Tue, Mar 29, 2016 at 10:46:15PM -0400, Sonic wrote:

> The IPMI is part of Dell's iDRAC stuff and the only thing I've found
[...]
> may be the iDRAC license level as well, anything above the "basic"
> level, providing a limited feature set, requires purchasing a license

Eeew. We've got some HP gear that requires an extra cost license to make
the remote kvm gui head work past the bootloader which is ridiculous
(but technically, I don't think remote kvm is part of the base IPMI
standard), but the IPMI SOL serial port??? That's just crazy. I've never
used Dell and never will for servers; desktops/notebooks, sure, but
servers? Nah. Sun gear was pretty good until Oracle killed them off, we
used IBM for a while until they sold it off to Lenovo and policy
wouldn't let us buy from a non-US company (like the gear itself doesn't
come from China anyway). Right now we're using HP at my dayjob and it's
working out ok. I pretty much use supermicro for personal gear and
sidejobs, it's generally good stuff. At least my IPMI SOL port works :).

Good luck :).