Re: Kernel memory leaking on Intel CPUs?

[SJP Lists]

On Friday, 5 January 2018, Rupert Gallagher  wrote:

> The Intel flop hits the US .mil as well,  because they depend on COTS
> Xeons.
>
> I pity the Russians. I wonder if they pay through the nose for Oracle's
> power hungry hardware, or make it cheaper and power efficient of their own.
>
> On Thu, Jan 4, 2018 at 18:28, Jordan Geoghegan 
> wrote:
>
> > The Russians heavily use SPARC for aerospace/military applications as
> well as their in house domestic-use-only Elbrus machines, for what I
> imagine to be reasons precisely like this.  @mail.com>


SPARC architecture is open to others to develop their own CPU designs.  The
Russians are not forced to buy SPARC from Oracle.

Re: gcc-4.9.4 package build signal 11 [Segmentation fault] on Ubiquiti Unifi Security Gateway

[Diana Eichert]

All I hear is crickets, so I guess the SDNA Shasta is not available to 
mortals.


I just rebuilt the OpenBSD build on my Ubiquiti USG with 5 GB swap.
Reminds me of running FreeBSD on 486 systems back in the 90's. ;-)
I have it building telephony/asterisk package, which has a LOT
of dependencies.

I just got my USG Pro at work.  I'm having fun opening it, the PH00
screws don't want to turn with my jeweler's screwdriver.  So I'm
going to try to find a PH00 bit for my impact screwdriver.

diana

On Tue, 2 Jan 2018, Jordan Geoghegan wrote:

I too have have tried contacting them, but with no response. Does anyone have 
any info on the Shasta or even the Edgerouter6 availability?


Jordan

Re: Community-driven OpenBSD tutorials wiki?

[Rodrigo Mosconi]

2018-01-04 12:17 GMT-02:00 Andreas Thulin :

> Hi all!
>
> Thought I'd create an OpenBSD wiki somewhere, where anyone (especially
> non-developers like myself) could create and edit tutorials for stuff
> non-developers like myself would find useful. I find that sometimes
> existing tutorials become outdated, and was thinking that a wiki would make
> updates easier.
>
> Before I go and create anything - are there already a place similar to what
> I'm describing, where I could get myself involved? (I'm too junior to start
> suggesting changes and updates to the docs on OpenBSD.org, and I'm not sure
> they should be used for what I want to achieve.)
>
> I know this comes out as yet another "let's start another project no one is
> asking for", but please be gentle with flaming me - I honestly want to
> contribute to the community to the extent of my abilities.
>
> Cheers,
> Andreas
>


OpenBSD already has a good faq, manpages and books.
Both the FAQ and manpages receives updates, even for non-developers as
patchs.
I remember that an list member provided an faq update because a change on
ifconfig.

IMHO, I think that there is no need for an wiki.  Just improve the FAQ
(that is plain
HTML!!!, no some sort of 'custom markdown'). Just send a patch.

Also the manpages are great, yesterday I used ypldap.conf(5) to setup a lab
to try to
make openbsd as a FreeIPA client (no flame war, please).  In fact, I only
used the
manpages for YP .  But I need info pages, pkg-readme, and some old article
of
kerberos from bsdmagazine to setup the kerberos part (that is not in base
anymore).

Some weeks ago, I used the manpages to setup an two-factor auth (ssh-key +
password).
On the same day, I used another manpage and pkg_readme to setup TOTP
passwords.
And on the login.conf(5) you can find how to use OTP+password to ssh in,
OTP to sudo and
password only to change own password (yes, it's an crazy setup, but I
learned how to do it)

Not OpenBSD related, but I learned a lot of perl just by using the tutorial
manpages, and I
still use some perl*tut to resolve some doubt.  At that time I was using
FreeBSD, and there
docs (handbook) are also a good source of information.  The chapter of BIND
DNS is very
good for a newbie sysadmin.

As I said, there is no need to create an wiki.  We, the users
non-developers, need to submit
the missing parts from the faq or manpages or some configuration to put in
/etc/examples.


Att,
Mosconi

Re: Video-conferencing tool a la Skype or Facetime for OpenBSD?

[Duncan Patton a Campbell]

On Thu, 4 Jan 2018 17:52:39 +0100
Marko Cupać  wrote:

> On Fri, 5 Jan 2018 00:18:12 +0900
> Bryan Linton  wrote:
> 
> > Hello misc@
> > 
> > I have a friend who runs Windows who has asked me if there is any
> > way we can occasionally communicate with each other via some kind 
> > of video-conferencing application similar to what programs like
> > Skype and Facetime provide.
> > 
> > Does such a thing already exist for OpenBSD?
> 
> Do you mean client software that connects from both Windows and
> OpenBSD to public videoconferencing services, or self-hosted
> videoconferencing server? I don't know about the former, but as for
> latter, I am testing two different approaches:
> - nextcloud with webrtc: [https://nextcloud.com/webrtc/]
> - matrix/synapse: [https://github.com/matrix-org/synapse]
> 
> Nextcloud with webrtc should work on OpenBSD. Matrix/Synapse has
> FreeBSD port, I don't know about OpenBSD.
> 
> Regards,
> -- 
Before enlightenment - chop wood, draw water.
After  enlightenment - draw water, have a drink, chop wood.

Dhu ;-)

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


-- 
 Je suis Canadien. Ce n'est pas Francais ou Anglaise.  
 C'est une esp`ece de sauvage: ne obliviscaris, vix ea nostra voco;-) 

http://babayaga.neotext.ca/PublicKeys/Duncan_Patton_a_Campbell_pubkey.txt

Re: Kernel memory leaking on Intel CPUs?

[torsten]

Ps
security.bsd.see_other_uids=0
security.bsd.see_other_gids=0
security.bsd.unprivileged_read_msgbuf=0
security.bsd.unprivileged_proc_debug=0
kern.randompid=$(jot -r 1 )
security.bsd.stack_guard_page=1


> -Original Message-
> From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf
> Of torsten
> Sent: 05 January 2018 00:59
> To: 'Rupert Gallagher'; 'Daniel Wilkins'; 'Allan Streib'
> Cc: 'Alceu R. de Freitas Jr.'; misc@openbsd.org
> Subject: Re: Kernel memory leaking on Intel CPUs?
> 
> I wonder how it is in reality for most *BSD users due to 1. hide
> processes run by other users 2. disable reading kernel messaging
> buffers...
> 3. disable kernel messaging debugging by unprivileged users
> 
> And some other tweeks
> 
> What surprises me is the "panic" publication of this because of already
> known and in *BSDs addressed concerns about hyper threatening and
> shared memory well back since 1994
> 
> 
> > -Original Message-
> > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On
> Behalf
> > Of Rupert Gallagher
> > Sent: 04 January 2018 22:22
> > To: Daniel Wilkins; Allan Streib
> > Cc: Alceu R. de Freitas Jr.; misc@openbsd.org
> > Subject: Re: Kernel memory leaking on Intel CPUs?
> >
> > https://mobile.twitter.com/misc0110/status/948706387491786752
> >
> > On Thu, Jan 4, 2018 at 16:49, Daniel Wilkins 
> > wrote:
> >
> > > Intel's said that it affects every processor in the last 20+ years
> > and that it's "not a big deal for most users" because it's only a
> > kernel memory *read*. @yahoo.com.br>

Re: Kernel memory leaking on Intel CPUs?

[torsten]

I wonder how it is in reality for most *BSD users due to 
1. hide processes run by other users
2. disable reading kernel messaging buffers...
3. disable kernel messaging debugging by unprivileged users

And some other tweeks

What surprises me is the "panic" publication of this because of already known 
and in *BSDs addressed concerns about hyper threatening and shared memory well 
back since 1994


> -Original Message-
> From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf
> Of Rupert Gallagher
> Sent: 04 January 2018 22:22
> To: Daniel Wilkins; Allan Streib
> Cc: Alceu R. de Freitas Jr.; misc@openbsd.org
> Subject: Re: Kernel memory leaking on Intel CPUs?
> 
> https://mobile.twitter.com/misc0110/status/948706387491786752
> 
> On Thu, Jan 4, 2018 at 16:49, Daniel Wilkins 
> wrote:
> 
> > Intel's said that it affects every processor in the last 20+ years
> and that it's "not a big deal for most users" because it's only a
> kernel memory *read*. @yahoo.com.br>

Re: Kernel memory leaking on Intel CPUs?

[Rupert Gallagher]

https://mobile.twitter.com/misc0110/status/948706387491786752

On Thu, Jan 4, 2018 at 16:49, Daniel Wilkins  wrote:

> Intel's said that it affects every processor in the last 20+ years and that 
> it's "not a big deal for most users" because it's only a kernel memory 
> *read*. @yahoo.com.br>

Re: Kernel memory leaking on Intel CPUs?

[Rupert Gallagher]

The Intel flop hits the US .mil as well,  because they depend on COTS Xeons.

I pity the Russians. I wonder if they pay through the nose for Oracle's power 
hungry hardware, or make it cheaper and power efficient of their own.

On Thu, Jan 4, 2018 at 18:28, Jordan Geoghegan  wrote:

> The Russians heavily use SPARC for aerospace/military applications as well as 
> their in house domestic-use-only Elbrus machines, for what I imagine to be 
> reasons precisely like this.  @mail.com>

Re: Community-driven OpenBSD tutorials wiki?

[Ve Telko]

Hi Andreas,

I installed OpenBSD on Oct. 16. 2017 after 18 years in Linux motivated by 
reading an article from Derek Sivers on OpenBSD 6.1/6.2

I started with reading FAQ and mailing lists (mostly tech and misc) history.
I also searched for some other articles on OpenBSD but I very soon 
understood, that there are very few and that this is absolutely another 
world, than Linux.

Now after several weeks I use Google only occasionally, I stopped using 
stackoverflow et. al. I'm just reading FAQ, man pages, dotfiles and gists
on Github and if I need to ask for help I ask people in OpenBSD Jumpstart 
group in Telegram or people on Twitter. They are very friendly
and willing to help with anything.

Don't spend your time or energy on something like Arch Linux wiki.

Ve.

Re: Community-driven OpenBSD tutorials wiki?

[Allan Streib]

andrew fabbro  writes:

> read the man pages, read the FAQ, read the source code

I have to say that I've found that in most cases the man pages and FAQ
will get you a long way. If you're a new arrival from the linux world,
used to googling for how-to blog posts, this will not be expected or
habitual. Try it, and you might be surprised.

Allan

Re: Kernel memory leaking on Intel CPUs?

[Mike Tancsa]

On 1/4/2018 10:51 AM, Daniel Boyd wrote:
> 
> AMD has said that it doesn't affect their processors. Whether or not
> that's true, I'm not sure.
> 
> One curiosity I had was whether the KARL mitigation in 6.2 would help
> with this. I suppose it depends on the nature of the flaw (which is
> still embargoed I assume).

Seems a lot of the details are out

https://meltdownattack.com/

---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/

Re: Community-driven OpenBSD tutorials wiki?

[Peter N. M. Hansteen]

On 01/04/18 15:17, Andreas Thulin wrote:

> Thought I'd create an OpenBSD wiki somewhere, where anyone (especially
> non-developers like myself) could create and edit tutorials for stuff
> non-developers like myself would find useful. I find that sometimes
> existing tutorials become outdated, and was thinking that a wiki would make
> updates easier.
> 
> Before I go and create anything - are there already a place similar to what
> I'm describing, where I could get myself involved? (I'm too junior to start
> suggesting changes and updates to the docs on OpenBSD.org, and I'm not sure
> they should be used for what I want to achieve.)

