Re: how to completely reset all networking configuration without rebooting?

2022-06-26 Thread Theo de Raadt
Jonathan Thornburg  wrote:

> In ,
> Stuart Henderson  wrote
> > netstart does nothing to clear existing configuration. It wouldn't make
> > sense to do this for joinlist without also e.g. clearing IP addresses
> > from interfaces as needed, resetting media options/MTU/rdomain/VLAN
> > configuration, etc.
> 
> So, is there a way to to completely reset all networking configuration
> without rebooting?

No.



Re: rpcbind security

2022-06-17 Thread Theo de Raadt
I am certain you can find it yourself.

Gustavo Rios  wrote:

> may some here points me where rpcbind is implemented ? I would like to see 
> the C code
> of it.
> Thanks.
> 
> Em sex., 17 de jun. de 2022 às 00:20, Theo de Raadt  
> escreveu:
> 
>  Gustavo Rios  wrote:
> 
>  > Hi folks!
>  > 
>  > How does openbsd rpcbind prevent ordinary users to unset a given rpc port
>  > mapping registered by, for instance, the root user ?
> 
>  Poorly.
> 
>  It will only allow local root (who request upon a reserved port) to touch
>  ports which are reserved (< 1024), and 2049 is treated the same way.
> 
>  If root wants safe RPC, it needs to use reserved ports.
> 
>  Please don't bring up the argument that reserved ports are an outdated
>  concept, it is obvious right here they aren't.
> 
>  It is difficult to improve the RPC ecosystem, it kind of is what it is,
>  and noone new services use it.
> 
> -- 
> The lion and the tiger may be more powerful, but the wolves do not perform in 
> the
> circus
> 



Re: rpcbind security

2022-06-16 Thread Theo de Raadt
Gustavo Rios  wrote:

> Hi folks!
> 
> How does openbsd rpcbind prevent ordinary users to unset a given rpc port
> mapping registered by, for instance, the root user ?

Poorly.

It will only allow local root (who request upon a reserved port) to touch
ports which are reserved (< 1024), and 2049 is treated the same way.

If root wants safe RPC, it needs to use reserved ports.

Please don't bring up the argument that reserved ports are an outdated
concept, it is obvious right here they aren't.

It is difficult to improve the RPC ecosystem, it kind of is what it is,
and noone new services use it.



Re: pkg_add in -current

2022-06-04 Thread Theo de Raadt
Stuart Henderson  wrote:

> On 2022/06/04 15:23, Theo de Raadt wrote:
> > Stuart Henderson  wrote:
> > 
> > > If you are running -current and have not updated base recently, you
> > > may run inTO "pkg_add: Unknown option: always-update ".
> > > To fix it, just update to a newer base snapshot.
> > 
> > 
> > 
> > What happened is that a developer made a change to the pkg tools which
> > creates completely incompatible package files.
> > 
> > Noone knew this was happening beforehands.  An email was circulated
> > after-the-fact to ports@ list (which is mostly read by developers, and
> > not read by users).  It has now been weeks, and it still hasn't been
> > clearly communicated.
> 
> People can decide for themselves about that,
> 
> First commit enabling parsing in pkg_add
> https://github.com/openbsd/src/commit/5cb7aebf4211294fd2891b0bc45c383ab7fd66af

That commit message does not say:

 There will be no backwards compatiblity.

> "REMINDER: snapshots go with -current"
> https://marc.info/?l=openbsd-ports=165355109123377=2

That message says:

 There is zero effort being made for backwards compatiblity.

It also says it is going to be FUN.  Are we having fun?  We are not
having fun.  This is the case of one developer (who did not even
explain what was happening to any non-ports developer) making a decision
in their own bubble, without communicating the impact in a way that
everyone can understand.

> Second commit, after base is updated with this subsequent package builds
> use the new annotation
> https://github.com/openbsd/src/commit/c2e596a17ac45689d758df0d67597fef94480ebe

That commit message does not say:

 No effort has been made for backwards compatibility.

> (Then it takes time for new packages to be built on the various archs
> and it's not until *then* that errors would show up for people who
> haven't updated base yet)

So here we are:

There is no backwards compatibility, and users are starting to
encounter the problem, and the answer for them is that they must reboot.
No it's not just that, they are being told the PROCESS WAS GREAT, and
what is wrong here is *THEIR* process of using snapshots.

It has also been pointed out that current.html has no information about this
change.  I have been saying for a while we should delete current.html
because it seems to always contain useless information, and here we see
it lacks crucial information.



Re: reminder: ports snapshots go with base snapshots

2022-06-04 Thread Theo de Raadt
That Subject is incorrect.


Unless pkg_add is going to start doing a stat() of /bin/cat and demanding
you run sysupgrade INCLUDING THE REBOOT if the file is more than a day 
old?  or is it two days?  Or is it a week?

What has happened for years now is that if you attempt to upgrade an
old base snapshot with new packages, you get nice messages which tell you
what libraries are incompatible, and then you it is clear to everyone
what is going on and they take the correct action.

But I guess your real message here is the library checking code in pkg_add
can be deleted, because telling everyone "you must have upgraded to a
new snapshot INCLUDING THE REBOOT" is the new way, so why check libraries?!!
they will always have the new libraries, because you are saying that is
the ONLY RIGHT WAY.

You are wrong.  We will not demand that people aggressively jump to new
snapshots.


Look, you failed to communicate with the developers ahead of time
and then you failed to communicate with the users _after the fact_,
and it required complaints on public and developer forums before
you acted by telling people their process is broken.


No, sorry, you are incorrect blaming users for not updating to new snapshots.

What is wrong here is your development process.



Marc Espie  wrote:

> If you don't update base first (as you should always do),
> recent package snapshots will break.
> 
> Code to parse the hash after
> @option always-update 
> was added on May 26.
> 
> Package snapshots built after May 28 use that new syntax.
> 
> You will notice fairly early, as quirks uses
> @option always-update
> 
> the new package will refuse to install with an error
> from the packing-list parsing code:
> 
> "Unknown option: always-update "
> 



Re: pkg_add in -current

2022-06-04 Thread Theo de Raadt
Stuart Henderson  wrote:

> If you are running -current and have not updated base recently, you
> may run inTO "pkg_add: Unknown option: always-update ".
> To fix it, just update to a newer base snapshot.



What happened is that a developer made a change to the pkg tools which
creates completely incompatible package files.

Noone knew this was happening beforehands.  An email was circulated
after-the-fact to ports@ list (which is mostly read by developers, and
not read by users).  It has now been weeks, and it still hasn't been
clearly communicated.

We break compatibility often, but generally ensure the right people --
both developers and users -- know when they need to know.  This is
important because people who follow snapshots (in various ways) should
have a good experience because if they don't enjoy the snapshot
experience, we may end up with a smaller test community between
releases.

Sometimes there are surprises in snapshots of a testing nature, but this
particular change was not deployed or communicated as a test (we cannot
go back).

The normal model was not followed in this instance.



Re: happy birthday theo

2022-05-19 Thread Theo de Raadt
Thank you all, but I don't understand why this is so exciting.

I mean, it isn't a release day!



stati...@cryptolab.net wrote:

> I will join in as well: Happy birthday, Theo!
> And thank you for all the good work on this sublime OS...
> 
> Cheers,
> Oddmund
> 
> 
> Le 19/05/2022 à 16:33, Amit Kulkarni a écrit :
> > Happy Birthday to Theo!
> > On Thu, May 19, 2022 at 4:46 AM Brodey Dover 
> > wrote:
> >>
> >> Happy Birthday Theo!
> >>
> >> On Thu, 19 May 2022 at 02:51, Mayuresh Kathe  wrote:
> >>
> >>> here's wishing theo deraadt a very happy birthday.
> >>> wish you many more years of producing great software and being
> >>> cantankerous. :p
> >>> have a great day today and an amazing year ahead.
> >>> -mayuresh
> >>>
> >>>
> > 
> 



Re: Problems with bsd.rd upgrade and FDE.

2022-05-18 Thread Theo de Raadt
Nicola Dell'Uomo  wrote:

> From a couple of weeks I've been noticing these problems when I upgrade from 
> bsd.rd:
> 
> - after installing all verified .tgz files and making device nodes & 
> fw_update my system reports as follows: 'Failed to install bootblocks. You 
> will not be able to boot OpenBSD from sd1.' sd1 is my FDE volume, which after 
> this message boots;
> - after this upgrade my system boots GENERIC (and not GENERIC.MP) kernel; top 
> confirms I'm runnig with just one cpu;
> - in order to be back to MP I have to expressly load bsd.mp at prompt; or 
> compile my own kernel (GENERIC.MP), install and reboot.
> 
> Am I missing something or should I file a bug?

What kind of question is that?  You could skip filing a bug, and we can
skip looking into it.

There are a few people who have mentioned issues, and thus far they have been
providing incredibly bad reports, as in, they have *NO LOG* of the upgrade,
and they assume we should be able to read tea leaves or something.

As for "FDE", whatever that means!  There are numerous ways to setup such 
systems
because the installer doesn't do it native, and I believe MANY PEOPLE have set
it up using bizzare configurations, and if bsd.rd doesn't know what is going 
on..

I want to also mention I remain bewildered that we provide source, that
the install script is on the install media, that the install media can
be mounted, that the install script can be edited to make it more
verbose to help in debugging UNDESCRIBED configurations WE DON'T HAVE,
but hey  self-help seems to be a completely foreign concept.






Re: Historical Reasons For Default NAT Source Port Modification

2022-05-16 Thread Theo de Raadt
Elias Carter  wrote:

> I have found that preserving the source port if possible works better
> out of the box when hosting publicly accessable UDP applications
> within a private network.

Preserving the source port also works better for attacking services...

I don't see anything strange in what we did.  We have always taken the
approach of damaging potential attack surface by introducing random, when
the deterministic situation is already unstable for regular use.



Re: Wireguard IP packets fragmentation issue

2022-05-15 Thread Theo de Raadt
 .Bd -literal -offset indent
-inet 0.0.0.0 255.255.255.255 NONE \e
+inet 0.0.0.0 255.255.255.255 0.0.0.1 \e
pppoedev em0 authproto pap \e
authname 'testcaller' authkey 'donttell' up
-dest 0.0.0.1
 inet6 eui64

I don't think this is the right way to go.  Yes, on p2p links the
broadcast address is reused as destination by internal kernel logic,
but I don't think anyone is helped by hiding the configuration of this
in such a way.



Re: Cron running at 99% CPU for seemingly no reason

2022-05-15 Thread Theo de Raadt
This is a bug in a diff I put into snapshots.



Re: hw.perfpolicy behavior on desktop/server

2022-05-12 Thread Theo de Raadt
f.holop  wrote:

> Theo de Raadt - Wed, 11 May 2022 at 18:08:53
> > f.holop  wrote:
> > 
> > > Stuart Henderson - Mon, 09 May 2022 at 17:17:57
> > > > Currently, you can either set it manually to low speed
> > > > (hw.perfpolicy=manual, hw.setperf=0), modify the kernel (e.g. with the
> > > > diff below), or use obsdfreqd from packages. The latter is only in
> > > > -current packages not 7.1, but it could be built from ports.
> > > 
> > > I think the elephant in the room is:
> > > will this change be reverted?
> > > 
> > > What is the rationale of not letting wall powered servers
> > > throttle down?
> > 
> > As it is today the scheduler-based algorithm seriously sucks, and after
> > the change it was discovered many machines were running 10-20% less than
> > peak performance even under load.  This was discovered during
> > suspend/hibernate/resume events but it affects all workloads.
> 
> a 3rd party package popping up immediately to "solve" this issue is a
> good sign that it's not only about me me me. i don't know your workload,
> you don't know mine.  some do not need "peak performance" workloads all
> the time and actaully care more about power consumption on the long run
> than a couple of percentage points lost in performance.

I don't care what your workload is.

Shall I remind you what my role is in this project?  Should I demonstrate
it by quitting?

Grow up.

> this mailing list is littered with performance issues regarding openbsd
> and it was always a clear message by the developers that it is something
> important but clearly secondary after correctness, readability, etc.

we can't be a fast operating system, if the default behaviour is to slow
down aggressively, and not speed up aggressively.

> it's great that this was discovered but openbsd could simply come with
> those default settings and recommendations. let me choose my tradeoffs
> please, that was the entire point of that sysctl.  the exact same effect
> the hardcoding does was solvable with 2 lines of sysctl.conf for _those
> who wanted it that way_.

you are wrong.

> this whole discussion is really bizarre, do you want to hardcode some
> of my other sysctls as well in the next release?
> apparently we are not adults who should have a choice.

oh will you just shut up.

> i am really curious how this will affect your own power bill, you have
> lots of iron at home, some quite power hungry i imagine.  summer is
> coming maybe you will need more cooling too.  please publish some
> numbers in a month or two if you dont mind the transparency.

I don't care how it affects your power bill.

Why don't you go run some other operating system and get your moaning
off this list?



Re: why does resolvd sort nameserver rules

2022-05-11 Thread Theo de Raadt
William Ahern  wrote:

> On Wed, May 11, 2022 at 04:54:02PM +0100, james palmer wrote:
> > i have a local dhcp server running which gives out three nameservers:
> > 
> > - 192.168.0.2 (resolves some local machine names)
> > - 9.9.9.9
> > - 149.112.112.112
> > 
> > on linux, android, and windows the local nameserver takes priority over the 
> > others.
> > on openbsd thanks to the nameservers being sorted by ip address 
> > 149.112.112.112 is chosen first.
> > this causes the local machine names to not resolve.
> > 
> > is there a reason for this behaviour?
> > i would expect the nameservers to be written in the order they are set as 
> > on the dhcp server.
> 
> I have no direct knowledge, but judging from the code in resolvd.c
> handle_route_message and cmp, the sorting is primarily driven by declared
> priority of the source--resolvers associated with a higher priority source
> come first, independent of IP address. However, the relative ordering
> information among a set of proposed resolvers from a particular routing
> message seems to be dropped on the floor, no other information is used to
> sort, and the sort comparator falls back to comparing the address strings
> (using strcmp) to achieve a stable sort.

yes, but you missed a piece: /* Eliminate duplicates */

Duplicates should be eliminated when possible, because libc/asr only
uses the first 5 addresses I think.

Imagine we have a v4 announcement doing 3 addresses, and a v4 "umb"
doing 2 addreses, libc will never get around to using a manual entry at
the end if those dynamic dns servers are in fact not responding.

I was trying to handle that kind of situation heuristically.

Maybe we can avoid the address sort, but still attempt to delete duplicate
addresses, to increasae the odds of reaching a manual entry.

> This could be fixed, assuming the current behavior is broken or undesirable,
> by adding a new member to struct rdns_proposal recording the relative
> ordering of proposals within the incoming routing message (i.e. their index
> in the proposal set), and using that member in the comparator to sort
> addresses of equal priority before resorting to strcmp on the address
> string. This presumes the DHCP advertisement order is preserved in the
> routing message. There other potential nuances, like multiple proposal sets
> (from different routing messages) with the same priority, in which case a
> message counter or other mechanism might also be needed to get a more
> intuitive total ordering.

Naw the qsort() is only sensitive to the address to reduce bigO of the
duplicate elimination.  I think a slightly more clever sort+eliminate chunk
of code would do the job.




Re: hw.perfpolicy behavior on desktop/server

2022-05-11 Thread Theo de Raadt
f.holop  wrote:

> Stuart Henderson - Mon, 09 May 2022 at 17:17:57
> > Currently, you can either set it manually to low speed
> > (hw.perfpolicy=manual, hw.setperf=0), modify the kernel (e.g. with the
> > diff below), or use obsdfreqd from packages. The latter is only in
> > -current packages not 7.1, but it could be built from ports.
> 
> I think the elephant in the room is:
> will this change be reverted?
> 
> What is the rationale of not letting wall powered servers
> throttle down?

As it is today the scheduler-based algorithm seriously sucks, and after
the change it was discovered many machines were running 10-20% less than
peak performance even under load.  This was discovered during
suspend/hibernate/resume events but it affects all workloads.

No, the change won't get reverted.  That is simply trying to ignore the
problem with a "I only care about myself" attitude.

It may get fixed after work in the scheduler which is not so damned
pessimistic to give people 20% less machine than they bought, and
this may happen as a resultt of pivoting to the opposite side of the problem
space, so that the people who actually performance adjustments ensure the
ramping up/down actually works without hurting PERFORMANCE.



Re: OpenBSD ports require xbase set - still true?

2022-05-09 Thread Theo de Raadt
I looked very closely, it started like this

  "Just a rant"

And I knew the email was coming from a self-centered individual who is
unhappy with the entirely volunteer work done by others, yet not unhappy
enough to quit OpenBSD and switch to another operating sytem where
there will be similar unhappiness because those other systems also won't
do precisely what you want.

Your email is not appropriate.  If you don't like OpenBSD, use something
else, because noone deserves an email which starts with those 3 words
you chose, and the following complaint is such horseshit in a world
where disk drives are cheap.  I started OpenBSD a quarter of a century
ago by spending $3500 for a 300MB drive and ate noodles and tuna for
many months to make up for that, and we do not live in a world where you
get to moan about 55MB, relative to whatever it takes to ease the complicate
work undertaken by the ports developers.

In short, Steffen, you need to shut up.

Steffen Nurpmeso  wrote:

> Theo de Raadt wrote in
>  <36104.1652132...@cvs.openbsd.org>:
>  |The people who do the work make the decisions.
> 
> Ok i will at least look what i was talking about.
> 
>  |Steffen Nurpmeso  wrote:
>  |
>  |> Hello.
>  |> 
>  |> Just a rant, not for ports@.
>  |> I am installing OpenBSD 7.1 right now; this is only a VM, and
>  |> i want to create / manage ports there.
>  |> Until now whenever i wanted to do this i had to install xbase,
>  |> otherwise the port makefile complained some.  (I am afraid i have
>  |> forgotten the details.)  Is this still true?  I know i once
>  |> "hacked" it because for my ports it really was not needed, at
>  |> least not really.  Hm.  I think i even posted about this quite
>  |> some years ago.  I have installed xbase now, maybe i even will use
>  |> it (OpenBSD X is always super proper, i cheered this often; CRUX
>  |> also, but of course not base-integrated).  If not then 55 MB for
>  |> a file is quite an act.
>  |> 
>  |> --steffen
>  |>|
>  |>|Der Kragenbaer,The moon bear,
>  |>|der holt sich munter   he cheerfully and one by one
>  |>|einen nach dem anderen runter  wa.ks himself off
>  |>|(By Robert Gernhardt)
>  |> 
>  --End of <36104.1652132...@cvs.openbsd.org>
> 
> --steffen
> |
> |Der Kragenbaer,The moon bear,
> |der holt sich munter   he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off
> |(By Robert Gernhardt)
> 



Re: OpenBSD ports require xbase set - still true?

2022-05-09 Thread Theo de Raadt
The people who do the work make the decisions.

Steffen Nurpmeso  wrote:

> Hello.
> 
> Just a rant, not for ports@.
> I am installing OpenBSD 7.1 right now; this is only a VM, and
> i want to create / manage ports there.
> Until now whenever i wanted to do this i had to install xbase,
> otherwise the port makefile complained some.  (I am afraid i have
> forgotten the details.)  Is this still true?  I know i once
> "hacked" it because for my ports it really was not needed, at
> least not really.  Hm.  I think i even posted about this quite
> some years ago.  I have installed xbase now, maybe i even will use
> it (OpenBSD X is always super proper, i cheered this often; CRUX
> also, but of course not base-integrated).  If not then 55 MB for
> a file is quite an act.
> 
> --steffen
> |
> |Der Kragenbaer,The moon bear,
> |der holt sich munter   he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off
> |(By Robert Gernhardt)
> 



Re: HP T430 "Thin Client": Won't sysupgrade without HDMI monitor attached.

2022-05-06 Thread Theo de Raadt
Florian Obser  wrote:

> So, if you end up with a /bsd.upgrade on the running system that is
> still mode 0700, your bootloader is on the fritz.
> 
> If you have a /bsd.upgrade that's 0600 your bootloader found the kernel
> and tried to boot it, but the installer didn't get very far.
> 
> If there is no /bsd.upgrade after a reboot and no email to root the
> installer got rebooted by a watchdog process, otherwise you got an email
> to root detailing the upgrade process.

A very nice 3-way split.

Then once you figure out which one of those 3 is happening, it is easy
to reason about how to create further differentiations and see which is
happening.



Re: Howto do "a detailed cleanup with the aid of the sysclean package"?

2022-05-04 Thread Theo de Raadt
Marc Espie  wrote:

> All the horrors stories I've seen in this discussion are related
> to people trusting it blindly/automatically.

But why wouldn't people trust it?

All the documentation claims it produces a list of files that is obsolete.

It says those files are obsolete & unused -- with such authority!

Nowhere does it say "Oh, but these obsolete files may still be used"

Why is it blind for people to run rm?  Are they stupidly making assumptions
based upon the documentation?



Re: Howto do "a detailed cleanup with the aid of the sysclean package"?

2022-05-04 Thread Theo de Raadt
Sebastien Marie  wrote:

> a package could use old libraries, and such libraries will not be listed by 
> sysclean.

the sysclean manual page claims that it correctly identifies "obsolete
filenames".

Obsolete, adj.

1.no longer produced or used; out of date.

But this is innaccurate.  By your own admission, the test it performs to
decide on whether a file is "not used" is flawed.

Yet, people continue to use rm.

> yes it will. but as sysclean only inspects files under directories controlled 
> by 
> the admin, it means that the administrator created such files and so they 
> know 
> what it is doing.

The "controlled by admin" file does not exist by default, so normally this
will look in a lot of system locations, and falsely identify unused files.

Let me be clear: the program is lying to the user.  It is documented vaguely
to hide that what the program does is not truthful.  It says "obsolete" all
over the place, but no actual test for that condition is performed.

> > And then someone will rm -f `sysclean`.
> 
> sysclean isn't designed for such usage.

Yet, that is precisely what numerous people have done.

> I could saying the same about 'ls'. Someone will rm -f `ls` and a file named 
> "/somewhere/matchingpattern/\n/etc/spwd.db" will do bad thing.

Yet, noone is doing that.

> Should we add -0 to ls ? or remove it because of possible stupid usage ?
>  
> > I think sysclean is below the normal standard for our group.
> 
> Yes. ls too. it could hurt users which might call rm -f `ls`. 


Clear you don't care that people are getting hurt by this code you wrote.



Re: Howto do "a detailed cleanup with the aid of the sysclean package"?

2022-05-04 Thread Theo de Raadt
Sebastien Marie  wrote:

> semarie@ spoke about integrating some elements inside the installer when he 
> was 
> about "clean _other things_". It isn't about "stepping back". Even if the 
> installer would clean all it is possible to remove safely, I would still use 
> a 
> program to list libraries without registered packages using them.

There is nothing you can do in the installer to solve this problem of
deleting old libraries.  Old libraries MUST STAY, because sysclean does
not traverse and inspect all files in the entire filesystem to conclude
there are no use of them.

> I wrote sysclean because it solves *my* problems regarding maintaining a 
> system, 
> and I shared it because it could help *some* others people. It wasn't created 
> with intent to solve the general use case for all possibles users.

The pkg_info blob says:

sysclean is a script designed to help remove obsolete files between OpenBSD
upgrades.

But sysclean can help people remove non-obsolete files.  

sysclean does not remove any files on the system. It only reports obsolete
filenames or packages using out-of-date libraries.

The sysclean report includes files without doing a comprehensive search to
validate that they are NOT IN USE.  They are not obsolute, yet they show up
in the list.

> You don't like it, fine. Just don't use it.

This conversation is happening because sysclean makes it too easy for
people who don't understand the complete system sufficiently, to then
use rm, and break their system.

You can make that claim of "Don't use it" against me all day long, but
people will keep discovering sysclean and potentially using it to break
their systems.

I have also pointed out a couple of times now that sysclean ignores the
lessons of "find -print0" and "xargs -0", and I worry it could find a
file called

"/somewhere/matchingpattern/\n/etc/spwd.db"

Pehraps it won't match such patterns?  I suspec it will.

And then someone will rm -f `sysclean`.


I think sysclean is below the normal standard for our group.




Re: Howto do "a detailed cleanup with the aid of the sysclean package"?

2022-05-04 Thread Theo de Raadt
Harald Dunkel  wrote:

> Hi folks,
> 
> I think the main problem is pretty easy to describe: OpenBSD loses track
> about what it had installed and cannot clean up its own files on a system
> upgrade.

No, that is incorrect.

Users are capable of creating linking against older lib*.so.* files.
Such binaries could be anywhere on-disk, and we should not walk the entire
disk to find them.  Therefore such old libraries should NEVER be deleted.

It isn't that track as been lost.  The linker isn't going to create a log
file about what lib* files have been used at compile time.

New OpenBSD snapshots come with new libraries, because we crank
major.minor for incompatible changes, and there are some who think they
can delete the old libraries.

Such old libraries should NEVER be deleted.

sysclean wasn't designed to delete these libraries, but these libraries
are the biggest win as far as diskspace, so the selection algorithm
started hoovering them up, and it seems semarie doesn't want to walk
back "OK, I can clean _other things_ but I must leave the libaries alone".

Because then I guess then sysclean doesn't feel like such a winning
proposition at all...




Re: Maximum size of mfs in i386

2022-05-03 Thread Theo de Raadt
> What could be the cause? Is there any way to increase the MAXDSIZ to
> nearly 3GB?

No.

Our i386 architecture is a bit special.  Since older machines don't have
a NX bit, we invented a "line-in-the-sand" scheme using segment limits.
In a userland process, this places code below 512MB, and data above that,
and shared libraries stradle the distance if needed.  We are doing PIE ASLR,
so it is unclear exactly how large a linear-range of memory remains.
This is what is causing the effects you are seeing.

If you want more, move to amd64.



Re: clang 13 space issues with KARL

2022-04-28 Thread Theo de Raadt
>On Thu, Apr 28, 2022 at 10:44:09AM -0600, Theo de Raadt wrote:
>> If people built properly sized machines there would be no problem.
>
>That's a little condescending don't you think?

Not at all.

If you don't use a tool as it was intended, you bear the consequences.

*WE* built the tool.  *WE* decided how it works.  We even documented
how much resources it typically needs.  When people use it
incorrectly, it is their own damn fault.  *THEY* can make adjustments.

But they cannot complain, because they did not pay and even if they
had there is no warrantee.

There is nothing condescending about telling someone their complaints
about how something works are falling on deaf ears.  I don't give a
flying damn if KARL is hurting people who don't provide their machines
with reasonable defaults.  It is their own damn fault, and they can
make manual accomodations for their own (completely stupid, IMHO)
decisions.

In this modern world is has become *impossible* to complain about
any technology which doesn't work like you want, companies who take
money don't give a damn.  Here's the shocker:  I will not be held
to a higher standard than that.  So Peter, your attitude stinks
and your suggestion that anything I've said is "rude" rather than "real",
thgat suggestion of yours is an insult.



Re: clang 13 space issues with KARL

2022-04-28 Thread Theo de Raadt
>On 2022-04-27, Nick Holland  wrote:
>>> What can I do to make KARL reorder_kernel use less memory without buying 
>>> more
>>> RAM?  I've turned KARL off for now but that's not a real solution and I hate
>>> it.
>>> 
>>> Is there no option in the clang 13.0.0 linker to store what it would 
>>> normally
>>> store in memory to disk?  I know it would be slow but KARL doesn't need to
>>> be fast if it's backgrounded.
>>
>> yep. It is called "swap".  You just reinvented swap. :)
>> And KARL is backgrounded already.
>
>And that's the problem in some cases: /bin/time -l says that
>reorder_kernel uses ~650MB rss on my laptop. Depending on what else you
>have running (noting that daemons, which are often starting at around
>the same time as reorder_kernel runs, often use more RAM during startup
>than in a steady state) that can be enough to tip it over the edge.