There have been several similar efforts, but unfortunately in almost all
of these cases apparently life has happened to the people involved and
maintenance stopped.

The main barrier here is not the choice of tools (although I must admit
that for a certain project requiring people to get the DSSSL toolchain
up in order to be able to hand over validated DocBook SGML may have been
setting a high-ish bar) or even how much you know about the subject at
hand when you start out. There are examples of good tech books that
started out as lab notes while learning a subject, for example.

If you think you don't have the seniority to start submitting patches
when you see a bug (even a typo in a man page or the faq), you're most
likely wrong. Your first efforts will not be perfect of course, but if
you put in the effort and are able to learn from constructive criticism,
it's likely sooner or later you will be adding real value.

That said, as others have pointed out already, articles, tutorials and
such can be very useful and making these materials I think should be
encouraged. Putting together material to share about a subject you care
about is great fun even if it takes som effort, and with a bit of luck
what you produce will be useful to others.

However, if you want the material to *stay* useful you will need to
commit time and effort to *maintain* it so it stays up to date and
relevant.

There are too many cases out there where some abandoned document is so
out of date that it's actively harmful or at least very confusing to a
newcomer. In these cases it would have been a lot more useful if the
material was simply deleted.

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: Community-driven OpenBSD tutorials wiki?

[andrew fabbro]

On Thu, Jan 4, 2018 at 3:21 PM, Chris Bennett <
webmas...@bennettconstruction.us> wrote:

> But before you get your hopes up, go check out the various worldwide
> community groups websites with similar attempts.
>
> Mexico, Russia, etc.
> You will find the same thing. Instructions for something to do with 5.7,
> all
> of which is no longer applicable do to the constant change in OpenBSD.
>

We should wait until OpenBSD is completely done before tutorials are
written :-)  Kidding...

The OpenBSD community has historically taken a different approach than That
Other Open Source OS Family, frowning on tutorials, wikis, blog howtos,
etc. in favor of saying "read the man pages, read the FAQ, read the source
code".  I suspect some of this comes from the incredible craftsmanship put
into those resources.  OpenBSD man pages are the best in the world, and I'd
defend them even against commercial Unixes.  They're the Sistine Chapel
ceiling of man pages.

So then to turn around and see howtos written by non-devs...it's kind of
like a chess book by a GM versus one by a 1100 player.  No one objects to
Michael Lucas's book because he's a fine writer.

Writing articles is not too difficult. Updating them, just doesn't happen.
> Seriously, will I really want to spend the time updating an article about
> something I now thoroughly understand and which has changed? Or would I
> really just prefer to watch the latest movie that looks good? It's just
> human
> nature.
>

The situation is rather different for OpenBSD vs. other FOSS.  Plenty of
people are still running Debian 7 or CentOS 5.  Those tutorials have
enduring value.  Relatively few people run OpenBSD from three or four
versions back (or at least, they shouldn't).  Debian 7 or Scientific Linux
6 or whatever is a branch with ongoing support and intended to be a lasting
product, whereas OpenBSD is always a moving target.  There are no "OpenBSD
LTS" versions.

So while I might legitimately consume a 5-year-old Linux tutorial and find
it's still very applicable if you're still on Debian 7, deploying, reading
and trying to use a 5-year-old OpenBSD tutorial would not be helpful.

Trying to form a community project outside just doesn't seem to work, sadly.
>
> But if you've got the desire to do something, then have at it. Just don't
> do
> a ton of hard work only to be disappointed.
>

I do think there's a gap between man pages/source code and practical
instructions on how to fix a problem or deploy a solution.  But the problem
you highlight is very real - things get out of date very fast.

Ultimately, this is like the thread recently on using something other than
CVS.  The onus is on the proposer to demonstrate value.

-- 
andrew fabbro
and...@fabbro.org

no video on resume

[Ed Brunelle]

Hi,

I just managed to setup OpenBSD on my system
(MSI mini itx with A8-7600 AMD APU, Kaveri)

I setup the apm with flag "-A" on /etc/rc.local.conf and apmd runs after
boot.
, the problem is that there is no video - same result under X or virtual
terminal even when no X was loaded- after the system resumes , its working,
as I can type -in "blind" mode- so I can reboot the system.
Do I need to setup any extra  params on conf files?

many thanks

ed

Re: Video-conferencing tool a la Skype or Facetime for OpenBSD?

[Mihai Popescu]

On OpenBSD side, install from packages:
pjsua (but no video, no GUI)
baresip (no GUI)

On Windows:
microsip

Both of you need one account each on iptel.org.

Re: Community-driven OpenBSD tutorials wiki?

[Nick Holland]

On 01/04/18 10:38, Marko Cupać wrote:
> Feel free to contribute to [!WARNING - BLATANT SELF PROMOTION BELOW!]
> 
> [https://www.mimar.rs/blog/tag:openbsd]
> 
> As a side note, setting up apache and grav [https://getgrav.org/] took
> me an hour or so. Writing simple article takes whole day, sometimes
> much more.

bingo.

I love wikis for internal documentation.  But the magic is not setting
up the wiki (or anything else for documenting), it's MAINTAINING it and
getting others to participate.

Sadly, as is proven almost daily on this list, even though it is trivial
to put crap on a website, people seem to get this idea that if it is
"found on the web, it must be true!".  People don't trust google with
their personal data, but if it shows up in a google search, it must be
"vetted" some how!  It must be good!  No.  Of course not.  And yet ...

As has been demonstrated in comments on this thread and in practice,
people tend to write stuff, toss it out on the 'net, and forget about
it.  This is a problem.  For something like Wikipedia, facts don't
usually change as much as they do get added to.  For an OS, things
actually change.  What is written today and is correct becomes WRONG
next week.  So everything out there has to be periodically scrubbed for
accuracy.  And that creates a problem -- what if the maintainers don't
actually know everything about everything, and the original author
wanders off and isn't responsive?  The obvious answer is delete the old
article ... but what if you don't even know if it needs update?  (maybe
the answer is auto-removing every document that is not updated once a year)

Could it work?  Yes.  But not because of a discussion on misc@, but
because of a lot of people choose to make it happen.

And then, there's the problem of getting groups of people to agree on
things.  For example, I looked at the first article on the mimar blog
here, and I disagree with the basic structure.  Too much duplication of
installation instructions, too much "do this", too little "here's why
I'm doing this".  There's some really great things in there, like the -P
command to populate the MFS file systems, without even commenting about
that nifty command people might not know about.  And then you have a
bunch of echos used to create a script.  boo.  Just provide the script
and say "copy/paste this into your editor", or better, "here's how I did
it", and assume if someone needs to be told to copy/paste into their
editor, they shouldn't.  Don't obscure the actual details with "echo ...
>>file" crap.  Now, if I'm on the administration team, do you 1) think
I'm an idiot and storm off?  2) make the changes I suggest and decide
this isn't fun and then wander off?  3) decide I'm brilliant and start
writing the "Nick Way"?  (hint: it won't be #3.  In this case,
hopefully, it would be #4: kick me off the administration team, since
it's YOUR server, not mine! :) )

Bonus points for actually doing it, though.

Nick.

Re: Kernel memory leaking on Intel CPUs?

[Daniel Boyd]

On Thu, 2018-01-04 at 10:21 -0500, Allan Streib wrote:
> "Alceu R. de Freitas Jr."  writes:
> 
> > I guess Intel does not give a shit about non-profit groups. Linux
> > got
> > this attention because there are a lot of players making money from
> > it, players that surely have some sort of partnership with Intel.
> 
> From what I have read in the past 24 hours, the spectre attacks are
> not
> limited to Intel CPUs, but in theory could affect any that use
> speculative execution (including, at least, modern ARM designs and
> AMD
> processors).
> 
> My uninformed take on this is that when you allow anyone in the world
> to
> run programs on your systems (i.e. JavaScript in browsers, "cloud"
> hosted virtual machines running on shared hardware, etc.) these sorts
> of
> things occasionally happen. No CPUs or software are perfectly secure.
> 
> Allan
> 
> 

AMD has said that it doesn't affect their processors. Whether or not
that's true, I'm not sure.

One curiosity I had was whether the KARL mitigation in 6.2 would help
with this. I suppose it depends on the nature of the flaw (which is
still embargoed I assume).

Re: Community-driven OpenBSD tutorials wiki?

[Thuban]

> Before I go and create anything - are there already a place similar to what
> I'm describing, where I could get myself involved? (I'm too junior to start
> suggesting changes and updates to the docs on OpenBSD.org, and I'm not sure
> they should be used for what I want to achieve.)

yes, see here : https://wiki.obsd4a.net/doku.php

It's mainly in french, but I don't know what is your favourite language.

regards
-- 
thuban


signature.asc
Description: PGP signature

Re: Community-driven OpenBSD tutorials wiki?

[Daniel Ouellet]

On 1/4/18 11:46 AM, Marcus MERIGHI wrote:
> andreasthu...@gmail.com (Andreas Thulin), 2018.01.04 (Thu) 15:17 (CET):
>> Thought I'd create an OpenBSD wiki somewhere, where anyone (especially
> 
>> existing tutorials become outdated, and was thinking that a wiki would
>> make updates easier.  
> 
> You don't know you are standing on an ancient battle ground :-)
> 
> https://marc.info/?l=openbsd-misc=141611711607893

This is NOT officially bless and it is old as the site say this is for
the community to do it, but I did that in 2004 after I was fed up with
all these comments that it should be done.

https://marc.info/?l=openbsd-misc=110029083800034=2

I thought to delete it for many years now but that was an exercise in
shut up and hack mentality.

Only 2 person step in 15 years to do anything and they did it may be 3
or 4 times.

The site is total SHIT!!!

But it is there is show how useless all these comments are as talks is
cheap, but doing the work, not so much.

> I dare to forecast the answer: 
> If there's a lack of documentation, improve it in-place, send patches.

Obviously that wasn't a wiki, 15 years is a long time but it's proven
the point everyone talks and no one does the work.

> Do not expect anyone to be grateful if you put information out on the
> web and misc@ gets the spam because your four year old examples do not
> work anymore.

Amen. misc@ get a lots of crap and frankly I must admit the devs have a
very think skin to take all the sad comments you see on it.

I thought many times to delete the site, just kept it for the joke if it
I guess.

But if anyone was actually serious and I really don;t think anyone is
yet after 15 years then it could be changed.

I would be more then happy to redo it and host it like this at Equinix
in Ashburn Virginia where I have over 125 network peering connections so
connectivity is not the issue, doing the work is.

If anyone comes with a decent setup that work, I would be more then
happy to find it a home and even give some restricted shell access to
that person/persons if that's actually serious.

But experience has proven it time and time again when the subject come
up, it will die soon.

Going back under my rock...

Re: Kernel memory leaking on Intel CPUs?

[Jordan Geoghegan]

The Russians heavily use SPARC for aerospace/military applications as 
well as their in house domestic-use-only Elbrus machines, for what I 
imagine to be reasons precisely like this.



On 01/04/18 00:13, Rupert Gallagher wrote:

Everybody is reading about it, including people like me that have formerly 
underestimated the problem... mea culpa

The question is, can we have a kernel free of patches for spynet cpus? The 
Russians are moving to ARM-based cpus, anthough ARM is subject to UK-style 
Orwellian spynet law. The Chinese have an interesting project on RISC, who is 
taking ages to hit the market.

Sent from ProtonMail Mobile

On Wed, Jan 3, 2018 at 13:19, who one  wrote:


Did anyone hear about this?

Re: Community-driven OpenBSD tutorials wiki?

[Chris Bennett]

On Thu, Jan 04, 2018 at 02:17:51PM +, Andreas Thulin wrote:
> Hi all!
> 
> Thought I'd create an OpenBSD wiki somewhere, where anyone (especially
> non-developers like myself) could create and edit tutorials for stuff
> non-developers like myself would find useful. I find that sometimes
> existing tutorials become outdated, and was thinking that a wiki would make
> updates easier.
> 
> Before I go and create anything - are there already a place similar to what
> I'm describing, where I could get myself involved? (I'm too junior to start
> suggesting changes and updates to the docs on OpenBSD.org, and I'm not sure
> they should be used for what I want to achieve.)
> 
> I know this comes out as yet another "let's start another project no one is
> asking for", but please be gentle with flaming me - I honestly want to
> contribute to the community to the extent of my abilities.
> 
> Cheers,
> Andreas

Your idea, at first glance, sounds like a wonderful thing. Genuinely.

But before you get your hopes up, go check out the various worldwide
community groups websites with similar attempts.

Mexico, Russia, etc.
You will find the same thing. Instructions for something to do with 5.7, all
of which is no longer applicable do to the constant change in OpenBSD.

Writing articles is not too difficult. Updating them, just doesn't happen.
Seriously, will I really want to spend the time updating an article about
something I now thoroughly understand and which has changed? Or would I
really just prefer to watch the latest movie that looks good? It's just human
nature.

If you really want to see something kept up to date, it really needs to be
within the tree of the system. As changes happen (or happened a long time ago)
the manual pages don't always reflect reality well. I would put some effort
into that. If you see something in a manual page that is just beyond you, ask
about that and see if you can write a diff to make things more clear. I find
that some manual pages would be really more helpful with just one or two
examples added. Trust me, there are many manual pages with flaws. You are
naturally going to read every manual page for all of the commands within
/bin and /sbin, right?