650MB rss why is this a big deal?

I think people are building tiny little machines that Linux would
never run on, and then inventing complaints.

If people built properly sized machines there would be no problem.

Alternatively, they should grow up and go work on making the linker
use less memory.

I do not understand why this complaint exists.

If you built a machine that cannot link a kernel, your machine is
very likely Not Fit For Modern Purposes.  Grow up, this is not the year
2000.



Re: Sprurios errors from syspatch -c

2022-04-22 Thread Theo de Raadt
Richard Narron  wrote:

> On Fri, 22 Apr 2022, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
> 
> > After the 7.1 update syspatch -c started throwing errors due to a
> > missing signatures file:
> >
> >   Patch check:
> >   syspatch: Error retrieving 
> > http://ftp.openbsd.org/pub/OpenBSD/syspatch/7.1/amd64/SHA256.sig: 404 Not 
> > Found
> >
> > The error is valid.  To suppress this message it would make sense to drop
> > an empty place holder SHA256.sig file whenever a new release comes out.
> >
> 
> The error is caused by the wrong directory name.
> 
> The syspatch/7.1 directory was renamed to syspatch/7.1-no
> 
> Rumor has it that the source patch is good but the syspatch is bad, so
> someone renamed the syspatch 7.1 directory to prevent its use.
> 
> Has anyone heard anything "official" about this?


The syspatch was accidentally built from the wrong branch, so upon
relinking, it results in a kernel which says it is "7.1-stable".

To prevent application of syspatches to the wrong type of system,
syspatch(8) inspects 'sysctl kern.version'.  It checks you have a normal
release system (ie. 7.0 or 7.1).  Since this patch renamed the system to
"7.1-stable", syspatch(8) will refuse to install future patches.  And of
course the way this check is coded, it won't let you backout the patch
which took the system to 7.1-stable..

Simple instructions for getting over this trouble will be coming along
before there is a new syspatch 001_wifi is made available.  I estimate a
week.

People who already installed the 001_wifi syspatch aren't harmed by the
fix otherwise, but I have stopped distribution of the file to reduce the
number of people in this crossed-over state.

(Other than this issue, the syspatch itself was good, it fixes wifi
association problems on a number of devices, so people who already
have it shouldn't take special measures to get rid of it yet, wait for
our advice in a week or so).

And of course, the syspatch testing procedures will get another step or
two to make sure this doesn't happen again

So just wait.



Re: Howto do "a detailed cleanup with the aid of the sysclean package"?

2022-04-21 Thread Theo de Raadt
Stuart Henderson  wrote:

> > Btw. there is another school of thought that says old cruft doesn't need
> > to be removed, it's not causing any harm. If you need a clean system
> > just reinstall and restore config and data from backups. It's a good
> > excercise to check that your backups are working.
> 
> I disagree, it can cause harm sometimes. Not least when you run out of
> space in /usr halfway through untarring sets during an update...

That is a false history.

Many people got burned because we used to make /usr a certain size, then
we switched to clang.

But there were 2-3 other cases of this happening, where something quite big
was added to /usr

Most users upgrade release-to-release, and will only accumulate a few large
lib*.so.*.* files.  The upgrade process cleans out old clang/gcc leftovers.
So there isn't much growth.

If those users upgrade via snapshots, then the library collections can become
a problem.