Trying to form a community project outside just doesn't seem to work, sadly.

But if you've got the desire to do something, then have at it. Just don't do
a ton of hard work only to be disappointed.

Have fun,
Chris Bennett

Re: Kernel memory leaking on Intel CPUs?

[Daniel Boyd]

On Thu, 2018-01-04 at 10:49 -0500, Daniel Wilkins wrote:
> On Thu, Jan 04, 2018 at 10:21:12AM -0500, Allan Streib wrote:
> > "Alceu R. de Freitas Jr."  writes:
> > 
> > > I guess Intel does not give a shit about non-profit groups. Linux
> > > got
> > > this attention because there are a lot of players making money
> > > from
> > > it, players that surely have some sort of partnership with Intel.
> > 
> > From what I have read in the past 24 hours, the spectre attacks are
> > not
> > limited to Intel CPUs, but in theory could affect any that use
> > speculative execution (including, at least, modern ARM designs and
> > AMD
> > processors).
> > 
> > My uninformed take on this is that when you allow anyone in the
> > world to
> > run programs on your systems (i.e. JavaScript in browsers, "cloud"
> > hosted virtual machines running on shared hardware, etc.) these
> > sorts of
> > things occasionally happen. No CPUs or software are perfectly
> > secure.
> > 
> > Allan
> > 
> 
> From what I understand, AMD has come out and explicitly said that
> their
> architecture isn't and has never been vulnerable, while Intel's said
> that
> it affects every processor in the last 20+ years and that it's "not a
> big
> deal for most users" because it's only a kernel memory *read*.
> 
> 

I'm admittedly not an expert on all things kernel, but allowing user
space programs to read kernel space memory seems ... bad.  Read/write
would be worse, granted

Re: Video-conferencing tool a la Skype or Facetime for OpenBSD?

[Marko Cupać]

On Fri, 5 Jan 2018 00:18:12 +0900
Bryan Linton  wrote:

> Hello misc@
> 
> I have a friend who runs Windows who has asked me if there is any
> way we can occasionally communicate with each other via some kind 
> of video-conferencing application similar to what programs like
> Skype and Facetime provide.
> 
> Does such a thing already exist for OpenBSD?

Do you mean client software that connects from both Windows and
OpenBSD to public videoconferencing services, or self-hosted
videoconferencing server? I don't know about the former, but as for
latter, I am testing two different approaches:
- nextcloud with webrtc: [https://nextcloud.com/webrtc/]
- matrix/synapse: [https://github.com/matrix-org/synapse]

Nextcloud with webrtc should work on OpenBSD. Matrix/Synapse has
FreeBSD port, I don't know about OpenBSD.

Regards,
-- 
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

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

Re: Community-driven OpenBSD tutorials wiki?

[Marcus MERIGHI]

andreasthu...@gmail.com (Andreas Thulin), 2018.01.04 (Thu) 15:17 (CET):
> Thought I'd create an OpenBSD wiki somewhere, where anyone (especially

> existing tutorials become outdated, and was thinking that a wiki would
> make updates easier.  

You don't know you are standing on an ancient battle ground :-)

https://marc.info/?l=openbsd-misc=141611711607893
https://marc.info/?l=openbsd-misc=2=3=calomel

I dare to forecast the answer: 
If there's a lack of documentation, improve it in-place, send patches.

Do not expect anyone to be grateful if you put information out on the
web and misc@ gets the spam because your four year old examples do not
work anymore.

Marcus

Re: Community-driven OpenBSD tutorials wiki?

[Marko Cupać]

On Thu, 4 Jan 2018 09:13:58 -0700
Base Pr1me  wrote:

> The Pledge of the Network Admin, from one of those book authors:
> http://bsdly.blogspot.com/2011/01/i-will-not-mindlessly-paste-from-howtos.html
> :D

I found this pledge quite early, and it instantly became my pledge as
well. But I think the significant word here is "mindlessly". Pasting
from howtos is not bad per se, in my opinion, as long as you gradually
get to understand what you pasted.
-- 
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

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

Video-conferencing tool a la Skype or Facetime for OpenBSD?

[Bryan Linton]

Hello misc@

I have a friend who runs Windows who has asked me if there is any
way we can occasionally communicate with each other via some kind 
of video-conferencing application similar to what programs like
Skype and Facetime provide.

Does such a thing already exist for OpenBSD?

My requirements are fairly simple:
1) Must be usable between OpenBSD and Windows.
2) Must transmit/receive audio and video from a webcam.
3) Should be as point-and-click (on the Windows side) as possible.
4) Bonus points if it contains a text-based chatting feature.

For number 3, I can drive over to my friend's house and do a one-time
setup of anything highly technical, but after that, it should be as
simple for them as possible.  They're moderately technically inclined,
so entering a server/port/etc. is well within their means, but configuring
port-forwarding in their firewall and the like is something I'd have to
do myself.

Looking through the ports tree, I see a few programs that look promising,
like telephony/baresip but I don't see anything like Ekiga or Empathy.

Before I put the effort in to trying to get something working, I thought
it'd be prudent to ask the list if such a thing is even feasable first.

Any pointers (even a, "No, this isn't possible yet with OpenBSD <-> Windows")
would be appreciated.

Thank you!

-- 
Bryan

Re: Community-driven OpenBSD tutorials wiki?

[Base Pr1me]

The Pledge of the Network Admin, from one of those book authors:
http://bsdly.blogspot.com/2011/01/i-will-not-mindlessly-paste-from-howtos.html
:D

On Thu, Jan 4, 2018 at 9:02 AM, Marko Cupać  wrote:

> On Thu, 4 Jan 2018 10:41:19 -0500
> Bryan Harris  wrote:
>
> > My preference is to purchase a book. I have had a good experience with
> > Absolute OpenBSD, Httpd & Relayd, the tarsnap book, and the Book of
> > PF.
> >
> > I would buy a book about OpenSMTPD and also ikev2 but I didn't see
> > any.
> >
> > Just my $0.02, I like books better than online tutorials.
>
> Couldn't agree more. Those are good books.
>
> However, back in a day when I was completely fresh to OpenBSD, I
> preferred to copy/paste someone's working solution, and then discover
> which config line does what, how, and why. That's because I had no
> clue about anything. It was valuable to read how people designed
> solutions to their needs, what combination of software they used etc.
> Only at the later stage I was able to dive into documentation.
>
> I was particularly fond of this set of howtos:
> http://www.kernel-panic.it/openbsd.html
> --
> Before enlightenment - chop wood, draw water.
> After  enlightenment - chop wood, draw water.
>
> Marko Cupać
> https://www.mimar.rs/
>
>

Re: Kernel memory leaking on Intel CPUs?

[Raul Miller]

On Thu, Jan 4, 2018 at 10:49 AM, Daniel Wilkins  wrote:
> From what I understand, AMD has come out and explicitly said that their
> architecture isn't and has never been vulnerable, while Intel's said that
> it affects every processor in the last 20+ years and that it's "not a big
> deal for most users" because it's only a kernel memory *read*.

I think you should interpret this as saying that there is a part of
that specific exploit implementation which AMD cpus have not
implemented.

But keep in mind, also, that the exploit involves multiple hardware
components (not only sloppy cpu instruction scheduling but shoddy
power management interacting with cheap dynamic ram refresh).

Of course, I have also misused my adjectives here. The cpu scheduling
is just wonderful, the power management is professional and the memory
implementation is beyond high tech. Sales people are omniscient and
thus have good reason for ... ah, ... never mind. I'm going to go
crawl back under my rock.

Good luck,

-- 
Raul

Re: Community-driven OpenBSD tutorials wiki?

[Oliver Marugg]

Hi

In general an community driven openbsd wiki would be a good idea, for 
users like me (not developers). I would participate as far I am able to. 
But do not forget the OpenBSD FAQ and man pages are really well 
documented (thanks devs).

-oliver

On 4 Jan 2018, at 15:17, Andreas Thulin wrote:


Hi all!

Thought I'd create an OpenBSD wiki somewhere, where anyone (especially
non-developers like myself) could create and edit tutorials for stuff
non-developers like myself would find useful. I find that sometimes
existing tutorials become outdated, and was thinking that a wiki would 
make

updates easier.

Before I go and create anything - are there already a place similar to 
what
I'm describing, where I could get myself involved? (I'm too junior to 
start
suggesting changes and updates to the docs on OpenBSD.org, and I'm not 
sure

they should be used for what I want to achieve.)

I know this comes out as yet another "let's start another project no 
one is

asking for", but please be gentle with flaming me - I honestly want to
contribute to the community to the extent of my abilities.

Cheers,
Andreas

Re: Community-driven OpenBSD tutorials wiki?

[Marko Cupać]

On Thu, 4 Jan 2018 10:41:19 -0500
Bryan Harris  wrote:

> My preference is to purchase a book. I have had a good experience with
> Absolute OpenBSD, Httpd & Relayd, the tarsnap book, and the Book of
> PF.
>
> I would buy a book about OpenSMTPD and also ikev2 but I didn't see
> any.
> 
> Just my $0.02, I like books better than online tutorials.

Couldn't agree more. Those are good books.

However, back in a day when I was completely fresh to OpenBSD, I
preferred to copy/paste someone's working solution, and then discover
which config line does what, how, and why. That's because I had no
clue about anything. It was valuable to read how people designed
solutions to their needs, what combination of software they used etc.
Only at the later stage I was able to dive into documentation.

I was particularly fond of this set of howtos:
http://www.kernel-panic.it/openbsd.html
-- 
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

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

Re: Kernel memory leaking on Intel CPUs?

[Daniel Wilkins]

On Thu, Jan 04, 2018 at 10:21:12AM -0500, Allan Streib wrote:
> "Alceu R. de Freitas Jr."  writes:
> 
> > I guess Intel does not give a shit about non-profit groups. Linux got
> > this attention because there are a lot of players making money from
> > it, players that surely have some sort of partnership with Intel.
> 
> From what I have read in the past 24 hours, the spectre attacks are not
> limited to Intel CPUs, but in theory could affect any that use
> speculative execution (including, at least, modern ARM designs and AMD
> processors).
> 
> My uninformed take on this is that when you allow anyone in the world to
> run programs on your systems (i.e. JavaScript in browsers, "cloud"
> hosted virtual machines running on shared hardware, etc.) these sorts of
> things occasionally happen. No CPUs or software are perfectly secure.
> 
> Allan
> 

>From what I understand, AMD has come out and explicitly said that their
architecture isn't and has never been vulnerable, while Intel's said that
it affects every processor in the last 20+ years and that it's "not a big
deal for most users" because it's only a kernel memory *read*.

Re: fsck block number integer overflow

[Otto Moerbeek]

On Thu, Jan 04, 2018 at 02:53:31PM +0100, Otto Moerbeek wrote:

> On Thu, Jan 04, 2018 at 09:11:04AM +0100, Otto Moerbeek wrote:
> 
> > On Wed, Jan 03, 2018 at 09:44:55PM -0600, Colton Lewis wrote:
> > 
> > > When I try to run fsck on partition m of this disk:
> > > 
> > > # /dev/rsd1c:
> > > type: SCSI
> > > disk: SCSI disk
> > > label: TOSHIBA MD04ACA4
> > > duid: 8ad0895bc1395d21
> > > flags:
> > > bytes/sector: 512
> > > sectors/track: 63
> > > tracks/cylinder: 255
> > > sectors/cylinder: 16065
> > > cylinders: 486401
> > > total sectors: 7814037168
> > > boundstart: 262208
> > > boundend: 7814037168
> > > drivedata: 0
> > > 
> > > 16 partitions:
> > > #size   offset  fstype [fsize bsize   cpg]
> > >   a:  1136000   262208  4.2BSD   2048 16384  8875
> > >   b:  1821490  1398208swap
> > >   c:   78140371680  unused
> > >   d:  1571840  3219712  4.2BSD   2048 16384 12280
> > >   e:  2318784  4791552  4.2BSD   2048 16384 12958
> > >   f:  2672000  7110336  4.2BSD   2048 16384 12958
> > >   g:  1545856  9782336  4.2BSD   2048 16384 12077
> > >   h:  4944064 11328192  4.2BSD   2048 16384 12958
> > >   i:   262144   64   MSDOS
> > >   j:  2428672 16272256  4.2BSD   2048 16384 12958
> > >   k:  6954496 18700928  4.2BSD   2048 16384 12958
> > >   l:  7898912 25655424  4.2BSD   2048 16384 12958
> > >   m:   7780482560 33554560  4.2BSD   8192 65536 1
> > > 
> > > fsck reports that it cannot read negative block numbers:
> > > 
> > > ** /dev/rsd1m
> > > BAD SUPER BLOCK: MAGIC NUMBER WRONG
> > > 
> > > LOOK FOR ALTERNATE SUPERBLOCKS? yes
> > > 
> > > 
> > > CANNOT READ: BLK 749213312
> > > CONTINUE? yes
> > > 
> > > THE FOLLOWING DISK SECTORS COULD NOT BE READ: 749213312, 749213313,
> > > 749213314, 749213315, 749213316, 749213317, 749213318, 749213319,
> > > 
> > > CANNOT READ: BLK -2147483648
> > > CONTINUE? yes
> > > 
> > > THE FOLLOWING DISK SECTORS COULD NOT BE READ: -2147483648,
> > > -2147483647, -2147483646, -2147483645, -2147483644, -2147483643,
> > > -2147483642, -2147483641, -2147483640, -2147483639, -2147483638,
> > > -2147483637, -2147483636, -2147483635, -2147483634, -2147483633,
> > > 
> > > ...
> > > 
> > > How can I make sure fsck can handle a partition this size? There is
> > > nothing important on there at the moment.
> > > 
> > > -- 
> > > Sincerely,
> > > Colton Lewis
> > 
> > Did you actually newfs that partition? It looks like not since no
> > superblock or alternative is found. 
> > 
> > That said, it looks like there's an overflow somehere. I do not have
> > the hardware to investigate this though.
> > 
> > On a side note: a partition that large will cause problem in other
> > areas. Even if it would work, the memory needed to do an fsck will be
> > huge.
> > 
> > Also: provide dmeg! The platform involved can play a role in this.
> > 
> > -Otto
> 
> I tried to reproduce your problem using a vnd image using a sparse
> file.
> 
> If I do not newfs the device, I get results very similar to what you
> are seeing. 
> 
> If I newfs the partition first, an fsck -f works as expected. So without
> further information, I assume you did not run newfs.
> 
> I'll invetstigate the negative block numbers.
> 
>   -Otto

THis diff should fixes the negative blocknumbers here,

-Otto

Index: fsck.h
===
RCS file: /cvs/src/sbin/fsck_ffs/fsck.h,v
retrieving revision 1.31
diff -u -p -r1.31 fsck.h
--- fsck.h  19 Jan 2015 18:20:47 -  1.31
+++ fsck.h  4 Jan 2018 15:46:37 -
@@ -229,7 +229,7 @@ extern long numdirs, listmax, inplast;
 long   secsize;/* actual disk sector size */
 char   nflag;  /* assume a no response */
 char   yflag;  /* assume a yes response */
-intbflag;  /* location of alternate super block */
+daddr_tbflag;  /* location of alternate super block */
 intdebug;  /* output debugging info */
 intcvtlevel;   /* convert to newer file system format */
 charusedsoftdep;/* just fix soft dependency inconsistencies */
Index: main.c
===
RCS file: /cvs/src/sbin/fsck_ffs/main.c,v
retrieving revision 1.50
diff -u -p -r1.50 main.c
--- main.c  9 Sep 2016 15:37:15 -   1.50
+++ main.c  4 Jan 2018 15:46:37 -
@@ -48,7 +48,7 @@
 
 volatile sig_atomic_t returntosingle;
 
-intargtoi(int, char *, char *, int);
+long long argtoi(int, char *, char *, int);
 intcheckfilesys(char *, char *, long, int);
 intmain(int, char *[]);
 
@@ -78,7 +78,8 @@ main(int argc, char *argv[])
case 'b':
skipclean = 0;
  

Re: Kernel memory leaking on Intel CPUs?

[Tom Smyth]

Hello Daniel,

I don't know as Im not a core developer... the Vuln was embargoed  so my guess
is a lot of people were in the dark.

Thanks
Tom Smyth