I think it is dangerous to push our users to use sysclean.  Many of them
newbies.  There are people who review the data, then
  rm -rf `sysclean'
or
  sysclean | xargs rm -rf

About about paths containing \n  ?  The lessons of find -print0 forgotten
so easily?

What about TOCTOU concerns, there is no mention of the multiuser possibility
that someone can create a path that plays with the \n concern above.

I think the program is misdesigned.  It attacks files which are not in
the current upgrade set, rather than attacking files which were in
previous upgrades.  It attacks non-OpenBSD files.  It traverses
directories which have nothing to do with the OpenBSD system itself.  It
attacks files which OpenBSD never supplied.  The manual page does not
document the heuristic it will use, so that people can decide "whoa,
that will screw me because of how I use my directories". It is quite
simply unable to make correct decisions perhaps because there isn't
correct information to based this upon, and then there is this magic
leap that people won't use one of the two approaches above and after
doing so they will have a non-reversable problem.  Actually probably the
biggest problems are the (1) vagueness of the manual page, assuming
people will do the right thing, and (2) people pushing (for newbies) to
use this on social media.  The manual page doesn't tell people to remove.
But oh, here is a list, of what you should remove.  But we didn't tell
you to remove anything. Isn't that a bit deceitful?

I've heard of experts misusing sysclean, so I very much suspect there
are many users who have misused it, destroyed their system, and been to
shy to complain.





OpenBSD 7.1 released, April 21, 2022

2022-04-21 Thread Theo de Raadt



- OpenBSD 7.1 RELEASED -

April 21, 2022.

We are pleased to announce the official release of OpenBSD 7.1.
This is our 52nd release.  We remain proud of OpenBSD's record of more
than twenty years with only two remote holes in the default install.

As in our previous releases, 7.1 provides significant improvements,
including new features, in nearly all areas of the system:

 - New/extended platforms:
o Support for Apple Silicon Macs has improved and is ready for
  general use:
   - Added aplspi(4), a driver for the SPI controller found on the
 Apple M1 SoC.
   - Added aplhidev(4) support for the keyboard/touchpad on Apple
 M1 laptops.
   - Introduced aplpmgr(4), a driver for the power management
 controller found on Apple SoCs.
   - Introduced aplmbox(4), a driver for the mailbox that provides
 a communication channel with additional cores integrated on
 Apple SoCs.
   - Introduced apliic(4), a driver for the I2C controller found
 on Apple SoCs.
   - Added the chip ids used on Apple M1 Pro/Max and Apple T2 Macs
 to bwfm(4).
   - Rewrote arm64 kernel FPU handling code to fix the random
 crashes seen with SMP kernels on Apple M1.
   - Restricted the pci(4) ioctl interface to devices detected by
 the kernel, preventing Xorg PCI probes from breaking the WiFi
 chip on M1 macs.
   - Introduced aplsmc(4), a driver for the SMC found on Apple M1
 SoCs.
   - Introduced aplnco(4), a driver for the Numerically-controlled
 oscillator (NCO) clock which drives the audio clocks on Apple
 silicon.
   - Introduced tascodec(4), a driver for the TI TAS2770/TAS5770
 digital audio amplifier codec found on Apple M1 Macs.
   - Introduced apldma(4), a driver for the DMA controller found
 on Apple SoCs.
   - Added support to explicitly power on some PCIe devices on the
 M1 and M1 Pro/Max through a GPIO controlled by the SMC.
   - Added aplcpu(4), a driver to control the CPU performance
 levels on Apple SoCs.
   - Modified aplintc(4) to support a newer interrupt controller,
 making OpenBSD run on M1 Pro/Max machines.
   - Added nvmem support to aplpmu(4) and made it available on
 Apple SPMI PMUs.
   - Added RTC support to aplsmc(4).
   - Made the arm64 ramdisk installer fetch bwfm(4) firmware from
 the EFI System Partition on Apple Silicon devices for use
 during installation and addition to the newly installed
 system.
   - Added support for controlling keyboard LEDs to aplhidev(4).
   - Added basic GPIO support to aplsmc(4).
   - Ensured apldart(4) keeps the DART enabled in front of the
 display controller to preserve its access to the framebuffer
 and continued display.
   - Fixed reading motherboard time on Apple machines with old SMC
 firmware.
   - Implemented reboot/powerdown support in aplsmc(4).
   - Implemented aplintc(4) support for multiple dies, making
 OpenBSD work on the M1 Ultra.
o Support for other arm64 architecture hardware was also improved
  with the following changes:
   - Introduced gpiocharger(4), a driver providing support for
 battery chargers connected to GPIO pins, such as those found
 on the Pinebook Pro.
   - Introduced gpioleds(4) for arm64, a driver providing support
 for LEDs connected to GPIO pins, such as those found on the
 Pinebook Pro.
   - Added gpiokeys(4) for arm64, a driver which handles events
 triggered by GPIO keys such as lid status and power button.
   - Added pclk clock used by dwdog(4) on RK3399 to rkclock(4).
   - Introduced mpfclock(4), a driver for the PolarFire SoC MSS
 clock controller.
   - Introduced cdsdhc(4), a driver for the Cadence SD/SDIO/eMMC
 host controller.
   - Introduced mpfiic(4), a driver for the PolarFire SoC MSS I2C
 controller.
   - Introduced mpfgpio(4), a driver for the PolarFire SoC MSS
 GPIO controller.
   - Enabled cduart(4) on arm64.
   - Added mvpinctrl(4) support for the CP115 block found on
 Marvell CN9K SoCs.
   - Added mvclock(4) support for the AP807 block found on Marvell
 CN9K SoCs.
o Changes on other architectures:
   - Enabled uhid(4)/fido(4) on riscv64.
   - Allowed riscv64 installation on a disk with a GPT.
   - Added missing locking to pmap_extract(9) and pmap_unwire(9)
 on arm64 and riscv64.
   - Improved stack unwinding on riscv64 in ddb(4).
   - Fixed kernel stack alignment on riscv64.
   - Fixed RISC-V lld link code when dealing with object files
 created with "ld -b".
   - Made sure nothing can map address zero on RISC-V.
  

Re: Auto layout for disk partitions - a new user's perspective

2022-04-18 Thread Theo de Raadt
the installer creates partition layouts for a variety of _regular_ usage
patterns.

Both of these situations you describe are not the normal pattern.

We don't want to over-allocate space to specific purposes like that.

Other systems do one giant root partition and then avoid these space
issues.  There are downsides with the policy of creating seperate
partitions like we do, so that we can vary mountpoint flat options.
We kind of shrug and cope with it.

James Mintram  wrote:

> Hi. I am new to OpenBSD, so these questions come from my first 
> experience with the system.
> 
> I selected the auto layout option when partitioning my 256GB drive. I have 
> then found issues while doing the following:
> 
> 1) Cloning src from the github mirror and checking it out, completely fills 
> the /usr/src parition.
> 
> 2) Building some ports fail because /usr/local/pobj is not on an wxallowed fs.
> 
> 
> My questions are:
> 
> 1) Should the default /usr/src partition be bigger on large disks?
> 
> 2) Should there be a /usr/local/pobj partition created with correct mount 
> options? (I appreciate building ports is an "advanced" thing to do - but it 
> feels weird having to mess with partition layout after a fresh install just 
> to 
> build them)



Re: Github/Bitbucket free alternative

2022-04-03 Thread Theo de Raadt
Tito Mari Francis Escaño  wrote:

> Hi everyone,
> I'm trying to develop web apps on OpenBSD but Github and even Bitbucket
> seems to think that only Windows and/or Linux are the platforms so I feel
> forced to use VS Code that runs only on those systems.
> Can somebody please point me to alternative free online code repository
> services that I can use with OpenBSD?
> Thanks and stay safe everyone :)

It's almost like some a software ecosystem pandemic is happening.
Stay safe.



Re: user cannot login on -current amd64: ulimit related?

2022-03-23 Thread Theo de Raadt
There was a bug related to rlimits around March 15.  It has been fixed
since.

I think it is a big weird when people using snapshots reports a bug
against week-old code.  Do you think we do nothing for that week?

Mare Dedeu  wrote:

> Hi,
> 
> I am running -current on a thinkpad X270. After an upgrade two days ago I
> cannot login as a normal user (root is fine) via the terminal. The zsh
> shell complains about not having enough memory. Changing shells via chsh
> yields the same result on ksh and bash. I have upgraded again today to the
> latest snapshot but the result is the same.
> 
> I think this can be related to ulimit, but I am not sure. In any case,
> 
> $ ulimit -a
> -t: cpu time (seconds)  unlimited
> -f: file size (blocks)  unlimited
> -d: data seg size (kbytes)  4194304
> -s: stack size (kbytes) 8192
> -c: core file size (blocks) 0
> -m: resident set size (kbytes)  7634548
> -l: locked-in-memory size (kbytes)  7634548
> -u: processes   1310
> -n: file descriptors1024
> 
> Any hint would be appreciated.
> 
> thanks.
> 
> PS: this is my dmesg and login.conf:
> 
> ===
> OpenBSD 7.1-beta (GENERIC.MP) #422: Tue Mar 15 11:28:22 MDT 2022
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8080216064 (7705MB)
> avail mem = 7818051584 (7455MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xbf0dd000 (62 entries)
> bios0: vendor LENOVO version "R0IET43W (1.21 )" date 09/02/2017
> bios0: LENOVO 20HNA004CD
> acpi0 at bios0: ACPI 5.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP UEFI SSDT SSDT HPET APIC MCFG ECDT SSDT SSDT BOOT
> BATB SSDT SSDT SSDT WSMT SSDT SSDT DBGP DBG2 MSDM DMAR ASF! FPDT UEFI
> acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) RP02(S4)
> RP04(S4) RP05(S4) RP06(S4) RP07(S4) RP08(S4) RP09(S4) RP10(S4) RP11(S4)
> RP12(S4) RP13(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpihpet0 at acpi0: 2399 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz, 1596.28 MHz, 06-8e-09
> 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 24MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz, 1491.00 MHz, 06-8e-09
> 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 1 (application processor)
> cpu2: Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz, 1396.75 MHz, 06-8e-09
> cpu2:
> 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu2: smt 1, core 0, package 0
> cpu3 at mainbus0: apid 3 (application processor)
> cpu3: Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz, 1396.75 MHz, 06-8e-09
> cpu3:
> 

Re: 12-hour vs. 24-hour clock format

2022-02-23 Thread Theo de Raadt
So you want this command to behave differently in different environments?
Who wants that unpredicabtility?  I suspect noone wants that.

Your reference to POSIX is irrelevant because "w" is not a POSIX command.

Furthermore that feature creep in POSIX locales is not done by most
programs which do 24-hour clock by default, meaning it cannot force them
do 12-hour clock when requested, so the proposal feels like a one-way
road.

Anyways, it is like you didn't read my reply, I was saying: I don't
think we want to do your proposal.

Svyatoslav Mishyn  wrote:

> (Wed, 23 Feb 09:13) Theo de Raadt:
> > We do not have a firm rule that all programs must use 24-hour clock,
> > and I don't think we should create such a rule either.
> 
> OK, how about then before printing a date to check T_FMT_AMPM[0]?
> But if it were added to all code where approriate, then it would change
> standard behavior to some programs which currently display in 24-hour 
> format...
> so again no. 
> 
> As like in DragonflyBSD/FreeBSD:
> https://gitweb.dragonflybsd.org/dragonfly.git/blob/022bb0a9ed6967bc18e421ed074f5727e49314e0:/usr.bin/w/w.c#l133
> https://cgit.freebsd.org/src/tree/usr.bin/w/w.c?h=2d3725d62acbaca2fe84d43e8fd32ae9fb9a915b#n151
> 
> [0]: 
> https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/basedefs/V1_chap07.html
> 



Re: Updating mrouted in Base

2022-02-23 Thread Theo de Raadt
Stuart Henderson  wrote:

> On 2022/02/23 09:16, Theo de Raadt wrote:
> > Stuart Henderson  wrote:
> > 
> > > On 2022-02-21, Trace the Route  wrote:
> > > > Is it possible to include a newer version of mrouted in the base
> > > > installation of OpenBSD? The existing version of mrouted (v3.8) is
> > > > obviously quite old and lacks functionality found in newer versions.
> > > >
> > > > For example, the existing version of mrouted is not able to bind to
> > > > both ends of a pair(4) interface, whereas the latest version (v4.4)
> > > > has no issue with this.
> > > 
> > > It probably makes more sense to remove it from base. Do you fancy writing
> > > a port so it can be included there instead?
> > 
> > I dunno...
> > 
> > It seems to me that if multicast routing is going to be maintained in our
> > base tree, we probably want base utilities for it.  Otherwise, how would
> > anyone working in base development remember to test it when they make
> > changes?
> 
> Utilities yes, but do we need two different DVMRP daemons, one
> OpenBSD-style and privsepped and the other old and unmaintained?

No, we don't.

But included in the original email was a report that mrouted works better
tham dvmrpd...



Re: Updating mrouted in Base

2022-02-23 Thread Theo de Raadt
Stuart Henderson  wrote:

> On 2022-02-21, Trace the Route  wrote:
> > Is it possible to include a newer version of mrouted in the base
> > installation of OpenBSD? The existing version of mrouted (v3.8) is
> > obviously quite old and lacks functionality found in newer versions.
> >
> > For example, the existing version of mrouted is not able to bind to
> > both ends of a pair(4) interface, whereas the latest version (v4.4)
> > has no issue with this.
> 
> It probably makes more sense to remove it from base. Do you fancy writing
> a port so it can be included there instead?

I dunno...

It seems to me that if multicast routing is going to be maintained in our
base tree, we probably want base utilities for it.  Otherwise, how would
anyone working in base development remember to test it when they make
changes?

Sadly, we don't appear to have a mrouted developer.



Re: 12-hour vs. 24-hour clock format

2022-02-23 Thread Theo de Raadt
Svyatoslav Mishyn  wrote:

> just wondering why are some programs using 12-hour/24-hour clock format
> by default?
> 
> For instance, 12-hour clock format:
> w(1)/uptime(1) 
> Should it be fixed?

We do not have a firm rule that all programs must use 24-hour clock,
and I don't think we should create such a rule either.



Re: Updating mrouted in Base

2022-02-21 Thread Theo de Raadt
Trace the Route  wrote:

> Is it possible to include a newer version of mrouted in the base
> installation of OpenBSD? The existing version of mrouted (v3.8) is
> obviously quite old and lacks functionality found in newer versions.
> 
> For example, the existing version of mrouted is not able to bind to
> both ends of a pair(4) interface, whereas the latest version (v4.4)
> has no issue with this.

I haven't heard of anyone using mrouted in a very long time.

This is an imported daemon which has almost no maintainance or security
work.  No chroot, no pledge, no unveil -- I see no evidence of any privsep
at all!

I also don't see any serious audit/review in the commit logs.

Unfortunately I suspect new code would be similarily weak.  Let me
guess, upstream calls srandom()...



Re: No sound on ThinkPad X220 using current snapshot

2022-02-14 Thread Theo de Raadt
Josh Grosse  wrote:

> On Mon, Feb 14, 2022 at 05:58:37PM +0100, Dirk-Wilhelm Peters wrote:
> > "Theo de Raadt"  wrote:
> > 
> > > > OpenBSD 7.0-current (GENERIC.MP) #325: Thu Feb 10 12:26:12 MST 2022
> > > 
> > > Your subject says "current snapshot".  But then you show a 4-day old
> > > kernel.
> > > 
> > > You can do better.
> > 
> > Yes. Kernel #334 is also silent after returning from suspend mode.
>  
> I have the same X220 hardware.  Bisecting the kernel indicates this
> commit caused the regression.  Tested on the X220 with GENERIC.MP.
> 
> commit ad814436a071b6401bfaf527a709138b9bf992e2 (refs/bisect/bad)
> Author: deraadt 
> Date:   Tue Feb 8 17:25:10 2022 +
> 
> The suspend/resume code is a sticky mess of MI, MD, and ACPI sequencing.
> This splits out the MI sequencing, backing it with per-architecture helper
> functions.  Further steps will be neccesary because ACPI and MD are too
> tightly coupled, but soon we'll be able to use this code for more 
> architectures
> (which depends on figuring out the lowest-level cpu sleeping method)
> ok kettenis

I was meticulous about keeping the order-of-operations the same as before,
but something very subtle has happened.

We need to recall that suspend/resume on some machines has never behaved
perfectly.  Maybe some heisenbug has moved around.  I've been re-reading all
morning and I still can't see any reason.



Re: No sound on ThinkPad X220 using current snapshot

2022-02-14 Thread Theo de Raadt
Dirk-Wilhelm Peters  wrote:

> "Theo de Raadt"  wrote:
> 
> > > OpenBSD 7.0-current (GENERIC.MP) #325: Thu Feb 10 12:26:12 MST 2022
> > 
> > Your subject says "current snapshot".  But then you show a 4-day old
> > kernel.
> > 
> > You can do better.
> 
> Yes. Kernel #334 is also silent after returning from suspend mode.

That number is not a point of reference.  Sorry, I don't have time for
incomplete bug reports.



Re: No sound on ThinkPad X220 using current snapshot

2022-02-14 Thread Theo de Raadt
> OpenBSD 7.0-current (GENERIC.MP) #325: Thu Feb 10 12:26:12 MST 2022

Your subject says "current snapshot".  But then you show a 4-day old
kernel.

You can do better.



Re: Fsck_ffs seems to have trashed /usr/local

2022-02-11 Thread Theo de Raadt
Otto Moerbeek  wrote:

> On Fri, Feb 11, 2022 at 10:09:25PM +0100, Konrad Sowula wrote:
> 
> > Hello,
> > to keep things short, rebooting my vps using 'Server restart' in vultr
> > control panel trashed my /usr/local directory (or at least i suppose 
> > that's all that has been damaged, haven't noticed any changes to 
> > config files thus far).
> > 
> > Upon rebooting awaited me a message akin to:
> > /dev/sd0a (...): UNEXPECTED INCONSISTENCY; RUN fsck_ffs MANUALLY
> > ...
> > Enter path to shell binary: 
> > 
> > thus i ran `fsck_ffs /dev/sd0a` in shell and here I am.
> 
> Your subject is wrong. fsck_ffs did not trash your filesystem. It
> could not repair the damage automatically.
> 
> Your report is also useless. What does "here I am" mean? Was fsck_ffs
> able to repair the fs in non-automatic mode? How about providing the
> things it printed/questions it asked on the manual run?
> 
> BTW, /dev/sd0a is your root fs.

Indeed, in particular:

> > /dev/sd0a (...): UNEXPECTED INCONSISTENCY; RUN fsck_ffs MANUALLY

If fsck prints this, it has not done a single write operation.  fsck
has only read, and decided it cannot perform an automatic repair.

When fsck is run in manual mode, it asks questions, and puts part the
responsibility for some undermined handling in the hands of the user
(who is root).  Most of the time that goes well.  Sometimes it doesn't.

There are papers about fsck design, easy to search for.



Re: What happened to www/art on CVSWeb? Why is it empty?

2022-02-10 Thread Theo de Raadt
It is empty because we have other more important things to take care of.

Our sincere apologies for the inconvenience.



Kacper Wilgus  wrote:

> I tried to download some artwork from these pages:
> 
> https://www.openbsd.org/art1.html
> https://www.openbsd.org/art2.html
> https://www.openbsd.org/art3.html
> 
> But only the first one has an image, the rest of them give me 404
> errors and I swear they used to be there just a year ago. And the
> wayback machine proves this. Was it an error, or copyright issues?
> It seems wierd it was just snapped out of existence without any warning.
> 
> -- 
> Kacper Wilgus 
> 



Re: SSL write error: certificate verification failed: certificate has expired

2022-02-02 Thread Theo de Raadt
Your machine's time is wrong.


Yogendra Kumar Chaudhary  wrote:

> Good morning,
> 
> I am facing the following error while using pkg_add on OpenBSD 6.2.
> 
> FTP: SSL write error: certificate verification failed: certificate has
> expired
> 
> 1. I have tried with multiple mirrors sites but the outcome is the same.
> 
> 2. My system time is up to date.
> 
> Please guide me on how to resolve this issue.
> 
> -- 
> Thanks and Regards
> Yogendra Kumar
> National Institute of Technology,
> Karnataka



Re: awk doesn't build on armv7

2022-02-02 Thread Theo de Raadt
Builds fine for me.

Jan Stary  wrote:

> This is current/armv7 on a Beagle Bone  Black (dmesg below).
> make build just failed in usr.bin/awk with
> 
> ===> usr.bin/awk
> yacc -o awkgram.tab.c -d /usr/src/usr.bin/awk/awkgram.y
> /usr/src/usr.bin/awk/awkgram.y: yacc finds 62 shift/reduce conflicts
> /usr/src/usr.bin/awk/awkgram.y: yacc finds 87 reduce/reduce conflicts
> cc -O2 -pipe  -I. -I/usr/src/usr.bin/awk -DHAS_ISBLANK -DNDEBUG 
> -Werror-implicit-function-declaration -MD -MP  -c awkgram.tab.c
> In file included from /usr/src/usr.bin/awk/awkgram.y:29:
> /usr/src/usr.bin/awk/awk.h:32:10: fatal error: 'stdnoreturn.h' file not found
> #include 
>  ^~~
> 1 error generated.
> *** Error 1 in usr.bin/awk (:87 'awkgram.tab.o')
> 
> The include in awk.h happens like this:
> 
>   #if __STDC_VERSION__ <= 199901L
>   #define noreturn __dead
>   #else
>   #include 
>   #endif
> 
> and stdnoreturn.h indeed does not exist.
> 
> But the same compiles fine on amd64.
> 
>   Jan
> 
> 
> OpenBSD 7.0-current (GENERIC) #0: Mon Jan 31 17:41:46 CET 2022
> h...@bbb.stare.cz:/usr/src/sys/arch/armv7/compile/GENERIC
> real mem  = 484184064 (461MB)
> avail mem = 463847424 (442MB)
> random: good seed from bootblocks
> mainbus0 at root: TI AM335x BeagleBone Black
> cpu0 at mainbus0 mpidr 0: ARM Cortex-A8 r3p2
> cpu0: 32KB 64b/line 4-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache
> cpu0: 256KB 64b/line 8-way L2 cache
> omap0 at mainbus0
> prcm0 at omap0 rev 0.2
> dmtimer0 at omap0 rev 3.1
> dmtimer1 at omap0 rev 3.1
> omsysc0 at mainbus0: "target-module"
> omsysc1 at omsysc0: "target-module"
> "pmu" at omsysc1 not configured
> simplebus0 at mainbus0: "ocp"
> intc0 at simplebus0 rev 5.0
> omsysc2 at simplebus0: "target-module"
> simplebus1 at simplebus0: "interconnect"
> simplebus2 at simplebus1: "segment"
> simplebus3 at simplebus1: "segment"
> omsysc3 at simplebus3: "target-module"
> "cpu" at omsysc3 not configured
> simplebus4 at simplebus1: "segment"
> omsysc4 at simplebus4: "target-module"
> simplebus5 at omsysc4: "prcm"
> omcm0 at simplebus5: "per-cm"
> omclock0 at omcm0: "l4ls-clkctrl"
> omclock1 at omcm0: "l3s-clkctrl"
> omclock2 at omcm0: "l3-clkctrl"
> omclock3 at omcm0: "l4hs-clkctrl"
> omclock4 at omcm0: "pruss-ocp-clkctrl"
> omclock5 at omcm0: "cpsw-125mhz-clkctrl"
> omclock6 at omcm0: "lcdc-clkctrl"
> omclock7 at omcm0: "clk-24mhz-clkctrl"
> omcm1 at simplebus5: "wkup-cm"
> omclock8 at omcm1: "l4-wkup-clkctrl"
> omclock9 at omcm1: "l3-aon-clkctrl"
> omclock10 at omcm1: "l4-wkup-aon-clkctrl"
> omcm2 at simplebus5: "mpu-cm"
> omclock11 at omcm2: "mpu-clkctrl"
> omcm3 at simplebus5: "l4-rtc-cm"
> omclock12 at omcm3: "l4-rtc-clkctrl"
> omcm4 at simplebus5: "gfx-l3-cm"
> omclock13 at omcm4: "gfx-l3-clkctrl"
> omcm5 at simplebus5: "l4-cefuse-cm"
> omclock14 at omcm5: "l4-cefuse-clkctrl"
> "prm" at simplebus5 not configured
> "prm" at simplebus5 not configured
> "prm" at simplebus5 not configured
> "prm" at simplebus5 not configured
> "prm" at simplebus5 not configured
> "prm" at simplebus5 not configured
> "prm" at simplebus5 not configured
> omsysc5 at simplebus4: "target-module"
> simplebus6 at omsysc5: "scm"
> syscon0 at simplebus6: "scm_conf"
> pinctrl0 at simplebus6
> "control" at simplebus6 not configured
> "wkup_m3_ipc" at simplebus6 not configured
> "dma-router" at simplebus6 not configured
> omsysc6 at simplebus4: "target-module"
> omgpio0 at omsysc6: rev 0.1
> gpio0 at omgpio0: 32 pins
> omsysc7 at simplebus4: "target-module"
> com0 at omsysc7: ti16750, 64 byte fifo
> com0: console
> omsysc8 at simplebus4: "target-module"
> tiiic0 at omsysc8 rev 0.11
> iic0 at tiiic0
> "ti,tps65217" at iic0 addr 0x24 not configured
> "atmel,24c256" at iic0 addr 0x50 not configured
> nxphdmi0 at iic0 addr 0x70: rev 0x0301
> nxphdmi0: no display detected
> omsysc9 at simplebus4: "target-module"
> omsysc10 at simplebus4: "target-module"
> "timer" at omsysc10 not configured
> omsysc11 at simplebus4: "target-module"
> omdog0 at omsysc11 rev 0.1
> omsysc12 at simplebus4: "target-module"
> "rtc" at omsysc12 not configured
> simplebus7 at simplebus0: "interconnect"
> simplebus8 at simplebus7: "segment"
> omsysc13 at simplebus8: "target-module"
> omsysc14 at simplebus8: "target-module"
> omsysc15 at simplebus8: "target-module"
> omsysc16 at simplebus8: "target-module"
> omsysc17 at simplebus8: "target-module"
> "mcasp" at omsysc17 not configured
> omsysc18 at simplebus8: "target-module"
> omsysc19 at simplebus8: "target-module"
> "timer" at omsysc19 not configured
> omsysc20 at simplebus8: "target-module"
> "timer" at omsysc20 not configured
> omsysc21 at simplebus8: "target-module"
> "timer" at omsysc21 not configured
> omsysc22 at simplebus8: "target-module"
> "timer" at omsysc22 not configured
> omsysc23 at simplebus8: "target-module"
> "timer" at omsysc23 not configured
> omsysc24 at simplebus8: "target-module"
> "timer" at omsysc24 not configured
> omsysc25 at simplebus8: 

Re: Potential mirror sync issue with snapshot packages

2022-01-24 Thread Theo de Raadt
Ricky Cintron  wrote:

> Before upgrading my -current system Saturday evening (Jan. 22), I noticed that
> the snapshot packages for amd64 were partially synced. The first half are from
> the 21st, while the second half are from the 20th. I checked the Fastly cdn, 
> the
> Cloudflare cdn, and ftp.openbsd.org, and all 3 are in a similar state. I 
> figured
> it was a temporary issue, so I decided to wait until the packages were 
> updated,
> but nothing has changed as of Monday evening (Jan. 24).
> 
> I haven't seen anything related to this mentioned on the lists, so I'm just
> wondering if this is a known issue.
> 

Should be fixed now, or in the process of fixing itself.



Re: ttyflags hangs on Dell PowerEdge R200

2022-01-15 Thread Theo de Raadt
I think the bug is that com_acpi_match() should call ic/com.c comprobe1(),
which verifies that an actual chip exists, rather than simply trusting the
ACPI tables.  If attach succeeds, open and ioctl become callable, and at
that point if real hardware isn't present, the driver reacts very poorly.




Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"

2022-01-14 Thread Theo de Raadt
OpenBSD default is for /etc/ssl/ to be root:wheel u+w,a+rx

Harold, you broke your own machine.


Stuart Henderson  wrote:

> On 2022-01-14, Harald Dunkel  wrote:
> > On 2022-01-14 10:42:56, Harald Dunkel wrote:
> >> 
> >> Hi folks,
> >> 
> >> trying to upgrade the installed packages I get
> >> 
> >> # pkg_add -u
> >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages-stable/amd64/: TLS 
> >> connect failure: failed to open CA file '/etc/ssl/cert.pem': Permission 
> >> denied
> >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: TLS connect 
> >> failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied
> >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: empty
> >> Couldn't find updates for bash-5.1.8 bzip2-1.0.8p0 ...
> >
> > chmod a+rx /etc/ssl
> >
> > did the trick, but this doesn't look reasonable.
> 
> Why would that not be reasonable? It's setting it back to the default
> permissions after whatever change you've made to it.
> 
> There are various system daemons and utilities (including sysupgrade,
> syspatch, pkg_add, ntpd, rpki-client, syslogd, smtpd) that will
> want to make TLS connections as a non-root user, at least in some
> configurations. Some of these may open cert.pem while they still have
> privileges but not always.
> 
> > In general, if there is a permission problem due to file system
> > access bits, then it would be wise to include euid and egid in
> > the error message.
> 
> Not sure if that helps really. If you'd seen that, maybe you would have
> fixed it for _pkgfetch and not noticed some other software that would
> like to use it..
> 
> 



Re: Error on xenocara.tar.gz extraction

2022-01-13 Thread Theo de Raadt
It is just a warning, you can ignore it.

I am not going to change my processes to ship a tar file without "."

Rob Whitlock  wrote:

> Attempting to extract xenocara.tar.gz while avoiding root proviliges as
> described here https://www.openbsd.org/faq/faq5.html#wsrc, I ran into an
> error, shown below:
> 
> 0 thinkpad$ pwd
> /usr/xenocara
> 0 thinkpad$ ls -a
> 
> .  ..
> 0 thinkpad$ tar xzf /home/rob/openbsd_files/7.0/xenocara.tar.gz
> 
> tar: Access/modification time set failed on: .: Operation not permitted
> 1 thinkpad$ ls -a
> .  3RDPARTY   Makefile   data   docfont   share
> .. CVSREADME dist   driver libutil
> .gitignore MODULESappdistribetcproto  xserver
> 0 thinkpad$ cd ..
> 0 thinkpad$ ls -ld xenocara
> drwxrwxr-x  16 root   wsrc512 Jan 12 21:43 xenocara
> 0 thinkpad$ id
> uid=1001(rob) gid=1001 groups=1001, 0(wheel), 9(wsrc)
> 0 thinkpad$
> 
> Running ktrace on tar shows that tar is trying to set the mtime of ., which
> corresponds to /usr/xenocara, with the function futimens, which fails.
> According to the man page for futimens, if the times argument is non-NULL,
> which is the case here, then the caller must be the owner of the file or
> the superuser. For an unprivileged user, this is not the case, as, although
> /usr/xenocara has group wsrc, it has owner root.
> 
> Running tar tzf xenocara.tar.gz shows an entry for . which seems to be
> causing this problem. If you instead run tar xzf xenocara.tar.gz -s
> '/^\.$//' to omit only the . entry when extracting, there is no more error.
> There is a side effect to adding this -s option, which is that
> /usr/xenocara's mtime gets updated to the time the tarball extraction took
> place, as opposed to the time that was recorded for . in the tarball. I
> don't know whether updating /usr/xenocara to the mtime that was recorded in
> the tarball was intentional behavior or not.
> 
> If updating the mtime of /usr/xenocara was not intentional behavior, it
> would seem to me that the fix for this problem would be to not include the
> . directory when making the tarball xenocara.tar.gz. I was unable to locate
> any code that was responsible for creating xenocara.tar.gz so I have not
> included a diff. If anybody could tell me where that code is then that
> would be appreciated.
> 
> As another issue, extracting ports.tar.gz as a non-privileged user in /usr,
> as described in the document whose address is given above, results in
> failure due to lack of permission, as a normal user does not have access to
> create the /usr/ports directory.
> 
> I am running a snapshot of OpenBSD 7.0 that is only a few days old.



Re: auto_upgrade.conf ignored?

2022-01-07 Thread Theo de Raadt
Jan Stary  wrote:

> > 1) If you edit that file yourself,
> 
> Is there any other way this file is supposed to come to existence
> (except the one containing the default answers, which sysupgrade
> writes itself) beside editing it by hand?

sysupgrade creates it, exactly as it wants it to be.

If you edit it, you are no longer using sysupgrade.  You are on your
own.

> > how can you say you are using sysupgrade?
> 
> Perhaps I was unclear: I took the response log of a sysupgrade run
> (as mailed afterwards) and created /auto_upgrade.conf from it.
> I am not touching sysupgrade itself, obviously.

Ah, you edited the file.  

Then you are not using sysupgrade.  You are using your own process, and
you need to understand all the consequences.  misc@ owes you nothing.

> > sysupgrade manages the whole process.  When you subvert a program, you are
> > responsible.
> 
> Is creating /auto_upgrade.conf considered subversion?

No.  You can create your own /auto_upgrade.conf

But if you create it, it is not sysupgrade that created it

If you create a file which doesn't work, have you considered blaming the
creator of the file?

> > Especially when it is not documented what will happen.
> 
> sysupgrade(8) says
> 
>  /auto_upgrade.conf  Response file for the ramdisk kernel.
> 
> I agree that only documents the file is recognized to exist.

But you are not using sysupgrade.  Why do you refer to the sysupgrade
manual page?  You have placed *your own ideas* of what should be in
that file.

sysupgrade does not use ambigious question=answer lines.

But you do.  You are acting completely clueless here.

> > 2) You assume you can provide multiple answers to a question --
> >how do you expect this to work?
> 
> I naively assumed the undocumented file replaces
> the interactive dialogue of a bsd.rd upgrade. My bad.

If it was replacing the dialogue 1:1, then the lines would only need to
be answers.  But every line is question = answer.

Obviously, the parsing of this won't keep-state then, and it acts as either
first-match or last-match, so you cannot repeat questions.

> > 3) see _autorespond in install.sub
> 
> Thank you.
> 
> My original problem is that some machines are small/slow enough
> to warant not having e.g. the X sets, and I am trying to persuade
> sysupgrade to do that. Is there a user-visible way to do that
> via /auto_upgrade.conf?

what the hell does "slow" have to do with installing files you
won't use?

Buy a bigger machine.  Or use Linux, which will mean you need to buy
a bigger machine.  I'm dead serious -- OpenBSD is a small enough operating
system that we don't need to bend-over for people who want to use it
on ridiculously miserly systems.  We have tradeoffs to make and I see NO
POINT in focusing on people who's machines are that small.




Re: auto_upgrade.conf ignored?

2022-01-07 Thread Theo de Raadt
Jan Stary  wrote:

> On Jan 07 10:52:51, dera...@openbsd.org wrote:
> >   Set name(s) = -x*
> >   Set name(s) = done
> > 
> > By giving two seperate answers to the same question, you are making a
> > gigantic assumption.
> 
> Yes, that's probably wrong.
> But the same happens with just
> 
>   Set name(s) = -x*
> 
> Is the grammar of th eauto update response discribed somewhere?
> Naively, I just tweaked the response log of a previous sysupgrade.

1) If you edit that file yourself, how can you say you are using sysupgrade?
sysupgrade manages the whole process.  When you subvert a program, you are
responsible.  Especially when it is not documented what will happen.

2) You assume you can provide multiple answers to a question --
   how do you expect this to work?

3) see _autorespond in install.sub



Re: auto_upgrade.conf ignored?

2022-01-07 Thread Theo de Raadt
  Set name(s) = -x*
  Set name(s) = done

By giving two seperate answers to the same question, you are making a
gigantic assumption.



Re: Can OpenBSD use more than one fdisk partition?

2022-01-06 Thread Theo de Raadt
Marek Kozlowski  wrote:

> *Normally* only one fdisk partition. How about *abnormally*? I mean:
>  is it technically possible to place (and use!) more than one OpenBSD 
> partition for a drive?

No.



Re: Can OpenBSD use more than one fdisk partition?

2022-01-06 Thread Theo de Raadt
Crystal Kolipe  wrote:

> On Thu, Jan 06, 2022 at 01:27:25PM +, Stuart Henderson wrote:
> > On 2022/01/06 09:56, Crystal Kolipe wrote:
> > > On Thu, Jan 06, 2022 at 11:11:30AM -, Stuart Henderson wrote:
> > > > You can create more than one "fdisk partition" but there's not much
> > > > point in doing so. It doesn't give you any extra "disklabel partitions".
> > > 
> > > There is a niche use case for multiple OpenBSD MBR partitions, though:
> > 
> > I said "not much" rather than "no" for a reason. I didn't think it was
> > really helpful to go into more details of things which are possible but
> > inadvisable.
> 
> I agree that such a partitioning scheme isn't very useful in practice, but
> I think the example helps people to understand that the BSD disklabel does
> not live "inside" the OpenBSD MBR partition.
> 
> There seems to be this kind of urban myth that the MBR partitioning scheme
> is treated as the "overall" disk layout and that the OpenBSD partition is
> then "sub-divided" into pieces which only matter to OpenBSD.  Then people
> start making wrong assumptions, such as that the disklabel is always in
> the same location, that it's portable between architectures, that a disk
> without an OpenBSD MBR partition can't have a disklabel, and that changes
> to the MBR partitions will or should be reflected in the disklabel
> automatically.
> 

and then there is sparc64, with *five* possible disk descriptive layouts,
some of which don't even have a "struct disklabel" on the disk.

At some point we have to step back and say: We've written a scheme that works
for us. Who cares what inaccuracies people believe?



Re: Doku Wiki femail?

2022-01-03 Thread Theo de Raadt
Mihai Popescu  wrote:

> > It is an old less-secure practice ...
> 
> I use to think about security as secure / insecure (not secure). Is it ok
> to use grades like less secure, more secure, etc.?

Let me provide a better answer.

When you use fewer simple ingredients, you can judge the interactions
between the the simple components better, and have a more clear
understanding that you have achieved your objectives... and not have a
pile of curious latent behaviours as well.

The crucial behaviour we call "security" really just means the software
performs the intended goal only, and cannot be convinced to perform
additional unintended behaviours.

People are putting random things into chroot, hoping that it works fine.

Now people are going to say, surely ksh is not complicated.  It
needs nothing.  If my environment works once in test for my specific
test case, it will work the other million times without flaw.  I believe
that is incompetent delusion.

If you don't know precisely what you putting into the mixing bowl and
why you shouldn't be making a cake, get a job in sales or something and
save us all the grief.  Or go ahead, use a bunch of draino and some
matchheads, but don't share it.




Re: Doku Wiki femail?

2022-01-03 Thread Theo de Raadt
Mihai Popescu  wrote:

> > It is an old less-secure practice ...
> 
> I use to think about security as secure / insecure (not secure). Is it ok
> to use grades like less secure, more secure, etc.?

chroot is used to create a really crappy privsep.

Worse than duct tape in the sun.




Re: Doku Wiki femail?

2022-01-03 Thread Theo de Raadt
Thomas Bohl  wrote:

> Hello,
> 
> > After several tries, i think the problem is the interpretation, in
> > Universal Language; usually used in OBSD, it could be:
> > Write this 
> > Do this 
> >   But, in this case; there are not commands!
> > Please, let me ask you, How to add /bin/sh to the chroot?
> > How to add host? resolv.conf? and femail.conf?
> > How to create /var/www/etc/other files?
> >  From where do i have to create every thing?
> 
> That is what I always do for httpd chroot:
> 
> # mkdir -p /var/www/usr/local/share/icu/
> # mkdir -p /var/www/etc/ssl/
> # cp -r /usr/local/share/icu/* /var/www/usr/local/share/icu/
> # cp /etc/ssl/openssl.cnf /var/www/etc/ssl/
> # cp /etc/ssl/cert.pem /var/www/etc/ssl/
> # cp /etc/{hosts,resolv.conf,localtime} /var/www/etc/
> # chown -R root:daemon /var/www/etc/ssl
> # chown -R root:daemon /var/www/usr/
> 
> 
> I haven't had the need for /bin/sh in chroot, so this is untested. But
> judging by
> $ ldd /bin/sh
> 
> # mkdir /var/www/bin/
> # cp /bin/sh /var/www/bin/
> 
> should be it.

No.  Programs don't run in a vacuum.  They need various things in
the filesystem.

I do not think we should document what those things are, because
the practice of running binaries inside such chroot spaces is highly
discouraged.  It is an old less-secure practice for a less-secure
era and we don't need to help people re-create it.  When people
believe they really need to do so, we provide the tools they need to
learn what is required:  ktrace & kdump.  And I really mean they need
to learn to use those tools.  If they don't understand the low-level
system behaviours that happen, then why the HELL do they think they can
use chroot safely?



Re: acpibat confusion

2021-12-25 Thread Theo de Raadt
In acpibat_notify(), if acpibat_getbst() or acpibat_getbix() return
some sort of silent failure, such an error will be ignored and the
acpibat_refresh() will reprocess the same data to export to sensors.

In mosts cases replaying the same data will result in the same sensors,
but maybe some converter is aware of some global value like time.

ACPI has debug code.  You have the source.  You know the next step...



Jan Stary  wrote:

> This is current/amd64 on a Thinkpad T410 (dmesg below).
> I am reading the cpu temperature and the battery charge
> periodically from 
> 
>   sysctl hw.sensors.cpu0.temp0
>   sysctl hw.sensors.acpibat0.amphour3
> 
> and keeping a simple log (timestamp, temp, charge - see below).
> 
> It seems that the meaning of the acpibat values such as
> 
>   hw.sensors.acpibat0.amphour3=3.90 Ah (remaining capacity), OK
> 
> changes with time: namely, sometimes it rescales by a factor of ten.
> See below for a jump from 04.32 to 43.08 (discharging)
> or a jump from 32.44 to 04.20 (charging).
> 
> Is this known? Or a known quirk of the T410?
> 
>   Jan
> 
> 
> hw.machine=amd64
> hw.model=Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz
> hw.ncpu=4
> hw.byteorder=1234
> hw.pagesize=4096
> hw.disknames=sd0:7e642c4522750e51
> hw.diskcount=1
> hw.sensors.cpu0.temp0=32.00 degC
> hw.sensors.acpibtn0.indicator0=On (lid open)
> hw.sensors.acpibat0.volt0=10.80 VDC (voltage)
> hw.sensors.acpibat0.volt1=11.93 VDC (current voltage)
> hw.sensors.acpibat0.current0=1.24 A (rate)
> hw.sensors.acpibat0.amphour0=4.53 Ah (last full capacity)
> hw.sensors.acpibat0.amphour1=0.23 Ah (warning capacity)
> hw.sensors.acpibat0.amphour2=0.02 Ah (low capacity)
> hw.sensors.acpibat0.amphour3=3.83 Ah (remaining capacity), OK
> hw.sensors.acpibat0.amphour4=4.75 Ah (design capacity)
> hw.sensors.acpibat0.raw0=1 (battery discharging), OK
> hw.sensors.acpiac0.indicator0=Off (power supply)
> hw.sensors.acpithinkpad0.fan0=1794 RPM
> hw.sensors.acpithinkpad0.indicator0=Off (port replicator), UNKNOWN
> hw.sensors.acpitz0.temp0=41.00 degC (zone temperature)
> hw.sensors.itherm0.temp1=33.00 degC (Core 1)
> hw.sensors.itherm0.temp4=41.00 degC (CPU/GPU Max temp)
> hw.sensors.itherm0.temp9=41.00 degC (GPU/Memory controller abs.)
> hw.sensors.itherm0.temp10=59.00 degC (PCH abs.)
> hw.sensors.itherm0.power0=5.00 W (CPU power consumption)
> hw.sensors.aps0.temp0=35.00 degC
> hw.sensors.aps0.temp1=35.00 degC
> hw.sensors.aps0.indicator0=On (Keyboard Active)
> hw.sensors.aps0.indicator1=Off (Mouse Active)
> hw.sensors.aps0.indicator2=On (Lid Open)
> hw.sensors.aps0.raw0=507 (X_ACCEL)
> hw.sensors.aps0.raw1=515 (Y_ACCEL)
> hw.sensors.aps0.raw2=507 (X_VAR)
> hw.sensors.aps0.raw3=515 (Y_VAR)
> hw.cpuspeed=1199
> hw.setperf=0
> hw.vendor=LENOVO
> hw.product=2537BN8
> hw.version=ThinkPad T410
> hw.serialno=R8H3FF8
> hw.uuid=75c16301-5151-11cb-96df-9039995c4aef
> hw.physmem=8357658624
> hw.usermem=8342351872
> hw.ncpufound=4
> hw.allowpowerdown=1
> hw.perfpolicy=auto
> hw.smt=0
> hw.ncpuonline=4
> hw.power=0
> 
> 
> 
> OpenBSD 7.0-current (GENERIC.MP) #0: Thu Dec 23 16:24:56 CET 2021
> h...@t410.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8357658624 (7970MB)
> avail mem = 8088375296 (7713MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe0010 (78 entries)
> bios0: vendor LENOVO version "6IET75WW (1.35 )" date 02/01/2011
> bios0: LENOVO 2537BN8
> acpi0 at bios0: ACPI 4.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET ASF! SLIC BOOT SSDT TCPA 
> SSDT SSDT SSDT
> acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP1(S4) EXP2(S4) EXP3(S4) 
> EXP4(S4) EXP5(S4) EHC1(S3) EHC2(S3) HDEF(S4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpiec0 at acpi0
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz, 1197.19 MHz, 06-25-05
> 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
> cpu0: 256KB 64b/line 8-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 132MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz, 1197.00 MHz, 06-25-05
> 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
> cpu1: 256KB 64b/line 

Re: how to reload date from ntpd

2021-12-25 Thread Theo de Raadt
ntpd is started early because there are services that work better with
accurate time.  In most cases, ntpd will very quickly build accurate clock,
and those services run better.

In some cases, people build situations which challenge ntpd's fast startup.
Especially broken networks.

Because this can happen, ntpd contains code which kind of retries DNS to IP
translations.

It seems to work for me, in the situations where I build semi-broken networks.

I never delete lines in the stock ntpd.conf.  I only add additional lines.



ue...@danwin1210.de wrote:

> How can I reload date from ntpd after boot?
> And how can I do it automatically after dnscrypt_proxy service started
> Port: dnscrypt-proxy
> fp$ date
> Wed Dec 22 08:10:38 CET 2021
> fp$ doas rcctl restart ntpd
> ntpd(ok)
> ntpd(ok)
> fp$ date
> Wed Dec 22 08:10:48 CET 2021
> 
> I want to reload time from ntpd after dnscrypt_proxy is started because
> it's local DNS server and when it's not started ntpd can't resolve
> hostnames.
> 
> fp$ cat /etc/resolv.conf
> nameserver 127.0.0.1
> 
> fp$ doas rcctl order ntpd dnscrypt_proxy
> rcctl: ntpd is not a pkg script
> fp$ doas rcctl order dnscrypt_proxy ntpd
> rcctl: ntpd is not a pkg script
> 
> 
> fp$ cat /etc/rc.d/dnscrypt_proxy
> #!/bin/ksh
> #
> # $OpenBSD: dnscrypt_proxy.rc,v 1.5 2018/10/16 14:55:02 bket Exp $
> 
> daemon="/usr/local/bin/dnscrypt-proxy"
> daemon_flags="-config /etc/dnscrypt-proxy.toml"
> 
> . /etc/rc.d/rc.subr
> 
> pexp="${daemon}${daemon_flags:+ ${daemon_flags}}.*"
> 
> rc_bg=YES
> rc_reload=NO
> 
> rc_cmd $1
> 
> 
> 



Re: Is fw_update documentation outdated?

2021-12-25 Thread Theo de Raadt
fw_update is being replaced with a new program, and this is being tested
in snapshots to ensure we have coverage all all circumstances.

The new program is capable of updating firmwares while in the bsd.rd
install/upgrade phase.  This means some firmwares (specially *drm firmwares)
will get updated then, rather than after the reboot.  This means noone needs
a 2nd reboot to activate those firmwares.

Some behaviours of the existing program may not survive, and others may
get changes.  It isn't finished yet, when it is, then documentation will
be updated.

Alexander  wrote:

> Hi all,
> 
> I just wanted to check for new firmware versions:
> 
> $ fw_update -n
> fw_update: unknown option -- -n
> usage:  fw_update [-d | -D] [-av] [-p path] [driver | file ...]
> 
> This used to work and is still documented like this in
> 
> $ man 8 fw_update
> [...]
>  -n  Dry run.  Do not actually install or update any firmware
>  and whether it appears to be required by a driver.
> [...]
> (also https://man.openbsd.org/fw_update)
> 
> But /usr/sbin/fw_update does not contain this option anymore and
> consequently produces the error above.
> This mismatch puzzles me a bit and I'm even more confused when looking
> at https://cvsweb.openbsd.org/src/usr.sbin/fw_update/ which has been in
> the attic for the last 6 years.
> 
> I'm guessing I'm just uninformed and don't understand CVSweb but I'd
> like to learn, so:
> Is the documentation for fw_update outdated?
> Where do I actually find the version history of the fw_update that is
> installed on my system in CVSweb?
> 
> My system:
> $ head -1 /etc/motd
> OpenBSD 7.0-current (GENERIC.MP) #200: Fri Dec 24 22:15:01 MST 2021
> 
> Thanks in advance.
> 
> Best regards,
> Alexander
> 



Re: Disk partition not recognized

2021-12-23 Thread Theo de Raadt
Rob Whitlock  wrote:

> On Thu, Dec 23, 2021 at 1:15 AM Theo de Raadt  wrote:
> >
> > Crystal Kolipe  wrote:
> >
> > > On Tue, Dec 21, 2021 at 06:04:28PM -0500, Rob Whitlock wrote:
> > > > A problem seems to be that there is no disklabel entry for the ExFAT
> > > > partition.
> > >
> > > You probably wrote a BSD disklabel to the disk before creating the
> ExFAT partition.
> > >
> > > If there is no on-disk disklabel, the kernel will create one in memory
> based on information from other partitioning schemes, (MBR, GPT).  So in
> this case, as you change those MBR or GPT partitions, those changes will be
> reflected in the disklabel that the kernel sees.
> > >
> > > Once you actually write a disklabel to the disk, that on-disk disklabel
> is then used in place of calculating one each time the disk is attached,
> and the automatic parsing of MBR and GPT partition information stops.
> > >
> > > To solve your problem, you need to add the details of the ExFAT
> partition to the BSD disklabel.  You can either do that manually with the
> disklabel command, or since you do not have any OpenBSD partitions on the
> disk, you could overwrite the on-disk disklabel, allow the kernel to
> generate one automatically with the correct information, then optionally
> force it to be written to the disk by running disklabel and entering 'w' at
> the interactive prompt.
> >
> > This can be investigated with
> >
> >  disklabel -d
> >
> > (BTW, when the disklabel is constructed from other information on the
> disk,
> > we call it a "spoofed label")
> 
> I would like to avoid modifying the data on the disk. Is there a way to use
> disklabel to update the in-core copy of the disklabel with a spoofed label,
> without also writing it to disk? I see in the disklabel(5) manual page that
> the DIOCSDINFO ioctl updates the in-core copy, so it seems it should be
> technically possible, but I don't see how to do it with the disklabel(8)
> program. My understanding of disklabel -d is that it gives you a default
> disklabel to start with, but does not affect how or where the disklabel is
> written.

disklabel -d is a read operation.

You can look at what it reads, and seperately add partitions and write back
the label.



Re: Disk partition not recognized

2021-12-22 Thread Theo de Raadt
Crystal Kolipe  wrote:

> On Tue, Dec 21, 2021 at 06:04:28PM -0500, Rob Whitlock wrote:
> > A problem seems to be that there is no disklabel entry for the ExFAT
> > partition.
> 
> You probably wrote a BSD disklabel to the disk before creating the ExFAT 
> partition.
> 
> If there is no on-disk disklabel, the kernel will create one in memory based 
> on information from other partitioning schemes, (MBR, GPT).  So in this case, 
> as you change those MBR or GPT partitions, those changes will be reflected in 
> the disklabel that the kernel sees.
> 
> Once you actually write a disklabel to the disk, that on-disk disklabel is 
> then used in place of calculating one each time the disk is attached, and the 
> automatic parsing of MBR and GPT partition information stops.
> 
> To solve your problem, you need to add the details of the ExFAT partition to 
> the BSD disklabel.  You can either do that manually with the disklabel 
> command, or since you do not have any OpenBSD partitions on the disk, you 
> could overwrite the on-disk disklabel, allow the kernel to generate one 
> automatically with the correct information, then optionally force it to be 
> written to the disk by running disklabel and entering 'w' at the interactive 
> prompt.

This can be investigated with

 disklabel -d

(BTW, when the disklabel is constructed from other information on the disk,
we call it a "spoofed label")



Re: Disk partition not recognized

2021-12-22 Thread Theo de Raadt
James Cook  wrote:

> I thought the disklabel lives at the start of the OpenBSD partition.

That is incorrect.



Re: Profiling ifconfig

2021-12-16 Thread Theo de Raadt
Claudio Jeker  wrote:

> On Thu, Dec 16, 2021 at 03:55:43PM +0800, Vladimir Nikishkin wrote:
> > Hello, everyone
> > 
> > Recently I had a problem: my system is losing network connectivity,
> > although the interface (vio0 on KVM) seemed up. Restarting the
> > connection with `ifconfig vio0 down` and `ifconfig vio0 up` restores the
> > connection.
> > 
> > However, when I timed the execution, I found that the second `up` can
> > take up to 15 minutes. (Hugely unexpected!) To find out where the
> > program is waiting, I decided to recompile ifconfig from source with
> > debugging and profiling support.
> > 
> > Slightly adjusting the commands provided by the Makefile, I came up with
> > the following commands:
> > 
> > ```
> > egcc -O0 -g -pg -fPIC  -Werror-implicit-function-declaration  -c ifconfig.c
> > egcc -O0 -g -pg -fPIC  -Werror-implicit-function-declaration  -c brconfig.c
> > egcc -O0 -g -pg -fPIC  -Werror-implicit-function-declaration  -c sff.c
> > egcc  -g -pg -shared -pie -o ifconfig ifconfig.o brconfig.o sff.o -lc -pg
> > ```
> > 
> > However, when I run ./ifconfig compiled like this, I am getting (besides
> > the output of ifconfig itself) the following error message:
> > 
> > ```
> > gmon.out: No such file or directory
> > ```
> > 
> > I find this unexpected. Compiling and linking a simple helloworld with
> > -pg -g seems to be working fine, and gmon.out is produced as expected.
> > 
> > What am I doing wrong? Is there something specific that needs to be
> > permitted to profile ifconfig?
> 
> I doubt the problem is in ifconfig(8) itself but more an ioctl that takes
> long to finish. Anyway for prfiling to work you need to neuter unveil() in
> ifconfig. e.g. by changing the code. With unveil on the gmon.out file
> written in the atexit handler can't be created.

Wrong tool being used to debug a userland program.  It is better to attach
a debugger to a -g executable.  Or use ktrace -di with kdump, to figure out
what system calls it is stuck in.

And I suspect you will quickly decide there is no problem in ifconfig..



Re: Missing action list in lesskey man page

2021-12-06 Thread Theo de Raadt
Ingo Schwarze  wrote:

> >> I'd much prefer to have
> >> the actions explained in the lesskey(1) man page.
> 
> No way.  Copying half of the less(1) manual to the lesskey(1) manual
> would result in a maintenance nightmare.

I agree.  This is not the first time one has to read two related pages
to gain understanding, rather than reading one monster combined or
duplicated page -- which can muddle up other learning patterns.

> >>> however we still import less. i'd want to make sure that's
> >>> not stepping on anyone's toes to make local changes.
> 
> We forked the "less" program and made many extensive changes.
> I think we are free to improve the documentation as we see fit.

The main reason there was little pushback against forking less is
because upstream releases were changing features regularily and we
wanted to get off that train.  We want a simpler program that does what
it is supposed to do, doesn't adopt new features every 3 months, with a
couple keystrokes changing behaviours and messing with people's heads.

> >> I could also suggest changes upstream.
> 
> If people want, they can forward relevant patches to Illumos,
> which has a code base somewhat similar to ours.  Forwarding patches
> to Mark Nudelman is harder; i would expect many merge conflicts.
> Then again, if anybody wants to spend time helping Mark, there is
> certainly nothing wrong with that.

I think this latter sentence is where the problem comes from -- it is
a piece of software gathering features like a rolling stone.  Here let
me throw a turd in front of it's path



Re: Memory protection and the push instruction (amd64)

2021-12-06 Thread Theo de Raadt
Theo de Raadt  wrote:

> Upon every system call entry, both the PC and SP are range-checked
> against the object they point to, vaguely providing an addition kind of
> MMU flag bit.  This check hinders a variety of ROP pivot methods.

I want to add one more comment.  I believe the benefit described
far outweighs the past expectation the pointer can point outside.

When I was writing this code, we found no "thread-lite" libraries that
pointed the pointer aligned and outside the object.  They all moved the
pointer inside the object first, and then aligned it as required.



Re: Memory protection and the push instruction (amd64)

2021-12-06 Thread Theo de Raadt
Otto Moerbeek  wrote:

> On Mon, Dec 06, 2021 at 05:59:41AM +, slembcke wrote:
> 
> > So this is a fairly esoteric question, and I expect the answer might
> > be just as esoteric.
> > 
> > I have a little toy fiber/stackless coroutine library that I made a
> > few years ago and have been using in some of my hobby projects.
> > (https://github.com/slembcke/Tina) The recent 7.0 release rekindled my
> > interest in OpenBSD, so I tried building my current game project for
> > it, and I was quite pleased that it mostly just needed a few ifdefs
> > changed. Well, except for the fiber library... There were two issues,
> > the first was trivial to fix. I just had to switch to mmap() +
> > MAP_STACK to allocate the stack buffers since OpenBSD requires it. The
> > second I found a workaround for easily enough, but I'm really curious
> > why it happens. If I mmap() a buffer, I can mark the final page as
> > PROT_NONE as a guard page. Then if I set %rsp to the guard page's
> > address and push a value, it subtracts and then writes the value just
> > below the guard page as expected on Linux/FreeBSD/Mac. However, on
> > OpenBSD this fails with a segfault. Either starting 16 bytes lower, or
> > replacing the push instruction with a sub and a mov to emulate it
> > works fine. So there is an easy workaround, but my question is why? I
> > assumed pagefaults were implemented in hardware by the MMU as an
> > interrupt or something during reads and writes. Is this a subtle bug
> > in OpenBSD, and if it is, how does it even know since the write
> > doesn't even affect the protected page?! (Protected memory is black
> > magic already! Hah!) I would assume that whatever is happening here
> > would have to be handled when initializing the stack for processes or
> > threads too.
> > 
> > - Scott
> > 
> 
> We prefer to see code instead of stories.
> 
> From your story it is not clear if yo are changing the protection
> flags of a general buffer or a MAP_STACK region. I t is the latter,
> there are extra restrictions on the stack pointer that are enforced in
> the kernel on behalf of the user process. You should check
> /var/log/messages

or type dmesg

Upon every system call entry, both the PC and SP are range-checked
against the object they point to, vaguely providing an addition kind of
MMU flag bit.  This check hinders a variety of ROP pivot methods.

Setting the SP just outside the object is considered invalid, since it
does not point *inside* an identifiable object, instead it points to the
first byte inside unmapped or differently mapped address space, and a
non-predecrement storage operation will act upon the wrong object.

Otto is suggesting you have something like this in:

[program]10549/243766 sp=7fa43021000 inside 7fa4301b000-7fa43021000: not 
MAP_STACK

(For now, these errors are printed, like pledge errors are, in a few
more years I hope to delete these publically visible identifiers and
have authors recognize the failure mode without blatant logging).

It is true the message says "inside", the check is [7fa4301b000,7fa43021000)
but I don't want to use bracket notation, so the 7fa43021000 should be
printed as 7fa43020fff.  This should improve the message, and lets us keep
using the easy to understand word "inside" (the format string for this message
is in sys/sys/syscall_mi.h)

Index: sys/uvm/uvm_map.c
===
RCS file: /cvs/src/sys/uvm/uvm_map.c,v
retrieving revision 1.279
diff -u -r1.279 uvm_map.c
--- sys/uvm/uvm_map.c   24 Oct 2021 15:23:52 -  1.279
+++ sys/uvm/uvm_map.c   6 Dec 2021 16:26:26 -
@@ -1894,7 +1894,7 @@
if (!ok) {
KERNEL_LOCK();
printf(fmt, p->p_p->ps_comm, p->p_p->ps_pid, p->p_tid,
-   addr, ie->ie_start, ie->ie_end);
+   addr, ie->ie_start, ie->ie_end-1);
p->p_p->ps_acflag |= AMAP;
sv.sival_ptr = (void *)PROC_PC(p);
trapsignal(p, SIGSEGV, 0, SEGV_ACCERR, sv);




 



Re: cd*.iso reboot loop (vultr, Skylake AVX MDS)

2021-12-04 Thread Theo de Raadt
Mike Larkin  wrote:

> On Sat, Dec 04, 2021 at 06:18:55PM +, Claus Assmann wrote:
> > Just in case someone is wondering: vultr moved the VM to a different
> > server, the system is up and running again.
> > BTW: I guess I can ignore this:
> > fd0 at fdc0 drive 1: density unknown
> >
> >
> > OpenBSD 6.9 (GENERIC) #464: Mon Apr 19 10:28:56 MDT 2021
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
> > real mem = 1056813056 (1007MB)
> > avail mem = 1009561600 (962MB)
> > random: good seed from bootblocks
> > mpath0 at root
> > scsibus0 at mpath0: 256 targets
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5940 (9 entries)
> > bios0: vendor Vultr
> > bios0: Vultr VC2
> > acpi0 at bios0: ACPI 1.0
> > acpi0: sleep states S3 S4 S5
> > acpi0: tables DSDT FACP APIC HPET WAET
> > acpi0: wakeup devices
> > acpitimer0 at acpi0: 3579545 Hz, 24 bits
> > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> > cpu0 at mainbus0: apid 0 (boot processor)
> > cpu0: Virtual CPU 6db7dc0e7704, 2993.33 MHz, 06-5e-03
> 
> It was at this point I stopped caring about this configuration.

No kidding.

The Intel-compatible cpu landcape is pretty fucked up, in that feature
bits are missing in some generations or otherwise inaccurate.  Therefore
a kernel has to someones look at the brand to narrow in on the truth and
make a logical decision.  At the moment the way we do it looks like
this:

amd64/cpu.c:if (strcmp(cpu_vendor, "GenuineIntel") == 0) {
amd64/cpu.c:if (strcmp(cpu_vendor, "GenuineIntel") != 0 ||
amd64/cpu.c:if (strcmp(cpu_vendor, "GenuineIntel") == 0 &&
amd64/cpu.c:if (strcmp(cpu_vendor, "GenuineIntel") == 0 &&
amd64/identcpu.c:   if (!strcmp(cpu_vendor, "GenuineIntel")) {
amd64/identcpu.c:   } else if (!strcmp(cpu_vendor, "CentaurHauls")) 
{
amd64/identcpu.c:   } else if (!strcmp(cpu_vendor, "AuthenticAMD")) 
{
amd64/identcpu.c:   if (!strcmp(cpu_vendor, "GenuineIntel") && cpuid_level 
>= 0x06) {
amd64/identcpu.c:   } else if (!strcmp(cpu_vendor, "AuthenticAMD")) {
amd64/identcpu.c:   if (!strcmp(cpu_vendor, "AuthenticAMD")) {
amd64/identcpu.c:   if (!strcmp(cpu_vendor, "AuthenticAMD")) {
amd64/identcpu.c:   if (!strcmp(cpu_vendor, "GenuineIntel") &&
amd64/identcpu.c:   if (!strcmp(cpu_vendor, "AuthenticAMD") &&
amd64/identcpu.c:   if (!strcmp(cpu_vendor, "AuthenticAMD"))
amd64/identcpu.c:   if (CPU_IS_PRIMARY(ci) && !strcmp(cpu_vendor, 
"CentaurHauls")) {
amd64/identcpu.c:   if (strcmp(cpu_vendor, "AuthenticAMD") == 0) {
amd64/identcpu.c:   } else if (strcmp(cpu_vendor, "GenuineIntel") == 0) {
amd64/identcpu.c:   if (!strcmp(cpu_vendor, "GenuineIntel")) {
amd64/lapic.c:  if (strcmp(cpu_vendor, "AuthenticAMD") == 0) {
amd64/mtrr.c:   if (((strcmp(cpu_vendor, "GenuineIntel") == 0) ||
amd64/mtrr.c:   (strcmp(cpu_vendor, "CentaurHauls") == 0) ||
amd64/mtrr.c:   (strcmp(cpu_vendor, "AuthenticAMD") == 0)) && 
amd64/pctr.c:   pctr_isamd = (strcmp(cpu_vendor, "AuthenticAMD") == 0);
amd64/pctr.c:   pctr_isintel = (strcmp(cpu_vendor, "GenuineIntel") == 
0);
amd64/tsc.c:if (!strcmp(cpu_vendor, "GenuineIntel") &&
amd64/ucode.c:  if (strcmp(cpu_vendor, "GenuineIntel") == 0)

Then someone at Vultr, who is probably really proud of themselves,
disabled all those tests.

If they can so easily make a damaging decision like that without studying
real system behaviour, what else will they get wrong?



Re: cd*.iso reboot loop (vultr, Skylake AVX MDS)

2021-12-04 Thread Theo de Raadt
Philip Guenther  wrote:

> They have your virtualization guest configured in a way that doesn't match
> any real hardware: it has a family-model-stepping combination that matches
> the Skylake line, real hardware of which all have the cflushopt extension,
> but the host is making the guest trap when that instruction is used.

My personal favorite is AMD cpus with Intel host bridges.  Then code
has to decide which types of family workarounds apply based upon non-sensical
conditions.  Oh, I see you have qbus instead of isa, you don't need this
specific interrupt controller hack!



Re: Problems with a fresh install not finding SSD drive over floppy img HTML5/KVM

2021-11-30 Thread Theo de Raadt
I am dissapointed to see "long answers" to "short spurious claims".

Nick, your long mail didn't help anything.

Chris, your report sucks.  Use sendbug and file a bug report with no
details missing.  Not one user has reported a drive missing on a ahci
controller before you, and suddenly you say (paraphasing) "oh i hear this
is very common!"). The intentionally vague way you approach this looks like
you want to make us look bad.

Nick Holland  wrote:

> On 11/30/21 3:30 PM, Chris Bennett wrote:
> > After looking over the list, it looks like many SSD's have compatibility
> > problems, so I'm just going to switch over to a spinning drive.
> > Sorry for the noise.
> > 
> 
> categorical nonsense.
> 
> SSDs work.  Cheap ones work, expensive ones work.  Some work better than
> others,  I wish cost predicted success, hasn't in my experience, but
> some IBM branded SAN SSD drives have had an oddly low rate of failure at
> work...but then each drive probably costs as much as one of my cars,
> and stores a very modest amount of data...so maybe at the really high
> end you get what you pay for.  maybe.
> 
> I've had nothing but problems with /some/ Samsung drives, good luck
> with some junk no-name drives, but the key thing is...if the SATA or SAS
> port the drive is plugged into works, the drive will be recognized and
> work (though maybe better or worse than you wish...but that's not an OS
> issue).
> 
> For a system to boot, the BIOS must support the drive.  For the system
> to get installed, the OS must support the drive.  You can boot a kernel
> from a disk the OS doesn't recognize, and you can install the OS to a
> drive the system can't boot from.  The fact that you "see" the drive in
> the BIOS means only that the drive is hooked up properly.  Doesn't
> indicate OS support.
> 
> Make sure your BIOS is set to support the drives as "AHCI" if that's an
> option.  If you see "RAID", that won't work for good reasons.  If the
> drive is attached to a real RAID controller, the controller may not be
> supported, or you may have it configured wrong (i.e., the drives are there,
> but not configured on the RAID Card, so the RAID card isn't presenting
> "drives" to the OS).
> 
> Provide useful info rather than stomping your feet and saying "it worked
> before!".  Obviously, things are different.  The answer is almost
> certainly in the dmesg.
> 
> Nick.
> 



Re: Problems with a fresh install not finding SSD drive over floppy img HTML5/KVM

2021-11-30 Thread Theo de Raadt
Chris Bennett  wrote:

> After looking over the list, it looks like many SSD's have compatibility
> problems, so I'm just going to switch over to a spinning drive.

That is news to us.



Re: libdmx removal incomplete?

2021-11-28 Thread Theo de Raadt
>These files are still part of xshare70 set, and should not be
>removed. There are part of xorgproto (xenocara/proto/xorgproto).
>
>> Lastly: From your emails it seems to me that the use of sysclean after
>> upgrading is very much encouraged if not necessary. Then why is it not
>> included in base (especially when it's developed by OpenBSD developers)?
>> Or am I misunderstanding the requirements for inclusion of packages in
>> base?

  ^^^
WRONG.  Deleting old files is DISCOURAGED -- because we do
not have tooling to discover if a user has built their own
private programs which require those files.  I am actually
getting a bit tired of (1) people overly worried about old
files (2) who don't recognize they can always reinstall and
(3) that we (OpenBSD) are not able to determine what to delete
any better than you the user.

>If removal of files is required, it is explicitly mentioned in
>upgradeXX.html or current.html. Very few files will broke your system
>if present.
>
>In the other side, removing files that are used will broke your system
>(for example, if you compile a program yourself, it will use system
>libraries like libc, libm...).
>
>Thanks.
>-- 
>Sebastien Marie
>
>



Re: isc-bind doesn't start...

2021-11-28 Thread Theo de Raadt
Christer Solskogen  wrote:

> on the recent snapshot (OpenBSD 7.0-current (GENERIC.MP) #126: Sun Nov 28
> 00:04:30 MST 2021)
> 
> tugs# /usr/local/sbin/named -t /var/named -u _bind -U 4
> named:/usr/local/lib/libisc-9.16.23.so: undefined symbol
> '__emutls_get_address'
> ld.so: named: lazy binding failed!
> Killed

Perhaps you know how the saying goes:

new base snapshot, new snapshot packages



Re: Put non-NULL pledge abort in the man page

2021-11-24 Thread Theo de Raadt
Sebastien Marie  wrote:

> If the code you are using is restricted and can't be showed, please at
> least show a ktrace output of the program run. At this point I am
> still unsure that it is execve(2) which is causing pledge violation.

actually I want to know where garbage code like this runs to make sure
it hurts fewer people



Re: Put non-NULL pledge abort in the man page

2021-11-24 Thread Theo de Raadt
It kills your secret program because it is broken.

>From the manual page:

 A process which attempts a restricted operation is killed with an
 uncatchable SIGABRT, delivering a core file if possible.

You are so incapable of reading and learning.

I am asking you to leave this list.



Luke Small  wrote:

> It works great, up until the time that pledge() ITSELF gets shot in the head, 
> which
> seems would be impossible! It’s supposed to only throw errors! Or did I miss 
> the memo
> that there’s a “pledge” pledge?
> 
> On Wed, Nov 24, 2021 at 8:19 PM Theo de Raadt  wrote:
> 
>  You have a secret program and you want people on the internet to help
>  you debug what you have done wrong in this secret program.
> 
>  You obviously don't know what you are doing, and I think you don't
>  deserve help.
> 
>  Luke Small  wrote:
> 
>  > I have a program which runs fork() a couple times with pledges: “stdio
>  > cpath wpath” for writing to disk and “stdio dns” for a dns caching process
>  > after accepting command-line input. Is the execpromises, permitted to
>  > increase/change to accommodate the different fork()s from the parent? If
>  > so, why isn’t all of this discussed in the manpage.
>  > 
>  > I’m running 7.0 and it immediately is killed when I run pledge with a
>  > non-NULL execpromise.
>  > 
>  > No error, just a sigabort. And nothing in the man page (even for -current:
>  > on the web) which explains anything.
>  > 
>  > https://github.com/lukensmall/pkg_ping
>  > 
>  > This a command-line program is used to make manually choosing a responsive
>  > mirror or automatically writing the most responsive OpenBSD mirror to
>  > /etc/installurl very easy.
>  > 
>  > On Wed, Nov 24, 2021 at 11:50 AM Luke Small  wrote:
>  > 
>  > > I tried calling pledge with a non-NULL execpromise and noticed that it 
> was
>  > > killed. That’d be convenient if that behavior was noted in the man 
> page!--
>  > > -Luke
>  > >
>  > -- 
>  > -Luke
> 
> -- 
> -Luke
> 



Re: Put non-NULL pledge abort in the man page

2021-11-24 Thread Theo de Raadt
You have a secret program and you want people on the internet to help
you debug what you have done wrong in this secret program.

You obviously don't know what you are doing, and I think you don't
deserve help.


Luke Small  wrote:

> I have a program which runs fork() a couple times with pledges: “stdio
> cpath wpath” for writing to disk and “stdio dns” for a dns caching process
> after accepting command-line input. Is the execpromises, permitted to
> increase/change to accommodate the different fork()s from the parent? If
> so, why isn’t all of this discussed in the manpage.
> 
> I’m running 7.0 and it immediately is killed when I run pledge with a
> non-NULL execpromise.
> 
> No error, just a sigabort. And nothing in the man page (even for -current:
> on the web) which explains anything.
> 
> https://github.com/lukensmall/pkg_ping
> 
> This a command-line program is used to make manually choosing a responsive
> mirror or automatically writing the most responsive OpenBSD mirror to
> /etc/installurl very easy.
> 
> On Wed, Nov 24, 2021 at 11:50 AM Luke Small  wrote:
> 
> > I tried calling pledge with a non-NULL execpromise and noticed that it was
> > killed. That’d be convenient if that behavior was noted in the man page!--
> > -Luke
> >
> -- 
> -Luke



Re: lm(4) temperature

2021-11-20 Thread Theo de Raadt
Jan Stary  wrote:

> This is current/i386 on an ALIX.1E (dmesg below).
> I am trying to monitor the CPU temperature with
> 
> wbsio0 at isa0 port 0x2e/2: W83627HF rev 0x41
> lm1 at wbsio0 port 0x290/8: W83627HF
> 
> $ sysctl hw.sensors.lm1
> hw.sensors.lm1.temp0=69.00 degC
> hw.sensors.lm1.temp1=57.00 degC
> hw.sensors.lm1.temp2=49.00 degC
> hw.sensors.lm1.volt0=1.26 VDC (VCore A)
> hw.sensors.lm1.volt1=2.64 VDC (VCore B)
> hw.sensors.lm1.volt2=3.42 VDC (+3.3V)
> hw.sensors.lm1.volt3=5.11 VDC (+5V)
> hw.sensors.lm1.volt4=0.00 VDC (+12V)
> hw.sensors.lm1.volt5=-14.91 VDC (-12V)
> hw.sensors.lm1.volt6=-7.71 VDC (-5V)
> hw.sensors.lm1.volt7=5.07 VDC (5VSB)
> hw.sensors.lm1.volt8=0.00 VDC (VBAT)
> 
> There are three temperatures reported,
> and dev/ic/lm78var.h talks about Temperature 1, 2, 3;
> but man lm(4) only says
> 
>   Temp uK Motherboard Temperature
> 
> Does anyone know what exactly they are?


There is a chip in the machine.
It has pins.
Those pins are monitored by the driver, as specific registers.

The pins wired to who the hell knows where by each board manufacturer.

Sometimes the chips need special registers and capacitors

Quite often, the board engineer sent to add this part to the board
choose the wrong registers and capacitors, and sometimes they compensate
for these errors with private tables in the BIOS or various monitoring
programs which move around machine to machine.


We monitor registers.  We assume the vendor did the right thing.


No that I've described what a shitshow it is, I hope you can adjust your
expectations.  Otherwise, maybe it is time to give up and delete these
sensor drivers..



Re: boundend less than total sectors — amd64, install70.iso, new HDD

2021-11-17 Thread Theo de Raadt
Stuart Henderson  wrote:

> > If that's the case, you have to reinstall on GPT.
> 
> But that isn't, if the disk is just used for OpenBSD and boot is close enough
> to the start of the disk (i.e. root partition isn't too far in) then setting
> the full disk with 'b' is enough, OpenBSD uses its own disklabel and doesn't
> need the entire disk to be shown in the fdisk partition

The command is

> b *




Re: type checking/signalling shell and utilities?

2021-11-17 Thread Theo de Raadt
Reuben ua Bríġ  wrote:

> > Date: Wed, 17 Nov 2021 09:34:21 -0700
> > From: "Theo de Raadt" 
> >
> > Oh you want magic
> > 
> > you'll find it next to the ponies.
> 
> This is not magic. It is syntax. Or is C also "magic"?
> 
> The shell is the one that expands *. The shell knows they are files. It
> is not unreasonable to expect the shell to pass that information on.
> 
> I find your lack of faith disturbing.

It is really exhausting watching these replays of discussions from
before 75% of the readers were born.  They went nowhere then.  They will
go nowhere now.

The other exhausting part is "I can't do this, why doesn't someone do
this for me, oh I will ask a mailing list".



Re: type checking/signalling shell and utilities?

2021-11-17 Thread Theo de Raadt
Reuben ua Bríġ  wrote:

> I felt a more elegant solution would be a shell that can pass an array
> of strings as an argument, just as C can, and knows when to do so,
> rather than having each string as an argument. I wanted to know if
> there is already a shell that accomplishes that.--No need to reinvent
> the shell if someone has done so already.

Oh you want magic

you'll find it next to the ponies.



Re: cron sh script fork

2021-11-15 Thread Theo de Raadt
Todd C. Miller  wrote:

> On Mon, 15 Nov 2021 20:13:01 +0300, misc@abrakadabra.systems wrote:
> 
> > [/opt/bin]$ cat check.sh
> > #!/bin/sh
> >
> > _ret=$(ps aux | grep sleeploop.sh | grep -v grep | awk '{print $2}')
> > test -z ${_ret} && /opt/bin/sleeploop.sh &
> 
> By default, ps uses 80 columns so the information is probably being
> cut off.  I'm guessing your interactive terminal is wider than 80
> columns.  You can add 'w' a few times to your ps options to extend
> the width but you are much better off using pgrep for this.

pgrep is better.  But there are so many risks in this construct I would not
trust it at all.



Re: cron sh script fork

2021-11-15 Thread Theo de Raadt
Your "ps" pipeline could identify other processes.  If I was on your
machine, I would start a long-running process with sleeploop.sh as an
argument, your script sees it, and misbehaves.  Don't do this.

man 5 crontab

A method to do this safer was

 -s command
 Only a single instance of command will be run concurrently.
 Additional instances of command will not be scheduled until the
 earlier one completes.

misc@abrakadabra.systems wrote:

> I have one script (sleeploop.sh) running in background and second (check.sh)
> to test if sleeploop is running and if not then start it. 
> 
> 
> [/opt/bin]$ cat sleeploop.sh
> #!/bin/sh
> while true
> do
> sleep 5
> done
> 
> [/opt/bin]$ cat check.sh
> #!/bin/sh
> 
> _ret=$(ps aux | grep sleeploop.sh | grep -v grep | awk '{print $2}')
> test -z ${_ret} && /opt/bin/sleeploop.sh &
> 
> 
> When i start check.sh from the shell it works fine; if there is no pid 
> check.sh 
> starts sleeploop.sh, otherwise it gets the pid and exiting.
> If i put check.sh in cron it spawns another sleeploop.sh process every time
> when triggered.
> 
> 
> dmesg:
> OpenBSD 7.0 (GENERIC.MP) #1: Fri Oct 29 12:04:07 MDT 2021
> 
> r...@syspatch-70-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 1810530304 (1726MB)
> avail mem = 1739616256 (1659MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb6b0 (91 entries)
> bios0: vendor American Megatrends Inc. version "0608" date 08/10/2012
> bios0: ASUSTeK COMPUTER INC. P8H61-M LX3 R2.0
> acpi0 at bios0: ACPI 5.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT SSDT
> acpi0: wakeup devices P0P1(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) 
> PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) PEG0(S4) 
> PEGP(S4) PEG1(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Pentium(R) CPU G2020 @ 2.90GHz, 2900.44 MHz, 06-3a-09
> 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 100MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Pentium(R) CPU G2020 @ 2.90GHz, 2900.04 MHz, 06-3a-09
> 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xf800, bus 0-63
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (P0P1)
> acpiprt2 at acpi0: bus 2 (RP01)
> acpiprt3 at acpi0: bus -1 (RP02)
> acpiprt4 at acpi0: bus -1 (RP03)
> acpiprt5 at acpi0: bus -1 (RP04)
> acpiprt6 at acpi0: bus -1 (RP05)
> acpiprt7 at acpi0: bus 3 (RP06)
> acpiprt8 at acpi0: bus 1 (PEG0)
> acpiprt9 at acpi0: bus -1 (PEG1)
> acpiprt10 at acpi0: bus -1 (PEG2)
> acpiprt11 at acpi0: bus -1 (PEG3)
> acpiec0 at acpi0: not present
> acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x
> acpicmos0 at acpi0
> acpibtn0 at acpi0: PWRB
> "PNP0C0B" at acpi0 not configured
> "PNP0C0B" at acpi0 not configured
> "PNP0C0B" at acpi0 not configured
> "PNP0C0B" at acpi0 not configured
> "PNP0C0B" at acpi0 not configured
> "PNP0C14" at acpi0 not configured
> acpicpu0 at acpi0: C3(350@80 mwait.1@0x20), C2(500@59 mwait.1@0x10), 
> C1(1000@1 mwait.1), PSS
> acpicpu1 at acpi0: C3(350@80 mwait.1@0x20), C2(500@59 mwait.1@0x10), 
> C1(1000@1 mwait.1), PSS
> acpipwrres0 at acpi0: FN00, resource for FAN0
> acpipwrres1 at acpi0: FN01, resource for FAN1
> acpipwrres2 at acpi0: FN02, resource for FAN2
> acpipwrres3 at acpi0: FN03, resource for FAN3
> acpipwrres4 at acpi0: FN04, resource for FAN4
> acpitz0 at acpi0: critical temperature is 106 degC
> acpitz1 at acpi0: critical temperature is 106 degC
> acpivideo0 at acpi0: GFX0
> acpivout0 at acpivideo0: DD02
> cpu0: using VERW MDS workaround (except on vmm entry)
> cpu0: Enhanced SpeedStep 2900 MHz: 

Re: Some Thoughts on resolv.conf.tail Deprecation

2021-11-11 Thread Theo de Raadt
beebeet...@posteo.de wrote:

> > I am not sure about what problem you are trying to solve.  Won't the
> > lines added by resolvd be overwritten anyway the first time you use the
> > backed up file?
> 
> What I'm trying to solve is that static part of the configuration being
> mixed up with configuration generated runtime in a single file, which
> leads to a few inconveniences:
>  - resolv.conf will show up in the diff between backups all the time
>even if nothing has really changed;

Oh come on.  Something happened. That is why the contents are different.

>  - when migrating the configuration to a different deployment, for
>example, one where IP address is statically assigned, resolvd will
>not overwrite the "stale" auto-configured lines, and the old
>nameserver info will linger unless manually removed.

So what?

> For now resolv.conf is the only configuration file I know of that gets
> mixed up with runtime info, and it's manageable; but imagine if many
> more configuration files follow similar principles, the administrative
> overhead can quickly become too much.

Yes, we are going to do the same thing to lots of other configuration files.
We are trying to keep up with systemd.  Didn't you get the memo?



Re: Some Thoughts on resolv.conf.tail Deprecation

2021-11-11 Thread Theo de Raadt
No, we will not do what you propose because resolvd so far is working
for the majority of people, better than we expected.

Luckily we provide all the parts including source, and you can do
whatever you want with it.

beebeet...@posteo.de wrote:

> Hi all,
> 
> I was reading the manual page of resolv.conf(5) today and realized that
> paragraph on resolv.conf.tail has disappeared since the upgrade to
> 7.0, so I assume that resolv.conf.tail has been deprecated in response
> to resolvd being enabled by default.
> 
> Previously, my backup strategy was to back up the customized system
> configuration files, which involves backing up resolv.conf.tail, but
> not resolv.conf. With the new behaviour in 7.0, it appears that my best
> shot is to back up resolv.conf, which constantly gets edited by
> resolvd(8). This seems less than ideal.
> 
> I gave it some thoughts, and came up with an alternative solution to
> handling resolv.conf:
> 
>  - If resolvd is enabled, then resolv.conf is overidden entirely by
>resolvd, no more blending of user-edited and auto-configured
>information is involved. A new resolvd.conf needs to be introduced to
>instruct resolvd to add static defaults and stuff;
> 
>  - If resolvd is not enabled, then the contents of resolv.conf.tail gets
>copied to resolv.conf at system start.
> 
> To me it seems that this is cleaner than the current solution to
> resolv.conf in that static and dynamic configurations is clearly
> separated instead of being blended into a one file.
> 
> What are your thought on this? Thanks!
> 



Re: clang performance bug is worse on openbsd than freebsd

2021-11-08 Thread Theo de Raadt
Stuart Henderson  wrote:

> On 2021-11-08, Otto Moerbeek  wrote:
> > On Sun, Nov 07, 2021 at 08:13:36PM -0600, Luke Small wrote:
> >
> >> https://bugs.llvm.org/show_bug.cgi?id=50026
> >> 
> >> I reported it to the llvm people. it is two slightly different quicksort
> >> algorithms which perform radically differently. The one which you could
> >> assume would take more time, performs MUCH better.
> >> 
> >> I made a custom quicksort algorithm which outperforms qsort by A LOT for
> >> sorting an array of around 300 randomly created unsigned characters, which
> >> is what I use it for.
> >> 
> >> if you read the report a guy said there's a 10% difference for sorting 3
> >> million characters on freebsd, but there's about 40% performance difference
> >> on OpenBSD. maybe it's also how the OpenBSD team modified clang to prevent
> >> rop chain stuff or something? I'm using a westmere based intell server.
> >> 
> >> it's the same for clang 11.
> >> 
> >> What's the deal?
> >
> > 1. Your test is too small. I increased the test size to get less error
> > in measurement. I also changed the code to either run quicksort or
> > quicksort depending on an argument.
> >
> > 2. I confirmed your observation using time on amd64, arm64 however
> > shows a difference more in line with expectations:
> >
> > [otto@mc:8]$ time ./a.out A
> > quicksort
> > time = 0.335777021
> > 0m00.35s real 0m00.35s user 0m00.01s system
> > [otto@mc:9]$ time ./a.out B 
> > quicksort1
> > time = 0.345703033
> > 0m00.36s real 0m00.36s user 0m00.01s system
> >
> >
> > I suspect some non-optimal decision of the optimizer on amd64 for the
> > first quicksort.
> >
> > A next step could be somebody looking at the code produced by the
> > compiler.  That is not going to be me.
> 
> This is another example of code quite badly affected by fixup-gadgets.
> With an increased test size and building separate objects for each of
> the two tests and with/without CFLAGS=-fno-fixup-gadgets:
> 
> $ for i in quicksort*; do echo $i; time ./$i; done
>
> quicksort
> 0m02.33s real 0m02.32s user 0m00.00s system
> quicksort-no-fixup-gadgets
> 0m01.29s real 0m01.27s user 0m00.00s system
> quicksort1
> 0m01.06s real 0m00.94s user 0m00.02s system
> quicksort1-no-fixup-gadgets
> 0m01.08s real 0m00.87s user 0m00.01s system
> 
> 

The word everyone is looking for is "tradeoff", meaning this is intentional.



Re: mmap with the arguments PROT_NONE and MAP_STACK

2021-11-04 Thread Theo de Raadt
overcq  wrote:

> >> However, I need to know how much of the stack is currently allocated
> >> and how much remains only reserved.
> > > Why?
> 
> To be able to release reservations from the beginning of the stacks
> when new in-program tasks are created. So that you can create any number
> of these tasks at runtime.

You are attempting to micromanage physical memory in a program which can
only allocate/deallocate virtual memory address space.  In any case, I
would never want to run any piece of software like yours which is
undoubtably pulling software with unknown memory damage into a single
address space.  I'm reading your approach is anti-security. And I'm giving up.



Re: mmap with the arguments PROT_NONE and MAP_STACK

2021-11-04 Thread Theo de Raadt
overcq  wrote:

> However, I need to know how much of the stack is currently allocated
> and how much remains only reserved.

Why?



Re: mmap with the arguments PROT_NONE and MAP_STACK

2021-11-03 Thread Theo de Raadt
overcq  wrote:

> Theo de Raadt  wrote:
> 
> > There would need to be justification for why that program wants to do
> > that, before changing this.  The restriction for stacks is a bit like
> > a safety belt.
> 
> I don't know how much stack each task will need, and I reserve all tasks
> equally from all available memory. When a new task is created,
> I take away the top of the stack from everyone else, so that again
> all tasks have the same amount of the stack reserved. But I allocate
> real memory only after the task reaches for this memory.
> 
> Perhaps the solution is not to change this protection, as it is only
> a matter of ensuring that real memory is not allocated before it is used

That is not making any sense to me.

The mmap calls do not allocate memory.

Instead, mmap allocates address space, indicating a allocation/permission
policy, which allows the kernel to fault in (provide) memory when required.

A page of memory in the range is not actually allocated from the system
until code touches it.



Re: mmap with the arguments PROT_NONE and MAP_STACK

2021-11-03 Thread Theo de Raadt
overcq  wrote:

> Hello,
> 
> I am trying to run a program I wrote that was ported from Linux.
> It allows you to run in-program tasks as C functions. Each such task
> is set up with its own allocated stack.
> 
> However, in OpenBSD I cannot allocate the stack with mmap
> with the PROT_NONE flag, and later in the SIGSEGV handler change
> mprotect to PROT_READ | PROT_WRITE because mmap returns with error
> errno == 22 (Invalid argument).
> 
> Is there a workaround for this so that you don't have to allocate
> the entire stack first?
> 
> Below is a link to the code where mmap returns with an error:
> https://github.com/overcq/oux/blob/master/module/base/flow-drv.cx#L188

At the moment we require stacks to be R|W

sys/uvm/uvm_mmap.c line 260

There would need to be justification for why that program wants to do
that, before changing this.  The restriction for stacks is a bit like
a safety belt.



Re: Mouse scrolling issues for anyone else?

2021-11-03 Thread Theo de Raadt
Ricky Cintron  wrote:

> I'm a bit confused as to why the snapshot from Oct. 30 included a
> commit from Oct. 31, but everything else seems clear now.

Diffs under review often land in snapshots.



Re: iwm stopped working on 7.0 after installing patches 001,002,003

2021-11-03 Thread Theo de Raadt
I do not think it is the errata, because they are completely unrelated
to 802.11 drivers or stack.  You can look at the errata closer and
realize it has nothing to do with wifi.

I suspect your firmware was updated.  Or you changed something else.


Doros Eracledes  wrote:

> Thanks Stefan, I did try booting the snapshot bsd.rd kernel but got an
> error about failing to load firmware, see attached screenshot.
> 
> thanks
> Doros
> 
> On Wed, 3 Nov 2021, 4:05 pm Stefan Sperling,  wrote:
> 
> >
> >
> > Could you please give a -current kernel a try to see whether this
> > issue has been fixed since? Temporarily booting into a bsd.mp image
> > from the latest snapshot should be enough for testing purposes.
> > You do not need to upgrade the entire system if you do not want to.
> >



Re: make: don't know how to make /usr/lib/crt0.o (prerequisite of: httpd)

2021-10-31 Thread Theo de Raadt
>From the script

 make obj && make && make install

Which uses the whole toolchain.

You need comp.  You don't have a choice.

Kent Watsen  wrote:

> The “httpd-plus” [1] patch installs just find when a fresh 7.0 install 
> selects packages "base", "bsd", "bsd.rd", "bsd.mp", “comp”, and “man”.
> 
> However, when a fresh 7.0 install selects all the same packages except 
> “comp”, and then subsequently adds the “comp” package via the command:
> 
>   (cd /root && curl -s -O 
> https://cdn.openbsd.org/pub/OpenBSD/7.0/amd64/comp70.tgz && cd / && tar 
> xzvphf /root/comp70.tgz)
> 
> The installation of the "httpd-plus" patch fails with the following snippet:
> 
>
>   Building and installing httpd-plus binary and manpage ...
>   /usr/src/usr.sbin/httpd/obj -> /usr/obj/usr.sbin/httpd
>   make: don't know how to make /usr/lib/crt0.o (prerequisite of: httpd)
>   Stop in /usr/src/usr.sbin/httpd
>   Restoring original sources ... Done.
>   Installing httpd-plus failed (exitcode: 2).
> 
> This logic worked on 6.9, what’s the difference?  Why can’t /usr/lib/crt0.o 
> be found or made?  How to get past this error without needing to install the 
> “comp” package during installation?
> 
> PS: I don’t want “comp” on the production system. After installing 
> “httpd-plus”, I run the following command to remove it: (cd /root && for i in 
> `tar -tzvf /root/comp70.tgz | awk '{print $NF}'`; do rm -rf $i; done) && rm 
> /root/comp70.tgz
> 
> [1] https://github.com/mpfr/httpd-plus/tree/7.0-stable
> 
> Thanks,
> Kent
> 
> 



Re: pf and tap interfaces

2021-10-31 Thread Theo de Raadt
tech-lists  wrote:

> On Sun, Oct 31, 2021 at 09:33:54AM -0600, Theo de Raadt wrote:
> >tech-lists  wrote:
> >
> >> I'm asking this here because I'm trying to do this with FreeBSD but
> >> their pf has diverged a lot from OpenBSD's
> >
> >that is incorrect history.
> >
> >It is hard to see how 'absolutely minimal maintainance' can result in
> >divergence.
> 
> yep. I should have said 'OpenBSD's pf has significantly evolved since ...'
> 
> >At some point, pf's state table data structures were rewritten completely.
> >
> >You are better off adjusting your expectations.  You can be foiled by
> >differences at any point.
> 
> Yes. At this stage it's more of an "is it even possible y/n"

you are asking a freebsd question on an openbsd mailing list.

come on



Re: pf and tap interfaces

2021-10-31 Thread Theo de Raadt
tech-lists  wrote:

> I'm asking this here because I'm trying to do this with FreeBSD but
> their pf has diverged a lot from OpenBSD's

that is incorrect history.

It is hard to see how 'absolutely minimal maintainance' can result in
divergence.

At some point, pf's state table data structures were rewritten completely.

You are better off adjusting your expectations.  You can be foiled by
differences at any point.




Re: use pfctl to reread /etc/mail/spamd-white table

2021-10-28 Thread Theo de Raadt
>> I don't know how atomic that is: is the table either empty
>> or does it contain all the addresses in the file? I would
>> guess the addresses are added as they are read, just like
>> when you add them manually.
>> 
>
>That is a wrong guess. pf tries to do things atomically when it makes
>sense is the general rule.

Yep, great effort was put into making the /dev/pf ioctl interface support
a number of atomic request/changes.



Re: How does bsd.upgrade work?

2021-10-24 Thread Theo de Raadt
If you don't use all the interlocked openbsd pieces together, and
replace some of them with your own, then you take on responsibility for
the problems we didn't need to solve because they don't exist in our
complete solution.

I think that is pretty simple.

I hope you understand.

As such, I have no comments on the rest of your questions, because in
our complete model, those questions don't matter.  I'm not kidding.

tetrahe...@danwin1210.me wrote:

> On Thu, Oct 21, 2021 at 03:46:20PM +0200, Janne Johansson wrote:
> >https://marc.info/?l=openbsd-tech=138829898720574=2
> >and
> >https://marc.info/?l=openbsd-tech=139013674405106=2
> >might help.
> 
> Thanks. This is the critical section:
> https://github.com/openbsd/src/blob/9c70cf5498e471044289f4c9857b84b309c5964e/sys/dev/rnd.c#L44-L45
> 
> So if the volume with the bootloader on it is not booted, the RNG is
> intialised with a less-random value (in particular if a hardware RNG is
> not present).
> 
> On Linux it's possible to check for an Intel hardware RNG[1] by looking
> for `rdrand` in /proc/cpuinfo[2]. *BSD seems to split this across
> `sysctl hw`, dmesg, and `dmidecode` [3].
> 
> Does this sound right -- will OpenBSD use the `rdrand` instruction if
> present, early in the boot process?
> 
> [1]
> https://stackoverflow.com/questions/26771329/is-there-any-legitimate-use-for-intels-rdrand
> 
> [2]
> https://0f5f.blogs.minster.io/2015/10/leveraging-intel-ivy-bridges-hardware-rng/
> 
> [3]
> https://stackoverflow.com/questions/4083848/what-is-the-equivalent-of-proc-cpuinfo-on-freebsd-v8-1
> 



Re: Unable to log in with Pubkey after upgrade to 7.0

2021-10-22 Thread Theo de Raadt
Ares  wrote:

> On Fri, Oct 22, 2021 at 08:56:13AM -0600, Theo de Raadt wrote:
> >Emiel Kollof  wrote:
> >
> >> Ivo Chutkin schreef op vr 22-10-2021 om 15:23 [+0300]:
> >> > Hello all,
> >> >
> >> > I am unable to log in with Pubkey after upgrade to 7.0
> >> >
> >> > I can log in with user/password.
> >> >
> >> > What i get in the log is:
> >> >
> >> > Oct 22 15:10:01 sklad sshd[88986]: userauth_pubkey: key type ssh-rsa
> >>
> >> See https://www.openssh.com/releasenotes.html
> >>
> >> Suggested workaround in your ssh config:
> >>
> >>Host old-host
> >> HostkeyAlgorithms +ssh-rsa
> >>PubkeyAcceptedAlgorithms +ssh-rsa
> >
> >Please stop telling people to work around it.  We removed ssh-rsa for
> >a damn good reason.
> >
> >Do you still use a horse buggy to visit the grocery store?
> >
> 
> While I'm not arguing with your damn good reasons for taking such
> actions. We don't always have the luxury of having the necessary
> permission to update the other side of a connection. Also yes, in my
> hometown of Lancaster plenty of people still take a horse buggy to get
> groceries.

Yes, you do have the luxury of upgrading the clients because this change
is *NOT NEW*, newer key methods are over five years old.

Those older clients have other bugs.  Generally not security related.
Perhaps we can only hope those people running such older clients get
holed.  Then they will update them to resolve the ssh-rsa problem.

Fair, right?



Re: Unable to log in with Pubkey after upgrade to 7.0

2021-10-22 Thread Theo de Raadt
Emiel Kollof  wrote:

> Ivo Chutkin schreef op vr 22-10-2021 om 15:23 [+0300]:
> > Hello all,
> > 
> > I am unable to log in with Pubkey after upgrade to 7.0
> > 
> > I can log in with user/password.
> > 
> > What i get in the log is:
> > 
> > Oct 22 15:10:01 sklad sshd[88986]: userauth_pubkey: key type ssh-rsa
> 
> See https://www.openssh.com/releasenotes.html
> 
> Suggested workaround in your ssh config: 
> 
>Host old-host
> HostkeyAlgorithms +ssh-rsa
>   PubkeyAcceptedAlgorithms +ssh-rsa

Please stop telling people to work around it.  We removed ssh-rsa for
a damn good reason.

Do you still use a horse buggy to visit the grocery store?



Re: Ifconfig error - SIOCSETPFLOW

2021-10-21 Thread Theo de Raadt
It is 'working for you' until we remove dhclient in a future release.

...

Antonino Sidoti  wrote:

> HI,
> 
> I added ‘!dhclient \$if’ to the /etc/hostname.em0 and removed ‘dhcp’. It is 
> working now with no errors on startup and the interface ‘pflow0’ now working 
> properly.
> 
> pf enabled
> net.inet.ip.forwarding: 0 -> 1
> net.inet6.ip6.forwarding: 0 -> 1
> starting network
> em0: no linkgot link
> em0: no lease.got lease
> em0: 122.199.32.172 lease accepted from 116.255.18.1 (3c:fd:fe:bd:95:13)
> reordering libraries: done.
> starting early daemons: syslogd pflogd unbound ntpd.
> starting RPC daemons:.
> savecore: no core dump
> checking quotas: done.
> clearing /tmp
> kern.securelevel: 0 -> 1
> creating runtime link editor directory cache.
> preserving editor files.
> starting network daemons: sshd snmpd dhcpd rad smtpd.
> starting package daemons: dhcpcd.
> starting local daemons: cron.
> Sun Oct 17 12:24:00 AEDT 2021
> 
> 
> Many thanks for your help
> 
> Antonino Sidoti
> 
> 
> 
> 
> > On 17 Oct 2021, at 1:12 am, Brian Brombacher  wrote:
> > 
> > 
> > 
> >> On Oct 15, 2021, at 10:56 PM, Antonino Sidoti  wrote:
> >> 
> >> HI,
> >> 
> >> Yes, on my em0 interface I am using ‘dhcp’ and this is the source IP for 
> >> pflow. The setup is a basic firewall as described in the PF example 
> >> firewall. 
> >> 
> >> Interface em0 = external using dhcp (Static IP assigned by carrier)
> >> Interface em1 = internal with static IP (Lan using 10.0.x.x/24)
> >> 
> >> Output from /etc/hostname.pflow0 (Not real IPs)
> >> flowdst 203.0.113.1:3001 flowsrc 198.51.100.1
> >> pflowproto 10
> >> 
> >> Thanks
> >> 
> >> Antonino Sidoti
> >> 
> >> 
> > 
> > Thanks for the details.  A recent change in 7.0 introduced a change in 
> > behavior for DHCP configured interfaces.  The IP could be assigned after 
> > other interfaces are configured.  You may need to assign the static IP in 
> > hostname.em0 before the dhcp line, or run dhclient directly from 
> > hostname.em0 and avoid using “dhcp” in there.
> > 
> >> 
>  On 16 Oct 2021, at 10:39 am, Brian Brombacher  
>  wrote:
>  
>  
>  
> > On Oct 15, 2021, at 7:09 PM, Antonino Sidoti  wrote:
>  
>  HI,
>  
>  I am getting this error since upgrading to v7.0;
>  
>  pf enabled
>  net.inet.ip.forwarding: 0 -> 1
>  net.inet6.ip6.forwarding: 0 -> 1
>  starting network
>  
>  ifconfig: SIOCSETPFLOW: Can't assign requested address
>  ifconfig: SIOCSETPFLOW: Can't assign requested address
>  
>  reordering libraries: done.
>  starting early daemons: syslogd pflogd unbound ntpd.
>  starting RPC daemons:.
>  savecore: no core dump
>  checking quotas: done.
>  clearing /tmp
>  kern.securelevel: 0 -> 1
>  creating runtime link editor directory cache.
>  preserving editor files.
>  starting network daemons: sshd snmpd dhcpd rad smtpd.
>  starting package daemons: dhcpcd.
>  starting local daemons: cron.
>  Sat Oct 16 08:06:39 AEDT 2021
>  
>  I am assuming it is related to the interface ‘pflow0’ which was working 
>  fine in version 6.9. The /etc/hostname.pflow0 is exactly the same as the 
>  examples in the man pages only that the source and destination IP 
>  addresses are different.
>  
>  Many thanks
>  
>  Antonino Sidoti
>  
>  
>  
> >>> 
> >>> Are you using DHCP to configure the interface the source IP is on?  
> >>> Provide some more details of the network setup.
> 



Re: How BSD Authentication Works

2021-10-21 Thread Theo de Raadt
Dante Catalfamo  wrote:

> Hello friends,
> 
> I just published a blog post about the BSD Authentication framework
> and I'm very excited to share it with you!
> 
> I'm not an OpenBSD developer but I tried my best to understand the
> system and how it works. Please let me know if I got anything wrong.
> 
> https://blog.lambda.cx/posts/how-bsd-authentication-works/

I think many people don't understand what BSD auth is:

It is an additional layer of privsep.

And whenever we have code that does privsep, we have an additional
opportunity to apply pledge/unveil to that process context.



Re: How does bsd.upgrade work?

2021-10-21 Thread Theo de Raadt
tetrahe...@danwin1210.me wrote:

> On Mon, Oct 18, 2021 at 07:41:57PM -, Stuart Henderson wrote:
> >> I resolved the problem. The solution was to run `sysupgrade -n` to
> >> download all the upgrade files, and leave the `bsd.upgrade` kernel in
> >> place, next to the `bsd` kernel I usually boot.
> >>
> >> Then, at the next boot, manually boot the `bsd.upgrade` kernel by
> >> specifying its location.
> >
> >Sounds like you aren't using the correct boot loader.
> 
> That's intentional.

Please do away.  We do not appreciate people attempting to monopolize
other's time the way you are doing.l




Re: How does bsd.upgrade work?

2021-10-21 Thread Theo de Raadt
tetrahe...@danwin1210.me wrote:

> On Mon, Oct 18, 2021 at 05:41:26PM +0200, Florian Obser wrote:
> >I wouldn't call this "resolved". You are missing the point that
> >bsd.upgrade should run automatically. *shrug*
> 
> My setup is not standard, so it's normal that bsd.upgrade not run
> automatically. The solution I used, as far as I know, is by far the
> simplest and easiest way of resolving the problem.

You've been told a few times that your vague "my setup is different" means
you shouldn't have asked.  If you introspect for more than a few minutes
you'll come to the same conclusion. Please stop wasting everyone's time.




OpenBSD 7.0 released, Oct 14

2021-10-14 Thread Theo de Raadt



- OpenBSD 7.0 RELEASED -

October 14, 2021.

We are pleased to announce the official release of OpenBSD 7.0.
This is our 51st release.  We remain proud of OpenBSD's record of more
than twenty years with only two remote holes in the default install.

As in our previous releases, 7.0 provides significant improvements,
including new features, in nearly all areas of the system:

 - New/extended platforms:
o Added new riscv64 platform for 64-bit RISC-V systems.
o The arm64 platform support was improved with the following
  changes:
   - Support for Apple Silicon Macs has improved but is not ready
 for general use yet:
  # Added support for installing on a disk with a GPT.
  # Added apldart(4) support for a DART with two sets of
registers, needed to support the Synopsis DesignWare USB
3 controller.
  # Added apldwusb(4), a glue driver for the Synopsys
DesignWare USB 3 controllers found on the Apple M1 SoC.
  # Added aplns(4) to provide support for Apple NVME storage
as found in Apple M1 devices.
  # Added aplpinctrl(4) driver for the Apple GPIO controller
found on the M1 SoCs.
  # Added aplpmu(4), a driver for the Apple "sera" SPMI
power management unit that contains the RTC on Apple M1
systems.
  # Added aplspmi(4), a driver for the Apple SPMI
controller.
   - Enabled LEDs for the mue(4) LAN7800 chip as found on the
 Raspberry Pi 3 Model B+.
   - Added rktcphy(4), a driver for the Type-C PHY controller
 found on the Rockchip RK3399.
   - Implemented multicast support in mvpp(4).
o Changes on other architectures:
   - Switched macppc to use ld.lld(1).
   - Fixed an issue preventing applications from selecting the
 non-ALTIVEC code path on macppc.
   - Made amd64 hw.setperf percentages proportional to the
 enhanced speed step frequencies on Intel processors. The
 default hw.setperf=99 corresponds to the maximum ordinary
 speed, and setting it to 100 enables turbo mode.
   - Enabled cy(4) on amd64.
   - Disabled base-gcc on amd64.
   - Prevented crashes on amd64 when TLB entries which should have
 been invalidated were used.
   - Prevented a kernel panic in sparc64 due to page boundary
 misalignment.
   - Forced luna88k to use the serial console when no graphics
 board is found.
   - Made additional free inodes on luna88k bsd.rd by specifying
 density=4096.
   - Fixed strchr() and strrchr() on mips64.
   - Prevented watchdog resets on some i.MX 64-bit machines with a
 recent U-Boot and watchdog enabled on boot in imxdog(8).
   - Created audio devices on armv7.
   - Retired OpenBSD/sgi platform.
   - Enabled MSI-X support for powerpc64.
   - Fixed __ppc_lock for page faults that recursively grab the
 lock on powerpc.
   - Increased the maximum data size on powerpc64 to 32GB.
   - Disabled global page table mappings when using PCID to
 prevent crashes when not flushed from TLB on amd64.
   - Added cduart(4) driver for Cadence Universal Asynchronous
 Receiver/Transmitter on armv7.
   - Added zqclock(4) driver for Xilinx Zynq-7000 clock controller
 on armv7.
   - Added zqreset(4) driver for Xilinx Zynq-7000 reset controller
 on armv7.

 - Various kernel improvements:
o Unlocked the top part of the VM fault handler on i386.
o Enabled dt(4) for GENERIC kernels on amd64, arm64, i386, sparc64,
  and powerpc64.
o Added kprobes provider for dt(4).
o Implemented < and > operators in btrace(8) filters.
o Added btrace(8) display of time spent in userland when analyzing
  the kernel stack in the flame graph tool and fixed a parsing bug.
o Introduced /etc/bsd.re-config(5), which can be used to configure
  the kernel using config(8), allowing use of KARL while making
  changes to the GENERIC kernel.
o Identify TPM 2.0 devices and perform the 2.0-specific suspend
  command, allowing the ThinkPad X1 Carbon Gen 9 and ThinkPad X1
  Nano with the latest BIOS (which added S3) to resume.
o Changed the printing of the hibernate image size from bytes to
  megabytes.
o Increased hibernate writeout speed.
o Added "machine sysregs" command to ddb(4) on amd64.
o Prevented interleaved stack traces in ddb(4) from multiple CPUs.
o Delayed installation of sensors until a device with battery
  support is connected, allowing sensorsd(8) to pick up hotplugged
  uhidpp(4) devices.
o Prevented a kernel panic after VFS shutdown.
o Increased the setitimer(2) timer limit to UINT_MAX seconds.
o Serialized the internals of kqueue(2) with a mutex.
o Enabled pool cache on knote(9) pool.
o Fixed 

  1   2   3   4   5   6   7   8   9   10   >