On 4 January 2018 at 13:31, Daniel Boyd  wrote:
> On Jan 4, 2018, at 5:43 AM, Tom Smyth  wrote:
>>
>> sorry all,
>>
>> I had posted to the tech mailing list about this .. I came across these 2
>> papers and they may be of interest about the CPU Security flaws
>>
>> https://spectreattack.com/
>>
>> I hope this helps
>> Tom Smyth
>>
>
> Were the BSDs given advanced notice of this like MS, Apple, and Linux...?

Re: Community-driven OpenBSD tutorials wiki?

[Bryan Harris]

My preference is to purchase a book. I have had a good experience with
Absolute OpenBSD, Httpd & Relayd, the tarsnap book, and the Book of PF.

I would buy a book about OpenSMTPD and also ikev2 but I didn't see any.

Just my $0.02, I like books better than online tutorials.

V/r,
Bryan

On Thu, Jan 4, 2018 at 10:38 AM, Marko Cupać  wrote:

> Feel free to contribute to [!WARNING - BLATANT SELF PROMOTION BELOW!]
>
> [https://www.mimar.rs/blog/tag:openbsd]
>
> As a side note, setting up apache and grav [https://getgrav.org/] took
> me an hour or so. Writing simple article takes whole day, sometimes
> much more.
> --
> Before enlightenment - chop wood, draw water.
> After  enlightenment - chop wood, draw water.
>
> Marko Cupać
> https://www.mimar.rs/
>
>

Re: Community-driven OpenBSD tutorials wiki?

[Marko Cupać]

Feel free to contribute to [!WARNING - BLATANT SELF PROMOTION BELOW!]

[https://www.mimar.rs/blog/tag:openbsd]

As a side note, setting up apache and grav [https://getgrav.org/] took
me an hour or so. Writing simple article takes whole day, sometimes
much more.
-- 
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

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

Re: Community-driven OpenBSD tutorials wiki?

[edgar]

On Jan 4, 2018 9:27 AM, Lea Chescotta  wrote:
>
> Hi Andreas! Personally I really like the idea, i used Arch Linux for
> several years and i always liked way the Arch Wiki was always updated
> and containing a lot of useful data, that (i know) it's always 
> available in the manual pages with a lot of more useful data, 
> but i think it's useful to have like a brief description and usage of
> the system and tools that one can then complement with the manual 
> pages if needed.
>
> I writed a lot of small text files that i use for different tasks,
> from video conversion and edition with ffmpeg, to system administration
> of different operating systems, including OpenBSD that is the system
> Im using in my personal computer for the last couple of months and that
> I really love.
>
> If you want i can share with you the text files relevant to the 
> installation and usage of OpenBSD that i had for personal use for you
> to see if something in them is suitable for your endeavour, they cover
> installation and updating processes, mainly for the stable branch that
> I installed and maintain in my computer, even the installation in an
> full encrypted disk, and basic setup of the environment and tools usage.
>
> Thanks for the initiative!
>
> ​
>
> ​
>
> > Original Message 
> >Subject: Re: Community-driven OpenBSD tutorials wiki?
> >Local Time: January 4, 2018 11:50 AM
> >UTC Time: January 4, 2018 2:50 PM
> >From: n...@nawi.is
> >To: Andreas Thulin 
> >misc@openbsd.org 
> >
> >Hello !
> >
> >No need for flame or complain or something.
> >
> >What I can remember, there is a German wiki at http://wiki.bsdforen.de
> >and posts at http://bsdnow.tv booth are not up to date. And, what you
> >find using your prefered search engine. But OpenBSD only - extreme
> >seldom.
> >
> >If it is useful for YOU and, YOU want it - do it.
> >
> >IMHO I would start it, provide maybe here a table of contents if you
> >didn't start already something and, I would call for / handle that off
> >list.
> >
> >Regards,
> >
> >Christoph
> >
> >
> >
> >>Hi all!
> >>Thought I'd create an OpenBSD wiki somewhere, where anyone (especially
> >>non-developers like myself) could create and edit tutorials for stuff
> >>non-developers like myself would find useful. I find that sometimes
> >>existing tutorials become outdated, and was thinking that a wiki would
> >>make
> >>updates easier.
> >>Before I go and create anything - are there already a place similar to
> >>what
> >>I'm describing, where I could get myself involved? (I'm too junior to
> >>start
> >>suggesting changes and updates to the docs on OpenBSD.org, and I'm not
> >>sure
> >>they should be used for what I want to achieve.)
> >>I know this comes out as yet another "let's start another project no
> >>one is
> >>asking for", but please be gentle with flaming me - I honestly want to
> >>contribute to the community to the extent of my abilities.
> >>Cheers,
> >>Andreas
> >>
> >
>


I feel that the FAQ section covers 90% of use cases fairly well. I would 
recommend focusing on the more in depth issues that aren't. However I do like 
the idea.

Re: Simplifying pf-rules

[Marko Cupać]

On Thu, 4 Jan 2018 14:09:50 +0100
Jon S  wrote:

> Hello misc!
> 
> My OpenBSD file server just became a router too (after getting a new
> internet connection where the provider does not include a router in
> the subscription).

If possible, I'd avoid combining file server and firewall services on
single box.

> This led to my first experieces with pf. After some work I came up
> with whats below. It works as I want it to work, but I wonder if
> there is a way to create a rule where incomming traffic to the
> internal NIC (re0) is passed if it is targeted for em0 (external,
> internet NIC)? The current solution would require an update of the
> "pass in on re0 to !re0:network"-rule if another NIC is added (lets
> say a DMZ).

All my pf rulesets start with defining interface macros so they are
more readable, and also more flexible (this way changing NIC with
different driver needs one line changed, instead of all lines in the
ruleset referencing that interface):

# INTERFACE MACROS
if_int = "re0"
if_ext = "em0"

> set skip on lo0
> 
> # Block everything everywhere by default
> block log all

I prefer to put "match" section above default "block log all" rule.
It's more logical to me, as something being "matched" has no impact if
it's not "passed" or "blocked" later on in the ruleset.

> # NAT local network to external
> match out on em0 inet from re0:network nat-to (em0)
> 
> # Allow all outgoing traffic
> pass out on {em0, re0}
> 
> # Allow only specific services on this machine to be accessed from
> # local network
> pass in on re0 inet proto tcp to port ssh # ssh
> pass in on re0 inet proto icmp# icmp
> pass in on re0 inet proto tcp to port 445 # samba

Your description line does not describe accurately what next three
lines do - as destination IP is not present, "to any" is assumed, so
more accurate description would be "Allow specific services on any
machine be accessed from local network".

If you wanted your ruleset to match description line, and your
services listen on internal NIC, you would do something like:

pass in on $if_int inet proto tcp  from re0:network to re0 port ssh
pass in on $if_int inet proto icmp from re0:network to re0
pass in on $if_int inet proto tcp  from re0:network to re0 port 445

> 
> #pass in on re0 inet to em0:network # This does not work, since the
> #mask for this IF will only let traffic through to the limitied set of
> #IPs on the same C-segment as em0. That would probably be a set of
> #other customers at the nework operator...
> 
> # This works, but will require an update if any furter NIC is involved
> # later
> pass in on re0 to !re0:network

There are multiple ways to achieve this. One of them would be passing
everything on $if_int, and blocking what you don't want later (if
"quick" keyword is not used, last matching rule wins):

pass in on $if_int
block in on $if_int inet proto tcp from $if_int:network to \
  $if_int port { !=ssh !=445 }

The other one would be blocking unwanted stuff quickly early in the
ruleset, and passing what you want later on:

block in quick on $if_int inet proto tcp from $if_int:network to \
  $if_int port { !=ssh !=445 }
pass in on $if_int

Both examples block only TCP to internal NIC, so blocking other
protocols if there are any on the firewall also needs to be done.
> 
> # I would like something like this to work, so that future added NICs
> # wont open new unwanted paths
> #pass in on re0 to em0
> 
> # Allow only incomming SSH to external NIC
> pass in on em0 inet proto tcp to port ssh

In the end, your ruleset seems quite minimal. I suggest you start
worrying about new NIC once you add it. For now it would be better to
play around with pfctl -vvsr, systat states/rules, tcpdumping pflog etc.

Hope this helps,

-- 
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

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

Re: Community-driven OpenBSD tutorials wiki?

[Lea Chescotta]

Hi Andreas! Personally I really like the idea, i used Arch Linux for
several years and i always liked way the Arch Wiki was always updated
and containing a lot of useful data, that (i know) it's always 
available in the manual pages with a lot of more useful data, 
but i think it's useful to have like a brief description and usage of
the system and tools that one can then complement with the manual 
pages if needed.

I writed a lot of small text files that i use for different tasks,
from video conversion and edition with ffmpeg, to system administration
of different operating systems, including OpenBSD that is the system
Im using in my personal computer for the last couple of months and that
I really love.

If you want i can share with you the text files relevant to the 
installation and usage of OpenBSD that i had for personal use for you
to see if something in them is suitable for your endeavour, they cover
installation and updating processes, mainly for the stable branch that
I installed and maintain in my computer, even the installation in an
full encrypted disk, and basic setup of the environment and tools usage.

Thanks for the initiative!

​

​

> Original Message 
>Subject: Re: Community-driven OpenBSD tutorials wiki?
>Local Time: January 4, 2018 11:50 AM
>UTC Time: January 4, 2018 2:50 PM
>From: n...@nawi.is
>To: Andreas Thulin 
>misc@openbsd.org 
>
>Hello !
>
>No need for flame or complain or something.
>
>What I can remember, there is a German wiki at http://wiki.bsdforen.de
>and posts at http://bsdnow.tv booth are not up to date. And, what you
>find using your prefered search engine. But OpenBSD only - extreme
>seldom.
>
>If it is useful for YOU and, YOU want it - do it.
>
>IMHO I would start it, provide maybe here a table of contents if you
>didn't start already something and, I would call for / handle that off
>list.
>
>Regards,
>
>Christoph
>
>
>
>>Hi all!
>>Thought I'd create an OpenBSD wiki somewhere, where anyone (especially
>>non-developers like myself) could create and edit tutorials for stuff
>>non-developers like myself would find useful. I find that sometimes
>>existing tutorials become outdated, and was thinking that a wiki would
>>make
>>updates easier.
>>Before I go and create anything - are there already a place similar to
>>what
>>I'm describing, where I could get myself involved? (I'm too junior to
>>start
>>suggesting changes and updates to the docs on OpenBSD.org, and I'm not
>>sure
>>they should be used for what I want to achieve.)
>>I know this comes out as yet another "let's start another project no
>>one is
>>asking for", but please be gentle with flaming me - I honestly want to
>>contribute to the community to the extent of my abilities.
>>Cheers,
>>Andreas
>>
>

Re: Kernel memory leaking on Intel CPUs?

[Allan Streib]

"Alceu R. de Freitas Jr."  writes:

> I guess Intel does not give a shit about non-profit groups. Linux got
> this attention because there are a lot of players making money from
> it, players that surely have some sort of partnership with Intel.

>From what I have read in the past 24 hours, the spectre attacks are not
limited to Intel CPUs, but in theory could affect any that use
speculative execution (including, at least, modern ARM designs and AMD
processors).

My uninformed take on this is that when you allow anyone in the world to
run programs on your systems (i.e. JavaScript in browsers, "cloud"
hosted virtual machines running on shared hardware, etc.) these sorts of
things occasionally happen. No CPUs or software are perfectly secure.

Allan

Re: Community-driven OpenBSD tutorials wiki?

[Christoph R. Murauer]

Hello !

No need for flame or complain or something.

What I can remember, there is a German wiki at http://wiki.bsdforen.de
and posts at http://bsdnow.tv booth are not up to date. And, what you
find using your prefered search engine. But OpenBSD only - extreme
seldom.

If it is useful for YOU and, YOU want it - do it.

IMHO I would start it, provide maybe here a table of contents if you
didn't start already something and, I would call for / handle that off
list.

Regards,

Christoph



> Hi all!
>
> Thought I'd create an OpenBSD wiki somewhere, where anyone (especially
> non-developers like myself) could create and edit tutorials for stuff
> non-developers like myself would find useful. I find that sometimes
> existing tutorials become outdated, and was thinking that a wiki would
> make
> updates easier.
>
> Before I go and create anything - are there already a place similar to
> what
> I'm describing, where I could get myself involved? (I'm too junior to
> start
> suggesting changes and updates to the docs on OpenBSD.org, and I'm not
> sure
> they should be used for what I want to achieve.)
>
> I know this comes out as yet another "let's start another project no
> one is
> asking for", but please be gentle with flaming me - I honestly want to
> contribute to the community to the extent of my abilities.
>
> Cheers,
> Andreas
>

Community-driven OpenBSD tutorials wiki?

[Andreas Thulin]

Hi all!

Thought I'd create an OpenBSD wiki somewhere, where anyone (especially
non-developers like myself) could create and edit tutorials for stuff
non-developers like myself would find useful. I find that sometimes
existing tutorials become outdated, and was thinking that a wiki would make
updates easier.

Before I go and create anything - are there already a place similar to what
I'm describing, where I could get myself involved? (I'm too junior to start
suggesting changes and updates to the docs on OpenBSD.org, and I'm not sure
they should be used for what I want to achieve.)

I know this comes out as yet another "let's start another project no one is
asking for", but please be gentle with flaming me - I honestly want to
contribute to the community to the extent of my abilities.

Cheers,
Andreas

Re: fsck block number integer overflow

[Otto Moerbeek]

On Thu, Jan 04, 2018 at 09:11:04AM +0100, Otto Moerbeek wrote:

> On Wed, Jan 03, 2018 at 09:44:55PM -0600, Colton Lewis wrote:
> 
> > When I try to run fsck on partition m of this disk:
> > 
> > # /dev/rsd1c:
> > type: SCSI
> > disk: SCSI disk
> > label: TOSHIBA MD04ACA4
> > duid: 8ad0895bc1395d21
> > flags:
> > bytes/sector: 512
> > sectors/track: 63
> > tracks/cylinder: 255
> > sectors/cylinder: 16065
> > cylinders: 486401
> > total sectors: 7814037168
> > boundstart: 262208
> > boundend: 7814037168
> > drivedata: 0
> > 
> > 16 partitions:
> > #size   offset  fstype [fsize bsize   cpg]
> >   a:  1136000   262208  4.2BSD   2048 16384  8875
> >   b:  1821490  1398208swap
> >   c:   78140371680  unused
> >   d:  1571840  3219712  4.2BSD   2048 16384 12280
> >   e:  2318784  4791552  4.2BSD   2048 16384 12958
> >   f:  2672000  7110336  4.2BSD   2048 16384 12958
> >   g:  1545856  9782336  4.2BSD   2048 16384 12077
> >   h:  4944064 11328192  4.2BSD   2048 16384 12958
> >   i:   262144   64   MSDOS
> >   j:  2428672 16272256  4.2BSD   2048 16384 12958
> >   k:  6954496 18700928  4.2BSD   2048 16384 12958
> >   l:  7898912 25655424  4.2BSD   2048 16384 12958
> >   m:   7780482560 33554560  4.2BSD   8192 65536 1
> > 
> > fsck reports that it cannot read negative block numbers:
> > 
> > ** /dev/rsd1m
> > BAD SUPER BLOCK: MAGIC NUMBER WRONG
> > 
> > LOOK FOR ALTERNATE SUPERBLOCKS? yes
> > 
> > 
> > CANNOT READ: BLK 749213312
> > CONTINUE? yes
> > 
> > THE FOLLOWING DISK SECTORS COULD NOT BE READ: 749213312, 749213313,
> > 749213314, 749213315, 749213316, 749213317, 749213318, 749213319,
> > 
> > CANNOT READ: BLK -2147483648
> > CONTINUE? yes
> > 
> > THE FOLLOWING DISK SECTORS COULD NOT BE READ: -2147483648,
> > -2147483647, -2147483646, -2147483645, -2147483644, -2147483643,
> > -2147483642, -2147483641, -2147483640, -2147483639, -2147483638,
> > -2147483637, -2147483636, -2147483635, -2147483634, -2147483633,
> > 
> > ...
> > 
> > How can I make sure fsck can handle a partition this size? There is
> > nothing important on there at the moment.
> > 
> > -- 
> > Sincerely,
> > Colton Lewis
> 
> Did you actually newfs that partition? It looks like not since no
> superblock or alternative is found. 
> 
> That said, it looks like there's an overflow somehere. I do not have
> the hardware to investigate this though.
> 
> On a side note: a partition that large will cause problem in other
> areas. Even if it would work, the memory needed to do an fsck will be
> huge.
> 
> Also: provide dmeg! The platform involved can play a role in this.
> 
>   -Otto

I tried to reproduce your problem using a vnd image using a sparse
file.

If I do not newfs the device, I get results very similar to what you
are seeing. 

If I newfs the partition first, an fsck -f works as expected. So without
further information, I assume you did not run newfs.

I'll invetstigate the negative block numbers.

-Otto

Re: Hellos from.. the region of Üni, The Mighty

[C-DSP]

And for the rest of you, know that Racoh Box, shall be realized, if Üni, 
The Mighty wills.

Re: Kernel memory leaking on Intel CPUs?

[Alceu R. de Freitas Jr.]

 Not that I was able to see.
I guess Intel does not give a shit about non-profit groups. Linux got this 
attention because there are a lot of players making money from it, players that 
surely have some sort of partnership with Intel.

Around 2003, when I was still in college, I went to a IBM talk about Linux and 
asked the speaker why IBM chose Linux for their products instead of any of the 
*BSD available. The answer was "our customers are not asking for our 
applications on *BSD, but on Linux".
The irony is that *BSD has a lot of importance on the ecosystem, heck, even 
some products (MS Windows, MacOSX) borrowed code from *BSD projects.

Em quinta-feira, 4 de janeiro de 2018 11:32:45 BRST, Daniel Boyd 
 escreveu:  
 
 On Jan 4, 2018, at 5:43 AM, Tom Smyth  wrote:
> 
> sorry all,
> 
> I had posted to the tech mailing list about this .. I came across these 2
> papers and they may be of interest about the CPU Security flaws
> 
> https://spectreattack.com/
> 
> I hope this helps
> Tom Smyth
> 

Were the BSDs given advanced notice of this like MS, Apple, and Linux...?

  

Re: Kernel memory leaking on Intel CPUs?

[Rupert Gallagher]

Everybody is reading about it, including people like me that have formerly 
underestimated the problem... mea culpa

The question is, can we have a kernel free of patches for spynet cpus? The 
Russians are moving to ARM-based cpus, anthough ARM is subject to UK-style 
Orwellian spynet law. The Chinese have an interesting project on RISC, who is 
taking ages to hit the market.

Sent from ProtonMail Mobile

On Wed, Jan 3, 2018 at 13:19, who one  wrote:

>Did anyone hear about this?

Re: Kernel memory leaking on Intel CPUs?

[Daniel Boyd]

On Jan 4, 2018, at 5:43 AM, Tom Smyth  wrote:
> 
> sorry all,
> 
> I had posted to the tech mailing list about this .. I came across these 2
> papers and they may be of interest about the CPU Security flaws
> 
> https://spectreattack.com/
> 
> I hope this helps
> Tom Smyth
> 

Were the BSDs given advanced notice of this like MS, Apple, and Linux...?

Simplifying pf-rules

[Jon S]

Hello misc!

My OpenBSD file server just became a router too (after getting a new
internet connection where the provider does not include a router in the
subscription).

This led to my first experieces with pf. After some work I came up with
whats below. It works as I want it to work, but I wonder if there is a way
to create a rule where incomming traffic to the internal NIC (re0) is
passed if it is targeted for em0 (external, internet NIC)? The current
solution would require an update of the "pass in on re0 to
!re0:network"-rule if another NIC is added (lets say a DMZ).

set skip on lo0

# Block everything everywhere by default
block log all

# NAT local network to external
match out on em0 inet from re0:network nat-to (em0)

# Allow all outgoing traffic
pass out on {em0, re0}

# Allow only specific services on this machine to be accessed from
# local network
pass in on re0 inet proto tcp to port ssh # ssh
pass in on re0 inet proto icmp# icmp
pass in on re0 inet proto tcp to port 445 # samba

#pass in on re0 inet to em0:network # This does not work, since the
#mask for this IF will only let traffic through to the limitied set of
#IPs on the same C-segment as em0. That would probably be a set of
#other customers at the nework operator...

# This works, but will require an update if any furter NIC is involved
# later
pass in on re0 to !re0:network

# I would like something like this to work, so that future added NICs
# wont open new unwanted paths
#pass in on re0 to em0

# Allow only incomming SSH to external NIC
pass in on em0 inet proto tcp to port ssh


-- 
<>
Jon Sjöstedt

jonsjost...@gmail.com

Re: Kernel memory leaking on Intel CPUs?

[Tom Smyth]

sorry all,

I had posted to the tech mailing list about this .. I came across these 2
papers and they may be of interest about the CPU Security flaws

https://spectreattack.com/

I hope this helps
Tom Smyth

Re: trouble while building a release

[Etienne]

On 03/01/18 18:54, Theo Buehler wrote:

On Wed, Jan 03, 2018 at 06:07:36PM +, Etienne wrote:

# cd /usr/src/etc && make release
[…]
sh /usr/src/sys/conf/newvers.sh
touch: version: Permission denied
/usr/src/sys/conf/newvers.sh[84]: cannot create version: Permission denied

You probably didn't do 'rm -rf /usr/obj/*' after building and installing
the kernel (first sentence in second paragraph of step 3 in release(8)):


Thank you so much, that was it, I missed that detail.

--
Étienne

Re: fsck block number integer overflow

[Otto Moerbeek]

On Wed, Jan 03, 2018 at 09:44:55PM -0600, Colton Lewis wrote:

> When I try to run fsck on partition m of this disk:
> 
> # /dev/rsd1c:
> type: SCSI
> disk: SCSI disk
> label: TOSHIBA MD04ACA4
> duid: 8ad0895bc1395d21
> flags:
> bytes/sector: 512
> sectors/track: 63
> tracks/cylinder: 255
> sectors/cylinder: 16065
> cylinders: 486401
> total sectors: 7814037168
> boundstart: 262208
> boundend: 7814037168
> drivedata: 0
> 
> 16 partitions:
> #size   offset  fstype [fsize bsize   cpg]
>   a:  1136000   262208  4.2BSD   2048 16384  8875
>   b:  1821490  1398208swap
>   c:   78140371680  unused
>   d:  1571840  3219712  4.2BSD   2048 16384 12280
>   e:  2318784  4791552  4.2BSD   2048 16384 12958
>   f:  2672000  7110336  4.2BSD   2048 16384 12958
>   g:  1545856  9782336  4.2BSD   2048 16384 12077
>   h:  4944064 11328192  4.2BSD   2048 16384 12958
>   i:   262144   64   MSDOS
>   j:  2428672 16272256  4.2BSD   2048 16384 12958
>   k:  6954496 18700928  4.2BSD   2048 16384 12958
>   l:  7898912 25655424  4.2BSD   2048 16384 12958
>   m:   7780482560 33554560  4.2BSD   8192 65536 1
> 
> fsck reports that it cannot read negative block numbers:
> 
> ** /dev/rsd1m
> BAD SUPER BLOCK: MAGIC NUMBER WRONG
> 
> LOOK FOR ALTERNATE SUPERBLOCKS? yes
> 
> 
> CANNOT READ: BLK 749213312
> CONTINUE? yes
> 
> THE FOLLOWING DISK SECTORS COULD NOT BE READ: 749213312, 749213313,
> 749213314, 749213315, 749213316, 749213317, 749213318, 749213319,
> 
> CANNOT READ: BLK -2147483648
> CONTINUE? yes
> 
> THE FOLLOWING DISK SECTORS COULD NOT BE READ: -2147483648,
> -2147483647, -2147483646, -2147483645, -2147483644, -2147483643,
> -2147483642, -2147483641, -2147483640, -2147483639, -2147483638,
> -2147483637, -2147483636, -2147483635, -2147483634, -2147483633,
> 
> ...
> 
> How can I make sure fsck can handle a partition this size? There is
> nothing important on there at the moment.
> 
> -- 
> Sincerely,
> Colton Lewis

Did you actually newfs that partition? It looks like not since no
superblock or alternative is found. 

That said, it looks like there's an overflow somehere. I do not have
the hardware to investigate this though.

On a side note: a partition that large will cause problem in other
areas. Even if it would work, the memory needed to do an fsck will be
huge.

Also: provide dmeg! The platform involved can play a role in this.

-Otto