Re: [NEW]: net/hopm - open-proxy monitor irc bot

[Theo de Raadt]

Chaz Kettleson  wrote:

> My general thought here was since I only needed wpath/cpath for pid/log
> files, and I was not going to patch for syslog (still need to write pid
> anyway), I would at least unveil for only those files. The idea of
> unveil("/", "") just seemed like a sane default from other domains where
> a "block all, explicitly allow" makes sense.

It is not sane.  But also, it is not idiomatic.  You can't find this in
any other code. You made it up, it's an assumption that "everything
possible should be used, it is all free".  Try to explain what this does
and why it is needed and why noone else uses it?  You won't find a reason.

Re: firefox & vaapi [was: Enable VA-API in graphics/ffmpeg]

[Theo de Raadt]

I think you should give up on this.

I think by talking about "sandbox" in an abstract for what is going on,
it fails to describe the what is going on.  "sandbox" is an extremely
unspecific words and everyone brings in their weird understanding.

- the program (firefox) has extremely poor "privsep" bolted on after
  the fact, and uses the wrong resources in the wrong processes
- the library, is even worse.  It believes it can do everything.

If this was going to ever work fixed, it would require significant changes
in the library.  It is designed to operate in a "can do everything" model,
and is incompatible with desired constraints.

Landry Breuil  wrote:

> Le Wed, Aug 14, 2024 at 10:57:46AM +0200, Jan Stary a écrit :
> > > Can AMD users play https://www.youtube.com/watch?v=LXb3EKWsInQ in
> > > 2160p60 on FF without blowing the CPU?
> > 
> > On this AMD machine (dmesg and vainfo below),
> > firefox-129.0 plays this video eating about 14% of CPU.
> > 
> >   PID USERNAME PRI NICE  SIZE   RES STATE WAIT  TIMECPU COMMAND
> > 23106 hans   20  362M  414M sleep/0   kqread1:14 14.16% firefox
> > 77528 hans   20  427M  467M sleep/3   kqread1:32 11.38% firefox
> > 60891 hans   20   97M   98M idle  kqread0:20  3.27% firefox
> > 
> > That's with "media.ffmpeg.vaapi.enabled true" in about:config;
> > and about the same with "media.ffmpeg.vaapi.enabled false",
> > which confuses me.
> > 
> >   PID USERNAME PRI NICE  SIZE   RES STATE WAIT  TIMECPU COMMAND
> > 77528 hans   20  429M  470M sleep/5   kqread1:44 14.06% firefox
> > 23106 hans   20  379M  429M sleep/4   kqread1:25 12.94% firefox
> > 60891 hans   20   97M   98M sleep/3   kqread0:26  4.69% firefox
> > 
> > Is there a better metric of how much firefox video playing
> > is helped (or not) by vaapi? How can I even tell FF is using it?
> 
> whatever knob you frob, firefox is not using vaapi, because vaapi is
> *not* compatible as-is with the current sandboxing config.
> 
> there are wip patches in the vaapi branch of my git repo (which is on
> top of the beta branch), cf
> https://cgit.rhaalovely.net/mozilla-firefox/?h=vaapi
> 
> but right now it doesnt work because:
> - it tries dlopening libs with fixed .so.X version we dont have (easy to fix)
> - it tries opening the drm device read-write after sandboxing (harder to fix)
> - the xenocara/mesa gl stack itself also tries to open the drm device rw when
>   creating some gl context at some point
> 
> so things to explore:
> - pushing sandbox initialization 'later' once every needed fd is
>   opened/saved somewhere
> - add the required paths/pledge class for the various syscalls used when
>   decoding (eg during process main loop)
> 
> if you dont care about sandboxing, ofc you can disable it, but then
> you're on your own. and that wont work anyway because of the .so.X
> paths, but ppl like to workaround that by doing symlinks, which is no
> the correct 'fix' either.
> 
> check https://bugzilla.mozilla.org/show_bug.cgi?id=1911635 for the
> details of the various things i've tried so far.
> 
> to know the status of vaapi at runtime, try with
> env MOZ_LOG="FFmpegVideo:5,Dmabuf:5,OpenBSDSandbox:5" MOZ_GFX_DEBUG=1 firefox
> and of course a separate profile.
> 
> Landry
> 

Re: 18-year-old security flaw in Chromium and Firefox exploited in attacks

[Theo de Raadt]

You can try this yourself:

ping 0.0.0.0
ssh 0.0.0.0

or on a webserver machine

nc -v 0.0.0.0 80

It's the same for chrome, because it is the same for *all userland programs*

Re: 18-year-old security flaw in Chromium and Firefox exploited in attacks

[Theo de Raadt]

CIVINULL  wrote:

> https://www.bleepingcomputer.com/news/security/18-year-old-security-flaw-in-firefox-and-chrome-exploited-in-attacks/
> 
> I wonder if the sandboxing of Chromium and Firefox on OpenBSD will prevent it 
> from being affected by this vulnerability.

Sorry, our sandboxing efforts does not solve this problem.

Instead, the problem was fixed in a series of commits in 1998, when the
OpenBSD kernel stopped considering 255.255.255.255 and 0.0.0.0 as
referring to localhost.

sys/netinet/in.c

revision 1.4
date: 1998/02/25 03:45:14;  author: angelos;  state: Exp;  lines: +20 -4;
Disallow TCP connects to 255.255.255.255 or local broadcast addresses.
revision 1.5
date: 1998/02/25 04:53:09;  author: angelos;  state: Exp;  lines: +2 -2;
Pay attention.
revision 1.7
date: 1998/02/25 23:44:57;  author: deraadt;  state: Exp;  lines: +4 -17;
patch could not have been tested. panics machine on boot
revision 1.8
date: 1998/02/28 03:39:56;  author: angelos;  state: Exp;  lines: +20 -4;
Another shot at disallowing TCP connections to 255.255.255.255,
0.0.0.0 and any local broadcast addresses. Tested.


I suspect RFC's this work preceeded RFCs which didn't require that
bizzare historical behaviour; I have not dug into my mail archives
to remember how this played out.


I forget what protocol worried us back in those days, to let us to fix
it.  Today it is chrome and firefox.  Next year this will some other
protocol or program, because there are operating systems who don't want
to fix this issue (or issues like it) at the correct layer because they
don't are unwilling to perform an ecosystem study to find the rare things
using it, force their repair, and then cut out the tumour.

Re: Chromium VAAPI support

[Theo de Raadt]

José Maldonado  wrote:

> I agree with that Theo, but that's exactly why I'm asking, to find out
> if there are any known issues, not to put pressure on it.
> 
> I understand that Robert is the only one working on that port, in
> fact, I CC'd him so he can respond if there's any problem with it.

that's coming off as tone deaf.

> Anyway, right now I'm compiling the port with use_vaapi=true to test
> and report any issues.

but that is a step.  and it will probably blow up so badly, that you
didn't need to ask in the first place.

Re: Chromium VAAPI support

[Theo de Raadt]

This is so backwards.

What do you expect to happen?  Oh robert will commit it, without any
testing.  Oh and only he should work on it, right?  Noone else needs
to, they can just sit on the mailing list and ask "when?"

Yes there is a reason.  It is one guy doing it all, and asking is
NOT ACTUALLY HELPING.  Think about it.


José Maldonado  wrote:

> Hi everyone!
> 
> Seeing the progress of VAAPI support in OpenBSD + Firefox, yesterday I
> wanted to take a look at VAAPI support in Chromium. Checking the
> Chromium dev site, I see that there are a couple of options that need
> to be enabled to achieve this, and checking the port I see that they
> are currently disabled.
> 
> More precisely the option in question is:
> 
> GN_ARGS+= use_vaapi=false
> 
> Is there a reason that blocks VAAPI activation in Chromium at this
> point? Thanks for your response.
> 
> -- 
> "Dios en su Cielo, todo bien en la Tierra"
> ***
> 

Re: Enable VA-API in graphics/ffmpeg

[Theo de Raadt]

Landry Breuil  wrote:

> thanks, that's a start, because it makes us understand what files are
> opened by which process.
> 
> But you do realize this adds lots of capacities to those process types
> that arent needed right now, thus shouldnt be added.

That is correct.  What's being proposed is very close to the same
thing as just deleting the pledge calls entirely.  These two choices
are very close to each other:

+   pledge("everything")
-   pledge("something")

> The right process is to figure out _what_ codepaths open those
> libs/paths, and try to move those initializations *before* sandboxing,
> so that adding those capacities isnt needed. Preloading libs before
> sandboxing is a trick that has been done before (cf
> https://phabricator.services.mozilla.com/D193353 /
> https://bugzilla.mozilla.org/show_bug.cgi?id=1856301) now we need to add
> a bit more libs, make sure subsequent dlopens finds the preloaded lib,
> and do the same for the drm device fd. Right now wpath is needed because
> it tries to open /dev/dri/renderD128 read-write after sandboxing, doing
> that before sandboxing is the way to go.

Indeed.  this is how a majority of OpenBSD base programs were adapted
to pledge.  We even came up for the process, "hoisting", where the
security-requiring sections are lifted higher, or earlier, in the code.

Re: Enable VA-API in graphics/ffmpeg

[Theo de Raadt]

That's quite a step backwards for pledge usage.  The firefox privsep
story just keeps getting worse.

Re: elf_aux_info in the mozillas on arm64 (was: Re: aarch64 bulk build report)

[Theo de Raadt]

Mark Kettenis  wrote:

> In general I'd say shared objects should always be linked against
> libc.  But Theo will probably never agree with me.

Let's be accurate what this means.

It does not mean linking about libc.

It means encoding a specific libc.so.#.# as DT_NEEDED, which will cause
us complete garbage later on

Or maybe it means having /usr/lib/libc.so symbolic links?

All that kinds of stuff makes me just want to give up.  Maybe we
need to head the way of Linux, where ABI changes are not allowed.
Because they would become impossible, as they are in Linux.  (Please
don't tell me what Linux can "still add things to their ABI".  They
actually can't, without hundreds of hours of study, half the time
they try to add something, it shows they need to change something or
remove something else that isn't allowed by their stupid rules)

Locking us to names, or to files, or to symbolic links, is a non-starter.
It was never part of the design.  It's just that some stupid people
made bad unnecessary decisions.





This is a lot like the X va import, btw.  Unintended consequences
were not discovered ahead of time.  I'm not complaining, I'm just
saying 'cloning a compatible interface' often goes wrong.

Re: pledge/unveil for harec?

[Theo de Raadt]

Vevy Kod  wrote:

> 1. We do not need a good reason to reduce our attack surface. The
> likeliness of the scenarios we are preventing does not matter: those
> scenarios will become likely as soon as they become the easiest to
> exploit.

What is the attack surface?

> 2. It prevents unknowingly escalating a supply-chain attack. If a
> malware is somehow embedded in the compiler, it will be able to 1)
> read secret keys used by developers to sign binary packages, and 2)
> embed those secret keys in the compiler output (likely set for
> distribution).


If the compiler has malware, it will probably remove the unveil
and pledge.  You are bullshitting.

Re: pledge/unveil for harec?

[Theo de Raadt]

Please tell me what security problem unveil is solving in this program.

Vevy Kod  wrote:

> How about adding an environment variable containing all directories
> where headers can be found ?
> If it is not provided, we can fall back to the per-file algorithm,
> possibly going above limit.
> If a user goes above that limit, they can provide their own list of
> directories.
> And in the worst case, they can simply set it to '/', giving
> themselves read access to everything.
> 
> On 18/07/2024 17:43, Lorenz (xha) wrote:
> > the HARE_TD_ are the "typedef" files, basically the equivalent
> > to C headers, but automatically generated by the compiler so we can
> > do resolution of types/functions/etc. in dependencies without having
> > to look at the source files themselves.
> > i doubt that anyone is ever going to make use of more than 125
> > imports.
> > the problem is that i cannot simply restict that to one folder. they
> > could be anywhere (even though they are not usually). that'd complicate
> > the patch a lot for... allowing more than 125 imports?
> > the error message will not be particularly hard to read; i guess if
> > someone really hits the limit, we can do something about it then?
> > we don't want to do anything in upstream harec because we want to
> > keep it to the POSIX subset.
> > On Thu, Jul 18, 2024 at 09:29:39AM -0600, Theo de Raadt wrote:
> >> Tobias Heider  wrote:
> >>
> >>> I think unveil might still be useful.
> >>
> >> I don't think so.
> >>
> >>> As I understand Theo the problem is just that calling unveil per-input 
> >>> file to grant
> >>> read access won't work. Restricting write and create permissions to the 
> >>> single
> >>> well-known output directory still makes sense to me.
> >>>
> >>>>
> >>>> The set of library functions used is pretty small, so it should be easy
> >>>> enough to reason about adding pledge.
> >>>>
> >>>> $ nm -s /usr/local/bin/harec | awk '/^ *U / { print $2 }' | column
> >>>> __assert2atexit  fseek   memset  strerror
> >>>> __errno  bsearch fstat   open_memstream  strlen
> >>>> __isinf  calloc  getenv  optarg  strncmp
> >>>> __isinff exitgetline optind  strtod
> >>>> __isinfl fclose  getopt  perror  strtoul
> >>>> __isnan  feofisalnum qsort   
> >>>> strtoumax
> >>>> __isnanf fgetc   isalpha realloc vfprintf
> >>>> __isnanl fileno  isatty  snprintfvsnprintf
> >>>> __isthreaded fmemopenisdigit stat
> >>>> __sF fopen   isprint strchr
> >>>> _csu_finish  fread   memcmp  strcmp
> >>>> abortfreememcpy  strdup
> >>>>
> >>
> >> So the undocumented, un-exported, unveil limit today is 128.  This comes
> >> with a cost, so we will not be increasing it.
> >>
> >> Enough setenv, enough arguments, and it fails.  Now how does someone 
> >> "workaround"
> >> it in their build tooling?
> >>
> >> THAT "workaround" is what makes the solution.
> >>
> >> This is not what unveil is intended to support.
> > 

Re: pledge/unveil for harec?

[Theo de Raadt]

Lorenz (xha)  wrote:

> On Thu, Jul 18, 2024 at 09:50:56AM -0600, Theo de Raadt wrote:
> > Lorenz (xha)  wrote:
> > 
> > > On Thu, Jul 18, 2024 at 09:45:34AM -0600, Theo de Raadt wrote:
> > > > Lorenz (xha)  wrote:
> > > > 
> > > > > the HARE_TD_ are the "typedef" files, basically the equivalent
> > > > > to C headers, but automatically generated by the compiler so we can
> > > > > do resolution of types/functions/etc. in dependencies without having
> > > > > to look at the source files themselves.
> > > > > 
> > > > > i doubt that anyone is ever going to make use of more than 125 
> > > > > imports.
> > > > > 
> > > > > the problem is that i cannot simply restict that to one folder. they
> > > > > could be anywhere (even though they are not usually). that'd 
> > > > > complicate
> > > > > the patch a lot for... allowing more than 125 imports?
> > > > > 
> > > > > the error message will not be particularly hard to read; i guess if
> > > > > someone really hits the limit, we can do something about it then?
> > > > 
> > > > So tell us --- when someone hits that limit, what do they need to
> > > > do about it?
> > > > 
> > > > What do they do then?
> > > 
> > > modify this patch so it finds the common folder where the typedef
> > > files are in and unveil to it instead. that's what i would do.
> > 
> > 
> > 
> > You have not answered the question.
> > 
> > And by not answering it, you have not justified the use of unveil().
> 
> sorry, then i don't understand your question.

This change gets commited, and the package now does unveil.

A user on the internet finds out the package simply exits with a
message.

What do they do now?

The software is not fit for purpose.  You broke an actual use case.

Re: pledge/unveil for harec?

[Theo de Raadt]

Lorenz (xha)  wrote:

> On Thu, Jul 18, 2024 at 09:45:34AM -0600, Theo de Raadt wrote:
> > Lorenz (xha)  wrote:
> > 
> > > the HARE_TD_ are the "typedef" files, basically the equivalent
> > > to C headers, but automatically generated by the compiler so we can
> > > do resolution of types/functions/etc. in dependencies without having
> > > to look at the source files themselves.
> > > 
> > > i doubt that anyone is ever going to make use of more than 125 imports.
> > > 
> > > the problem is that i cannot simply restict that to one folder. they
> > > could be anywhere (even though they are not usually). that'd complicate
> > > the patch a lot for... allowing more than 125 imports?
> > > 
> > > the error message will not be particularly hard to read; i guess if
> > > someone really hits the limit, we can do something about it then?
> > 
> > So tell us --- when someone hits that limit, what do they need to
> > do about it?
> > 
> > What do they do then?
> 
> modify this patch so it finds the common folder where the typedef
> files are in and unveil to it instead. that's what i would do.



You have not answered the question.

And by not answering it, you have not justified the use of unveil().

Re: pledge/unveil for harec?

[Theo de Raadt]

Lorenz (xha)  wrote:

> the HARE_TD_ are the "typedef" files, basically the equivalent
> to C headers, but automatically generated by the compiler so we can
> do resolution of types/functions/etc. in dependencies without having
> to look at the source files themselves.
> 
> i doubt that anyone is ever going to make use of more than 125 imports.
> 
> the problem is that i cannot simply restict that to one folder. they
> could be anywhere (even though they are not usually). that'd complicate
> the patch a lot for... allowing more than 125 imports?
> 
> the error message will not be particularly hard to read; i guess if
> someone really hits the limit, we can do something about it then?

So tell us --- when someone hits that limit, what do they need to
do about it?

What do they do then?

Re: pledge/unveil for harec?

[Theo de Raadt]

Stuart Henderson  wrote:

> On 2024/07/18 05:27, Theo de Raadt wrote:
> > This is not right.
> > 
> > Only a maximum number of unveil's are allowed, before it starts returning
> > E2BIG.  That amount is not a public #define, to discourage what you are
> > doing.
> > 
> > You are trying to shove an unbounded number of them into the kernel, based
> > upon getenv and argv.
> > 
> > When you run out, and will exit with error.  That's not very nice is it?
> > 
> 
> I think the place where unveil really gives the most benefit is for
> software which needs both network and filesystem access in the same
> process. Much of the protection that Lorenz is looking for would come
> from pledge without needing to consider unveil.

That is correct.

The true risks are when exploited programs have full-network and
full-filesystem.  This has no network, so the (incorrectly fragile)
unveil use is just breaking the program.

Re: pledge/unveil for harec?

[Theo de Raadt]

Tobias Heider  wrote:

> I think unveil might still be useful.

I don't think so.

> As I understand Theo the problem is just that calling unveil per-input file 
> to grant
> read access won't work. Restricting write and create permissions to the single
> well-known output directory still makes sense to me.
> 
> > 
> > The set of library functions used is pretty small, so it should be easy
> > enough to reason about adding pledge.
> > 
> > $ nm -s /usr/local/bin/harec | awk '/^ *U / { print $2 }' | column
> > __assert2   atexit  fseek   memset  strerror
> > __errno bsearch fstat   open_memstream  strlen
> > __isinf calloc  getenv  optarg  strncmp
> > __isinffexitgetline optind  strtod
> > __isinflfclose  getopt  perror  strtoul
> > __isnan feofisalnum qsort   
> > strtoumax
> > __isnanffgetc   isalpha realloc vfprintf
> > __isnanlfileno  isatty  snprintfvsnprintf
> > __isthreadedfmemopenisdigit stat
> > __sFfopen   isprint strchr
> > _csu_finish fread   memcmp  strcmp
> > abort   freememcpy  strdup
> > 

So the undocumented, un-exported, unveil limit today is 128.  This comes
with a cost, so we will not be increasing it.

Enough setenv, enough arguments, and it fails.  Now how does someone 
"workaround"
it in their build tooling?

THAT "workaround" is what makes the solution.

This is not what unveil is intended to support.

Re: pledge/unveil for harec?

[Theo de Raadt]

This is not right.

Only a maximum number of unveil's are allowed, before it starts returning
E2BIG.  That amount is not a public #define, to discourage what you are
doing.

You are trying to shove an unbounded number of them into the kernel, based
upon getenv and argv.

When you run out, and will exit with error.  That's not very nice is it?

Re: security/vpnc: dhclient -> ifconfig inet autoconf

[Theo de Raadt]

Stuart Henderson  wrote:

> This change won't work directly as the following lines currently need 
> blocking until dhcp has fetched an address but I don't think it's worth it. 

Right.

We have entered a world where dynamic address negotiation is async.
But then, it always was.

Re: ruby arm64 BTI

[Theo de Raadt]

Mark Kettenis  wrote:

> > From: "Theo de Raadt" 
> > Date: Sat, 22 Jun 2024 06:16:03 -0600
> > 
> > Mark Kettenis  wrote:
> > 
> > > Theo pointed out the NOBTCFI reversal here.  Now the reason that we
> > > still see SIGILL despite fixes to the assembly code is because the
> > > -mbranch-protection=pac-ret option added by the configure script
> > > actually downgrades our default of enabling both BTI and PAC to just
> > > enabling PAC.  So the necessary BTI instructrions were missing from
> > > the C code.
> > 
> > How did this issue arise?  Is PAC without BTI the case on MacOS?
> 
> Well, M1 did have PAC but no BTI.  BTI only came with M2.
> 
> > > With the diff below things seem to work fine on Apple M2.  There is
> > > one failure in the testsuite:
> > >   1) Failure:
> > > TestIO_Console#test_failed_path 
> > > [/home/ports/pobj/ruby-3.3.3/ruby-3.3.3/test/io/console/test_io_console.rb:46]:
> > > [Errno::ENODEV, Errno::ENOTTY, Errno::EBADF, Errno::ENXIO] exception 
> > > expected, not #.
> > > 
> > > but I'm pretty sure that is unrelated to BTI support.
> > 
> > I suspect that's the recent delution over "isatty is poorly standardized,
> > and we believe it should return linux errno".
> 
> Not sure if it isatty(3), but it is related to an ioctl on /dev/null.
> And we have a problem in OpenBSD here.
> 
> On amd64, the mmioctl() function returns ENODEV for unimplemented
> ioctls.  And this is one of the values that ruby expects.  But on most
> other architectures mmioctl() return EOPNOTSUPP.  I think that's a bug
> introduced 23 years ago by christos when an MI mmioctl() was
> introduced in NetBSD that got somehow copied into our MD variants of
> mmioctl().

Yes, that is a bug.

> That said, I think the actual correct return value should be ENOTTY is
> that is what our man page and POSIX say.  And that would probably fix
> isatty(3) as well, which according to the man page should return
> ENOTTY if the file descriptor isn't associated with a terminal.  This
> is what modern FreeBSD does.

This remains contentious:

https://austingroupbugs.net/view.php?id=618

Re: ruby arm64 BTI

[Theo de Raadt]

Mark Kettenis  wrote:

> Theo pointed out the NOBTCFI reversal here.  Now the reason that we
> still see SIGILL despite fixes to the assembly code is because the
> -mbranch-protection=pac-ret option added by the configure script
> actually downgrades our default of enabling both BTI and PAC to just
> enabling PAC.  So the necessary BTI instructrions were missing from
> the C code.

How did this issue arise?  Is PAC without BTI the case on MacOS?

> With the diff below things seem to work fine on Apple M2.  There is
> one failure in the testsuite:
>   1) Failure:
> TestIO_Console#test_failed_path 
> [/home/ports/pobj/ruby-3.3.3/ruby-3.3.3/test/io/console/test_io_console.rb:46]:
> [Errno::ENODEV, Errno::ENOTTY, Errno::EBADF, Errno::ENXIO] exception 
> expected, not #.
> 
> but I'm pretty sure that is unrelated to BTI support.

I suspect that's the recent delution over "isatty is poorly standardized,
and we believe it should return linux errno".

Re: lang/node & net/libcares weirdness

[Theo de Raadt]

Theo de Raadt  wrote:

> Stuart Henderson  wrote:
> 
> > On 2024/05/08 01:14, Volker Schlecht wrote:
> > > aisha@ identified a rather recent problem with lang/node, as in the 
> > > following
> > > would immediately crash (nevermind the node version. It's 100% 
> > > reproducible
> > > in 7.5 and -current):
> > > 
> > > $ node
> > > Welcome to Node.js v20.12.2.
> > > Type ".help" for more information.
> > > > require('dns').resolve4('openbsd.org','A',(err, records) => 
> > > > {console.log(records);});
> > > 
> > > I tracked this back to the following pull request in libcares:
> > > 
> > > https://github.com/c-ares/c-ares/pull/659
> > 
> > So, specifically, this patch is setting SOCK_DNS for the situation where
> > somebody using this library _might_ use pledge, but node is not using
> > pledge.
> 
> That is just plain dumb.
> 
> If a socket is marked SOCK_DNS then it is *just for DNS*, and only the
> very narrow set of operations used by libc/asr are supported.
> 
> Actually it is dumb, because it wasn't tested at all.


BTW, this use case in OpenBSD is *DEAD*.

If you want to use pledge, you must sign up for the DNS-sockets-are-special
protocol.  There are no options.  If you don't sign up for that, then you
cannot use pledge.   This will not be negotiated.  This design is deliberate.

I could have instead created a completely parallel set of system calls for
doing DNS, and also blocked port 53 on regular sockets.  It would have worked
the same way. The goal is CLEAR, you cannot accidentally perform DNS except
via the published API.   Yes, this means non-libc API for doing DNS are dead
in the water.  This should not be surprising; it is impossible for a non-system
DNS "library" to behave identical to other software running on the machine
since it will not have all the configuration policy / details embeddeed in
resolv.conf or other similar changes we've made.

Well you can stil use it.  You just cannot use any of the POSIX-subsets provided
by pledge, which is also not surprising.  pledge was not designed to interop
with billions of lines of foreign code that we don't know, it was only designed
to interop with code that we do know.  I'm human, I cannot anticipate 
everything.
So I drew a line: You can't just throw pledge around a random bag of garbage
software and expect it to work, you must USE YOUR BRAIN, and if you don't, the
node/c-ares outcome is exactly what you can expect.

Re: lang/node & net/libcares weirdness

[Theo de Raadt]

Stuart Henderson  wrote:

> On 2024/05/08 01:14, Volker Schlecht wrote:
> > aisha@ identified a rather recent problem with lang/node, as in the 
> > following
> > would immediately crash (nevermind the node version. It's 100% reproducible
> > in 7.5 and -current):
> > 
> > $ node
> > Welcome to Node.js v20.12.2.
> > Type ".help" for more information.
> > > require('dns').resolve4('openbsd.org','A',(err, records) => 
> > > {console.log(records);});
> > 
> > I tracked this back to the following pull request in libcares:
> > 
> > https://github.com/c-ares/c-ares/pull/659
> 
> So, specifically, this patch is setting SOCK_DNS for the situation where
> somebody using this library _might_ use pledge, but node is not using
> pledge.

That is just plain dumb.

If a socket is marked SOCK_DNS then it is *just for DNS*, and only the
very narrow set of operations used by libc/asr are supported.

Actually it is dumb, because it wasn't tested at all.

Re: firefox spawns native helpers without environment

[Theo de Raadt]

Lennart Jablonka  wrote:

> Quoth Landry Breuil:
> >Le Thu, Mar 28, 2024 at 02:52:52PM +, Lennart Jablonka a écrit :
> >> I’m trying to get himitsu-firefox¹ working on OpenBSD.  It’s a Firefox
> >> extension that talks to a daemon² using “native messaging”: The extension
> >> calls runtime.connectNative(); the browser spawns a himitsu-firefox-native
> >> process, and extension and native process exchange JSON messages.
> >>
> >> The native process wants to talk to the daemon using the daemon’s socket in
> >> $XDG_RUNTIME_DIR/himitsu.  Problem is, the himitsu-firefox-native process’s
> >> environment is empty—it doesn’t get no XDG_RUNTIME_DIR variable, or any
> >> other one.
> >>
> >> How come?  Is that documented somewhere?  Can I change that somehow?
> >
> >you can look with ktrace -i to figure out the env passed to the
> >subprocess when it's spawned (look for the execv call)
> 
> As far as I can tell, the ktrace doesn’t actually include the
> environment.  This is the exec syscall:
> 
>   60933 firefox-esr CALL  
> execve(0xeea86ca88d0,0xeea4ed16160,0xeea61f97550)
>   60933 firefox-esr NAMI  "/usr/local/libexec/himitsu-firefox-native"
>   60933 firefox-esr ARGS
>  [0] = "/usr/local/libexec/himitsu-firefox-native"
>  [1] = 
> "/usr/local/lib/mozilla/native-messaging-hosts/himitsu.json"
>  [2] = "himi...@drewdevault.com"
>   98832 firefox-esr RET   sched_yield 0
>   60933 himitsu-firefox-native NAMI  "/usr/libexec/ld.so"
>   60933 himitsu-firefox-native RET   execve JUSTRETURN

ktrace does print the environment.

There is some kind of environment.  The 3rd argument of execve is
0xeea61f97550, so there is an array containing at least something.

Re: archivers/pixz: new port (1.0.7)

[Theo de Raadt]

Thomas Dettbarn  wrote:

> I know sir.
> My apologies.
> 
> What I actually meant to say was
> 
> "Please, Sirs, somebody check the port! I am not qualified enough to
> do so myself."

That is why it was mailed out.  So that people could review it.

The peanut gallery who isn't going to review, has no right to make such
a request or demand.  It's quite simply very rude to assume all the people
who will review aren't already doing so.

Re: archivers/pixz: new port (1.0.7)

[Theo de Raadt]

Thomas Dettbarn  wrote:

> Hello.
> 
> 
> Yeah... You know how the social engineering part of this xz
> backhole was done?
> 
> Somebody pressured the Maintainer, that he needs to add new
> features.
> 
> Afterwards, the maintainers of distributions were pressured to
> update, because there were some "NEW FEATURES" available.
> 
> Your post sounded eerie similar. As do some of the gitlog entries.
> 
> 
> Just my two cents...
> (I am sure that I have not yet earned the privilege to post it on this list,
> but I felt like I had to say something. Blame it on poor impulse control!)


I think that is an uneducated take on the situation.  It sounds like:

"I can't really tell, but I'm very suspicious, I'm not going to put
any effort into justifying my suspiciouns, but in the meantime maybe
it is better if everyone stop all open source work of any sort
immediately.  Just my pointless two cents."


> On 4/1/24 12:55, Kirill A. Korinsky wrote:
> > Folks,
> >
> > Despite of current security issue with xz/lzma the algortihm itself provides
> > great compression, and the existing XZ Utils provide great compression in
> > the .xz file format, but they produce just one big block of compressed data.
> >
> > Here, a new port which is called archivers/pixz which produces a collection
> > of smaller blocks which makes random access to the original data possible.
> > This is especially useful for large tarballs.
> >
> > This can be used as seprated application or via tar, that described on
> > homepage: https://github.com/vasi/pixz
> >
> > --
> > wbr, Kirill
> 

Re: Chromium browsers: Meet + webcam = SIGILL?

[Theo de Raadt]

With a bit of effort, the address you see:

 addr=0x67cb1d220

can be compared in the ktrace to earlier mmap() operations (done by the
shared library linker ld.so); those mmap are mappings against a file descriptor,
and you can see what library file ld.so opened just previously... then we know
what library still has a BTI issue.

Laurence Tratt  wrote:

> On Mon, Mar 11, 2024 at 12:25:52PM +, Stuart Henderson wrote:
> 
> Hello Stuart,
> 
> >> On current, with packages upto date as of Saturday, I get a consistent
> >> SIGILL with Google Meet and the 3 Chromium browsers I'm aware of
> >> (Chromium, Iridium, Ungoogled-Chromium). It seems like it might be
> >> something to do with webcam/video processing in these browsers, but I'm
> >> far from sure.
> >>
> >> To replicate here's what I do:
> >>
> >> 1. Open a new private window (this probably isn't important but force of
> >> habit, but does mean a somewhat more consistent setup).
> >>
> >> 2. Go to meet.google.com and sign in.
> >>
> >> 3. Start a new meeting, and enable both microphone and webcam. As soon
> >> as the main "you should be able to see everyone else screen" is about to
> >> start, I get SIGILL.
> ...
> > Please ktrace and kdump | grep ILL, it should show the type of SIGILL. If
> > you're on Intel 11th gen or newer there's a good chance it will be
> > IBT-related.
> 
> Stuart pointed out off-list that `ktrace -i` is needed. With that I get:
> 
>   69377 chrome   PSIG  SIGILL SIG_DFL code=ILL_BTCFI addr=0x67cb1d220 
> trapno=21
> 
> I'm not sure if/how to get a backtrace out of any of the Chrome variants...
> 
> 
> Laurie
> 

Re: devel/libffi: arm64 BTI fix

[Theo de Raadt]

Crazy.  Looks good.


Mark Kettenis  wrote:

> This one was a bit tricky as I had to adjust the offsets used in the
> instructions.  But with this lang/guile3 no longer generates SIGILL
> when running the tests.
> 
> ok?
> 
> 
> Index: devel/libffi/Makefile
> ===
> RCS file: /cvs/ports/devel/libffi/Makefile,v
> retrieving revision 1.49
> diff -u -p -r1.49 Makefile
> --- devel/libffi/Makefile 22 Nov 2023 14:18:03 -  1.49
> +++ devel/libffi/Makefile 7 Mar 2024 22:06:25 -
> @@ -1,7 +1,7 @@
>  COMMENT= Foreign Function Interface
>  
>  V=   3.4.4
> -REVISION=0
> +REVISION=1
>  DISTNAME=libffi-$V
>  SHARED_LIBS +=  ffi  2.0  # 9.2
>  CATEGORIES=  devel
> Index: devel/libffi/patches/patch-src_aarch64_ffi_c
> ===
> RCS file: /cvs/ports/devel/libffi/patches/patch-src_aarch64_ffi_c,v
> retrieving revision 1.1
> diff -u -p -r1.1 patch-src_aarch64_ffi_c
> --- devel/libffi/patches/patch-src_aarch64_ffi_c  22 Nov 2023 14:18:03 
> -  1.1
> +++ devel/libffi/patches/patch-src_aarch64_ffi_c  7 Mar 2024 22:06:25 
> -
> @@ -74,3 +74,15 @@ Index: src/aarch64/ffi.c
>   : "memory", "v16", "v17", "v18", "v19");
>   }
>   #endif
> +@@ -873,8 +885,9 @@ ffi_prep_closure_loc (ffi_closure *closure,
> + # endif
> + #else
> +   static const unsigned char trampoline[16] = {
> +-0x90, 0x00, 0x00, 0x58, /* ldr  x16, tramp+16   */
> +-0xf1, 0xff, 0xff, 0x10, /* adr  x17, tramp+0*/
> ++0x5f, 0x24, 0x03, 0xd5, /* bti  c   */
> ++0x70, 0x00, 0x00, 0x58, /* ldr  x16, tramp+16   */
> ++0xd1, 0xff, 0xff, 0x10, /* adr  x17, tramp+0*/
> + 0x00, 0x02, 0x1f, 0xd6  /* br   x16 */
> +   };
> +   char *tramp = closure->tramp;
> 

Re: [mpv] --vo=gpu not working, permission denied

[Theo de Raadt]

This is because the fbtab subsystem is quite broken.  No good
alternative designs have come forward.

Stefan Hagen  wrote:

> beecdadd...@danwin1210.de wrote (2024-02-26 22:54 CET):
> > libEGL warning: failed to open /dev/dri/card0: Permission denied
> 
> You can fix it with: chown  /dev/dri/card0 /dev/dri/renderD128
> 
> Xenodm does this automatically when you log in.
> See /etc/X11/xenodm/GiveConsole
> 
> The permission are also set when you log in on ttyC0.
> See /etc/fbtab and fbtab(5)
> 
> Therefore the permissions are changing when you jump out of X
> with ctrl+alt+f1 and log in as root. When you hop back into X,
> the permissions are wrong.
> 
> This only happens on the first console. Use another one instead 
> (ctrl+alt+f2,3,4) while using X.
> 
> Best Regards,
> Stefan
> 

Re: acme-client: add challenge hook to support dns-01

[Theo de Raadt]

Christopher Zimmermann  wrote:

> Thanks for your feedback guys. I tried to improve the interface by
> calling the hook for each challenge challenge individually and send
> information from acme-client via environment variables, which are
> checked against a restrictive alphabet. This makes dropping privileges
> easier and passing random crap from the internet harder.
> 
> Privileges can now be dropped with this idiom:
> 
> [ `/usr/bin/who -m |cut -d ' ' -f 1` == 'nobody' ] ||
>   exec /usr/bin/su -s /bin/sh nobody -s "$@" <"$0"

Wow.  Just wow.  No way.  That's the type of stuff people did
in 1999.

These days, we build the minimal narrow layers of communication between
things, and we don't throw a shell script in there that uses "nobody" as
a safe UID (it is not a safe UID).

Re: acme-client: add challenge hook to support dns-01

[Theo de Raadt]

> populated by the acme-client hook and cleared after authorization.
> nsd can reload zonefiles on SIGHUP.

Sending the signal requires privs.  What's the plan?

Re: devel/objfw: add BTCFI landing pads for amd64 and arm64

[Theo de Raadt]

Jonathan Schleifer  wrote:

> Fixed upstream:
> https://objfw.nil.im/info/262baf76e7e66bc4
> https://objfw.nil.im/info/d73a388ecaf73b2a
> 
> New release:
> https://objfw.nil.im/downloads/objfw-1.0.10.tar.gz
> https://objfw.nil.im/downloads/objfw-1.0.10.tar.gz.sig
> 
> Am 24.02.24 um 22:17 schrieb Mark Kettenis:
> 
> > Ah, right.  What happens in that case is that the branch will use
> > register X16 or X17 and those are special in the sense that both "bti
> > c" and "bti j" landing pads are ok.
> 
> Ah. Is that OpenBSD specific or on every OS? I used "bti jc" upstream
> now to be on the safe side. I think security-wise it shouldn't make
> much of a difference since it's still before the function prologue?

Today: OpenBSD.

In a few years, more and more software.

In a decade, all operating systems.

Re: [crash] feh: illegal hardware instruction (core dumped)

[Theo de Raadt]

That is a missing BTI instruction.  Next package snapshot fixes it.

Mikhail  wrote:

> core:~$ sysctl kern.version
> kern.version=OpenBSD 7.5-beta (GENERIC.MP) #22: Fri Feb 23 19:29:07 MST 2024
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> Latest packages.
> 
> core:~/Downloads$ feh openbsd\ \(1\).jpg
> zsh: illegal hardware instruction (core dumped)  feh openbsd\ \(1\).jpg
> 
> core:~/Downloads$ egdb feh feh.core
> GNU gdb (GDB) 9.2
> Copyright (C) 2020 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-unknown-openbsd7.5".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> 
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from feh...
> (No debugging symbols found in feh)
> [New process 123074]
> Core was generated by `feh'.
> Program terminated with signal SIGILL, Illegal instruction.
> #0  0x009c63a03e20 in jsimd_h2v2_merged_upsample_avx2 () from 
> /usr/local/lib/libjpeg.so.70.2
> (gdb) bt
> #0  0x009c63a03e20 in jsimd_h2v2_merged_upsample_avx2 () from 
> /usr/local/lib/libjpeg.so.70.2
> #1  0x009c63a4b9e2 in merged_2v_upsample () from 
> /usr/local/lib/libjpeg.so.70.2
> #2  0x009c63a45124 in process_data_simple_main () from 
> /usr/local/lib/libjpeg.so.70.2
> #3  0x009c63a3e469 in jpeg_read_scanlines () from 
> /usr/local/lib/libjpeg.so.70.2
> #4  0x009c068f6596 in _load () from /usr/local/lib/imlib2/loaders/jpeg.so
> #5  0x009b9eb9f0d3 in __imlib_LoadImage () from 
> /usr/local/lib/libImlib2.so.9.0
> #6  0x009b9eb86631 in imlib_load_image_with_error_return () from 
> /usr/local/lib/libImlib2.so.9.0
> #7  0x009985fc88d4 in feh_load_image ()
> #8  0x009985fe20f1 in winwidget_create_from_file ()
> #9  0x009985fda4c1 in init_slideshow_mode ()
> #10 0x009985fd08f6 in main ()

Re: devel/ffcall: ENDBR64

[Theo de Raadt]

Looks good enough.  (I mean good enough for those two stupid ports)

Re: acme-client: add challenge hook to support dns-01

[Theo de Raadt]

Florian Obser  wrote:

> On 2024-02-20 22:32 +01, Christopher Zimmermann  wrote:
> > Hi,
> >
> > this diff adds a challenge hook to acme-client. This hook can be used
> > to fulfill challenges. For example by putting the requested files onto
> > a remote http server (http-01 challenge) or by modifying dns records
> > (dns-01 challenge). The latter are needed to obtain wildcard
> > certificates.
> > Is this diff ok? Is the design of the hook interface sane? Any
> > feedback is welcome.
> >
> 
> I'm not convinced passing random crap coming from the internet to a
> shell script running as root is a good idea.

I also think this is a mistake.  The proposed hook mechanism seems too
powerful and overly general.

To avoid that, maybe consider the minimum it could do, and still work.
I think it should perform an action based only upon pre-configured
information.  Then the server can do it's job, and the hook mechanism
watches for the job to be finished. Then the hook mechanism should
communicate what it sees back (without any dangerous inspection
or interpretation) to the main client engine for decision making.

Something like that.  The diff is hard to read for some reason, it seems
to lack refactoring and abstraction.

Re: www/hugo exits with illegal instruction

[Theo de Raadt]

Rafael Sadowski  wrote:

> I see the same illegal instruction with the latest packages and latest
> base:
> 
> fuckup$ hugo
> Illegal instruction (core dumped)
> 
> fuckup$ dmesg | head -1
> OpenBSD 7.5-beta (GENERIC.MP) #7: Tue Feb 20 11:09:18 MST 2024
> 
> ktrace:
> 
>  92986 hugo CALL  
> mmap(0,0x4,0x3,0x1002,-1,0)
>  92986 hugo RET   mmap 11072319488/0x293f63000
>  92986 hugo CALL  
> mmap(0,0x4,0x3,0x1002,-1,0)
>  92986 hugo RET   mmap 10030714880/0x255e09000
>  92986 hugo CALL  
> mmap(0,0x3000,0x3,0x1002,-1,0)
>  92986 hugo RET   mmap 11094835200/0x2954dc000
>  92986 hugo CALL  kbind(0x7e5873ba8528,24,0x47f5f02b048179b4)
>  92986 hugo RET   kbind 0
>  92986 hugo CALL  kbind(0x7e5873ba8528,24,0x47f5f02b048179b4)
>  92986 hugo RET   kbind 0
>  92986 hugo CALL  kbind(0x7e5873ba8508,24,0x47f5f02b048179b4)
>  92986 hugo RET   kbind 0
>  92986 hugo PSIG  SIGILL SIG_DFL code=ILL_ILLOPC addr=0x2ff6d00 trapno=21
>  92986 hugo NAMI  "hugo.core"

ktrace helped you find it is a SIGILL, with code=ILL_ILLOPC.  I can already
see trapno=21, and assuming this is amd64, that is

#define T_CP21  /* control protection exception */

That ILL_ILLOPC will change to ILL_BTCFI in the near future.

OK, so this is a missing IBT instruction.  ktrace helped you find that out
quickly.

Now you go into gdb, re-create the condition live, and find out what function
it is related to.

Re: (changed subject) Re: net/i2pd: FD talk and limits and ISP routers too weak maybe

[Theo de Raadt]

I'm out of here.

beecdadd...@danwin1210.de wrote:

> oh, Theo, if I were to start changing thing to the perfect OS security-wise,
> it wouldn't even look like OpenBSD code anymore, but OpenBSD still best what
> world have to offer
> 
> so do you agree with my logic? at least give me that
> at least tell me is this how things stand FD-wise/limit-wise/whatever, you
> probably know the best out of all I e-mailed with
> 
> no attempt yet,in future I hope,it's not a I am too lazy reason
> 
> On Tue, January 30, 2024 3:58 pm, Theo de Raadt wrote:
> > beecdadd...@danwin1210.de wrote:
> >
> >> I know system shares all resources including FDs
> >> as far as I know there's what kernel/OS needs and is using and the rest of
> >> users including but not limited to staff and daemon users/programs like
> >> i2pd all I was wondering is the limit or amount of FDs and other resources
> >> the rest of users of daemon can use in my head is a total amount which
> >> apparently is unknown (I have been told why, but how can anyone work with
> >> that? it's like relying on someone mentally unstable) which is then 
> >> devided,
> >> kernel/OS gets all that it needs, users and daemons get the rest which IS
> >> DIVIDED (in my head) until there is no more to
> >> divide/give away/share am I close?
> >>
> >> okay maybe not make all available resources to 1 program is not how it
> >> works but why not if that's the only programs that's running? I do not
> >> understand if it's even possible to do what I'm asking or questioning, I am
> >> not a OS dev because of reasons, but I like discussing such because I like
> >> OS-dev
> >>
> >>
> >> and just because what I ask isn't how it works doesn't mean it's bad? it
> >> could mean
> >
> > You've been provided with all the source code.
> >
> >
> > Where is your attempt to change things?
> >
> >
> >
> 
> 

Re: (changed subject) Re: net/i2pd: FD talk and limits and ISP routers too weak maybe

[Theo de Raadt]

beecdadd...@danwin1210.de wrote:

> I know system shares all resources including FDs
> as far as I know there's what kernel/OS needs and is using and the rest of
> users including but not limited to staff and daemon users/programs like i2pd
> all I was wondering is the limit or amount of FDs and other resources the rest
> of users of daemon can use
> in my head is a total amount which apparently is unknown (I have been told
> why, but how can anyone work with that? it's like relying on someone mentally
> unstable) which is then devided, kernel/OS gets all that it needs, users and
> daemons get the rest which IS DIVIDED (in my head) until there is no more to
> divide/give away/share
> am I close?
> 
> okay maybe not make all available resources to 1 program is not how it works
> but why not if that's the only programs that's running?
> I do not understand if it's even possible to do what I'm asking or
> questioning, I am not a OS dev because of reasons, but I like discussing such
> because I like OS-dev
> 
> and just because what I ask isn't how it works doesn't mean it's bad? it could
> mean

You've been provided with all the source code.

Where is your attempt to change things?

Re: (changed subject) Re: net/i2pd: FD talk and limits and ISP routers too weak maybe

[Theo de Raadt]

beecdadd...@danwin1210.de wrote:

> maybe not automatically, but having a utility that does this for you and you
> can run it once after each hardare change to find out, but I am not sure you
> say it depends on use-case, I do not understand what you mean
> 
> if you read my earlier replies, you would find out that I said I already tried
> searching online for like 1 hour, there is some sort of crazy formula one dude
> did a lot of math, snipets from code, is that what you mean?
> because what you say sound like there are multiple types of FDs, maybe network
> FDs and normal FDs?


You are failing to understand the operating system is intending to be a
"sharing" environment -- it is sharing limited resources among multiple 
consumers.

A large number of heuristics exist to defend this sharing, rather than
making resources available to just the 1 piece of software you want.

What you want isn't how it works.

Re: net/i2pd: move login.conf(5) bits from README to i2pd.login

[Theo de Raadt]

there is another possibility is everyone is out to get you.

beecdadd...@danwin1210.de wrote:

> anyone who cares about it - is using i2pd, and those that don't should if you
> understand me
> 
> not everyone knows ins and outs of everything or have time, by enabling their
> software to run at full potential should be priority
> 
> unless there are some unknown to me consequences of high number of openfiles?
> I tried searching online but found little, why does a limit kern.maxfiles have
> to be manually set and how can someone even know the hard true limit that
> wouldn't cause crashes (I assume that's what happens when system runs out of
> file descriptors I read it)
> 
> - best regards, didn't sleep who sleeps these days?
> 
> On Sun, January 28, 2024 8:21 pm, Theo de Raadt wrote:
> > beecdadd...@danwin1210.de wrote:
> >
> >> why are yo uignoring my reply? 4096 doesn't cover everyone like I said
> >> people can become floodfills automatically and floodfills means 8192
> >
> > the 1 person who cares can change the default.
> >
> >
> 
> 

Re: net/i2pd: move login.conf(5) bits from README to i2pd.login

[Theo de Raadt]

beecdadd...@danwin1210.de wrote:

> why are yo uignoring my reply? 4096 doesn't cover everyone like I said people
> can become floodfills automatically and floodfills means 8192

the 1 person who cares can change the default.

Re: irrlamb vs ctype.h

[Theo de Raadt]

> To my understanding it's an old BSDism and it's used to implement
> isupper(3), islower(3), etc.

The names may be old BSD, but this is following a pretty strong ISO rule
that names starting with '_' are in reserved, and trying to use them
yourself is undefined.

Changing them to another name that won't collide?  Maybe, I've no opinion.

Re: libffi: fix arm64 bti

[Theo de Raadt]

I think it is funny how exceedingly precise we are being in .S files
to not place *one extra dangerous bti* instruction.

Meanwhile, the C compilers don't know what will happen, so they slam
unused bti all over the place!  But that's why we hope purging these
at link time, as "mold" now does, is going to show up in other linkers.

Re: amd64: llvm 16 fallout (2023-11-14)

[Theo de Raadt]

Theo Buehler  wrote:

> > security/pivy   configure: cannot compute sizeof (int)
> 
> A function call while compiled with -fzero-call-used-regs=all runs into
> retguard. Downgrading to -fzero-call-used-regs=used makes it work.

this suggests that zero-call-used-regs is broken and touching a register
it is not allowed to use.

it probably needs to be disabled ENTIRELY, before it causes more problems
elsewhere.

Re: socat does not provide TUN/TAP support

[Theo de Raadt]

you would need to talk to socat upstream, because in general the ports
team do not add features

Luca Di Gregorio  wrote:

> I would like to set a point to point interface encapsulating packets via
> UDP.
> 
> It would be like a point to point wireguard but:
>  - without authentication (I can set permissions in PF on source ip)
>  - without encryption (content is already encrypted by source application)
> 
> I can't use GIF or GRE interfaces because I'm behind NAT with only TCP/UDP
> capabilities.
> 
> With linux it's possible with fou-gue interfaces, but I see that in OpenBSD
> fou is not implemented.
> 
> So, I installed socat with pkg_add and tried to do like this:
> http://www.dest-unreach.org/socat/doc/socat-tun.html
> 
> Anyway, I see this:
> # socat UDP:1.2.3.4:11443 TUN:192.168.255.2/24,up
> 2023/11/11 14:11:27 socat[4504] E unknown device/address "TUN"
> 
> Do you think it's possible to add TUN/TAP support in socat?

Re: [NEW] nitrocli

[Theo de Raadt]

+Beware this may allow the user unintended access to other hardware
+associated to the same usb(4) controller, so do this with extreme
+caution.

Can you explain what extreme caution means?

Re: [new] wayland/swaylock & wayland/swayidle

[Theo de Raadt]

Stuart Henderson  wrote:

> On 2023/11/09 11:38, Landry Breuil wrote:
> > The wordexp() use is awkward so i've replaced it by an ugly handrolled
> > lookup for configs in:
> > - $HOME/.sway{idle,lock}/config
> > - $XDG_CONFIG_HOME/sway{idle,lock}/config
> > - $HOME/.config/sway{idle,lock}/config if $XDG_CONFIG_HOME is unset
> > - and fallback to /etc/sway{lock,idle}/config
> > 
> > the wordexp() use for paths/image locations was also super awkward, but
> > with image=/usr/local/share/backgrounds/xfce/xfce-blue.jpg
> > in ~/.config/swaylock/config swaylock correctly loads the background
> > image, so just use full paths... or rely on $PATH for swayidle commands.
> 
> Obviously we don't want full wordexp but it would be nice if we had
> _something_ better and easy to use in place of the various ad-hoc
> wordexp alternatives that are in-tree (at least 10 ports already, plus
> these two, and as it seems popular with some of these wayland-related
> ports maybe we'll see more from there).
> 
> For some existing ports we patch to use glob() instead (though this
> can break documented use of the software e.g. $VAR, and is totally
> unusable for what swaylock/swayidle try to do), for others hand-
> rolled alternatives of varying quality (this one for example has
> unchecked malloc).
> 
> Most programs really just want ~ and $VARIABLE expansion (though
> of course they don't bother to set WRDE_NOCMD...)

I think the point is these pieces of code must always be written
narrowly to do just what they need to -- and nothing extra -- except always
that little bit of extra starts to be depended upon, and soon you have full
return to shell equivelancy

it's just plain awesome /sarc

"they" will continue to call system() -- oh i mean wordexp() -- because
they don't realize it is the same thing

they, n.
the children writing wayland from scratch hoping to introduce all the old
types of holes from the 90's.

Re: devel/boost syscall(2) removal

[Theo de Raadt]

On amd64, this makes no sense because we don't use stack protector.
It is retguard.   So something smells, it is like their handwritten
context switcher wasn't handling the full context before.  But that
might only matter if it unrolls via two seperate methods, or if a
new function above has become protected which was not protected before.
The description in the upstream work is pretty lacking.

Re: Gnome is dropping X11

[Theo de Raadt]

Chris Narkiewicz  wrote:

> TL;DR, the writing is on the wall


The writing has been on the wall a very long time that some people believe
their role in the ecosystem is to reduce software choice and push everyone
into vertical software monocultures.

Re: exim

[Theo de Raadt]

Renaud Allard  wrote:

> On 30/09/2023 16:32, Theo de Raadt wrote:
> > I'll try to summarize my point.
> > 
> > When less-secure AND more-secure pieces of software exist in the
> > the same role/service area, I think it is valid for developers who
> > care about security of their userbase to *DEMOTE* the less-secure
> > variations.
> > 
> > This kind of "hide the garbage" policy needs to exist somewhere
> > in the greater community, otherwise we have a situation where
> > software use is decided by "oh look, it is pretty".
> > 
> 
> You are the captain of this boat. I think if there are bad fishes, you 
> will take the right decision.

I don't make any decisions in ports, I can only make comments.

> After some discussion in the exim IRC channel, I am not sure there will 
> be fixes for everything soon. Given that one of the issues is in libspf2 
> and there have been no updates in this project since 2021. Maybe we 
> should discard libspf2 too then, which means also milter-greylist.
> Maybe it's time for a good cleanup.

Well, contrast that with the 4 layers of defence added inside ssh-agent for
dlopen being a broken interface.

You do what you do

Re: exim

[Theo de Raadt]

I'll try to summarize my point.

When less-secure AND more-secure pieces of software exist in the
the same role/service area, I think it is valid for developers who
care about security of their userbase to *DEMOTE* the less-secure
variations.

This kind of "hide the garbage" policy needs to exist somewhere
in the greater community, otherwise we have a situation where
software use is decided by "oh look, it is pretty".

Re: exim

[Theo de Raadt]

Right, it is not the first time.

Will it be the last time?

Doubtful.

If it won't be the last time, will the next time be just as bad?

For sure, because there is no security architecture in it.

Re: exim

[Theo de Raadt]

po...@phosphorus.com.br wrote:

> Unfortunately I like/use exim for years - pretty simple config file syntax.

Yes, you like unsafe software.

> https://seclists.org/oss-sec/2023/q3/254
> 
> So... I suppose those fixes were shared also with Exim's OpenBSD manteiners?

Wow.  Are you not listening?  They didn't fix anything.

Re: exim

[Theo de Raadt]

Stuart Henderson  wrote:

> With OpenBSD release fast approaching and considering the lack of solid
> information about the vulnerabilities, I think we should probably mark
> mail/exim BROKEN for now.

That's almost too kind.

> And also consider whether we want to keep this in ports at all...
> The response to this was much weaker than I'd expect from maintainers
> of software like this (note that it is a huge setuid root binary so
> it'd really be nice if they were a bit more active on that front)

Lacking any elements of privsep design.  In this regard, it is a very
strange piece of software.

sendmail was so terrible decades ago, that qmail showed up as
privsep-based-upon-file-moves.  That was privsep program #2.  Then
postfix, called vmailer at the time, showed up with privsep via other
forms of object movement, which is privsep program #3.  (openssh then
showed up as privsep program #4.  In my version of history, privsep
program #1 is the BSD auth subsystem, which is a piece of libc executing
gid-hidden setuid/setgid-if-needed service programs with their own
address spaces).  Many years later, sendmail even grew some aspects of
privsep. But exim?  No..  it's a newer piece of software using
old design rules.

It's a bad piece of software to expose users to, via the ports/packages.
Perhaps right after the ides of March next year, we should just move exim
into base.

Re: HEADS-UP: Slowing down for release, testing

[Theo de Raadt]

Thank you for locking ports.

To help prepare for this, I am now locking base + X ABI.

Re: enable -fstack-clash-protection in llvm ports

[Theo de Raadt]

Mark Kettenis  wrote:

> > From: Theo de Raadt 
> > Date: Thu, 14 Sep 2023 01:02:14 -0600 (MDT)
> > 
> > I do not think this should be enabled.
> > Our stacks work differently.
> > We don't put shit near the bottom of the main stack, because we
> > reserve the space.
> > For pthread stacks, we allocate them randomly also so you cannot
> > determistically trash a specific object.
> > This change also make very small stacks (meaning pthreads) potentially
> > reach beyond the bottom in a weird new way.
> > We simply don't need to cpu and pte's for this.
> 
> But if the stack space is used we'll have to spend the CPU time to
> fault the pages in and allocate the PTEs anyway.  Only stupid code
> allocates large amounts of stack space and doesn't use it!

That is not correct.

Sometimes it prefetches a page which you will use.
Sometimes it prefetches a page you won't use.
Quite often you don't use it.  Then the page has to eventually expire.
A PTE is also loaded.

It's a waste of time there are no pages to clash against.  We do not have
known objects to collide against.  We have address space randomization.
We don't have some "limited" form of it which puts other objects in those
locations.

Re: enable -fstack-clash-protection in llvm ports

[Theo de Raadt]

I do not think this should be enabled.
Our stacks work differently.
We don't put shit near the bottom of the main stack, because we
reserve the space.
For pthread stacks, we allocate them randomly also so you cannot
determistically trash a specific object.
This change also make very small stacks (meaning pthreads) potentially
reach beyond the bottom in a weird new way.
We simply don't need to cpu and pte's for this.

Re: Firefox toLocaleString displays wrong time on OpenBSD

[Theo de Raadt]

If you use unveil() without pledge(), you do not get the
special-case-file-exposures-for-libc behaviours that pledge() brings.

You are then responsible for all path exposure.

Morgan Aldridge  wrote:

> On Mon, Aug 7, 2023 at 3:57 AM Landry Breuil  wrote:
> 
> > Le Sat, Aug 05, 2023 at 07:41:12PM -0400, George Koehler a écrit :
> > > On Sat, 5 Aug 2023 08:49:25 +0200
> > > Landry Breuil  wrote:
> > >
> > > > I'm not sure i'll be able to look into it, but i'd rather *not*
> > document
> > > > 'workarounds' for issues until we're sure the issue isnt fixable. Maybe
> > > > it's pledge/unveil related, maybe not. Using ktrace to figure out which
> > > > files the browser tries to access when handling date-related functions
> > > > might help... and if it's not an issue happening only on OpenBSD, then
> > > > dealing with upstream is the way to go.
> > >
> > > I used ktrace.  It's unveil.  The fix is to add "/etc/localtime r"
> > > to /etc/firefox/unveil.content
> >
> > many thanks george for the time spend of this and this detailed
> > analysis. Definitely ok for me to add `/etc/localtime r` to
> > /etc/firefox/unveil.content, if it doesnt need to unveil the full
> > usr/share/zoneinfo subdir thats even simpler.
> >
> 
> Replicating George's test with the firefox port's default (unfixed)
> /etc/firefox/unveil.content. I used my Xsunaba utility just to simplify
> testing firefox as a fresh user, plus my own date_test.html (attached)
> which calls the `new Date().toString()`,
> `Intl.DateTimeFormat().resolvedOptions().timeZone`, and `new
> Date().toLocaleString()` JavaScript methods:
> 
> $ Xsunaba ktrace -di -f /home/xsunaba/firefox-stable-default-ktrace.out
> firefox /home/xsunaba/Downloads/date_test.html
> 
> 27628 is a content process that has called unveil and pledge:
> 
> $ doas -u xsunaba kdump -HT -f
> /home/xsunaba/firefox-stable-default-ktrace.out | grep 27628\\/ | less
> 
> libc still is able to successfully open /etc/localtime first:
> 
>  27628/276891  firefox  1692576139.506386 CALL
>  open(0xe92e849aac8,0)
>  27628/276891  firefox  1692576139.506392 NAMI  "/etc/localtime"
>  27628/276891  firefox  1692576139.506411 RET   open 41/0x29
> 
> Then the content process cannot call realpath() on /etc/localtime as
> unveil(2) hides it:
> 
>  27628/276891  firefox  1692576139.522045 CALL
>  __realpath(0xe92d022a315,0x774762945ea0)
>  27628/276891  firefox  1692576139.522048 NAMI  "/etc/localtime"
>  27628/276891  firefox  1692576139.522059 RET   __realpath -1 errno 2 No
> such file or directory
> 
> It also fails to access /usr/share/zoneinfo/* due to being hidden by
> unveil(2):
> 
>  27628/276891  firefox  1692576139.522089 CALL
>  open(0xe92cffe36a6,0x3)
>  27628/276891  firefox  1692576139.522094 NAMI  "/usr/share/zoneinfo/"
>  27628/276891  firefox  1692576139.522103 RET   open -1 errno 2 No such
> file or directory
> 
> The firefox JS console outputs the following inconsistent date/time/zone:
> 
>  Sun Aug 20 2023 18:02:19 GMT-0600 (GMT-06:00)
>  EST
>  8/20/2023, 7:02:19 PM
> 
> * * *
> 
> After adding '/etc/localtime r' to /etc/firefox/unveil.content:
> 
> $ Xsunaba ktrace -di -f
> /home/xsunaba/firefox-stable-unveil_localtime-ktrace.out firefox
> /home/xsunaba/Downloads/date_test.html
> 
> 61062 is a content process that has called unveil and pledge:
> 
> $ doas -u xsunaba kdump -HT -f
> /home/xsunaba/firefox-stable-unveil_localtime-ktrace.out | grep 61062\\/ |
> less
> 
> libc is still able to successfully /etc/localtime first:
> 
>  61062/172260  firefox  1692578044.321975 CALL
>  open(0x8df50322ac8,0)
>  61062/172260  firefox  1692578044.321982 NAMI  "/etc/localtime"
>  61062/172260  firefox  1692578044.321999 RET   open 41/0x2
> 
> Then the content process can call realpath() on /etc/localtime as unveil(2)
> is no longer hiding it:
> 
>  61062/172260  firefox  1692578044.333193 CALL
>  __realpath(0x8e03868b315,0x77b1cc5407f0)
>  61062/172260  firefox  1692578044.333199 NAMI  "/etc/localtime"
>  61062/172260  firefox  1692578044.333210 NAMI
>  "/usr/share/zoneinfo/America/New_York"
>  61062/172260  firefox  1692578044.333214 RET   __realpath
> 
> I no longer see an attempt nor error to open /usr/share/zoneinfo/.
> 
> The firefox JS console outputs the following correct date/time/zone:
> 
>  Sun Aug 20 2023 20:34:04 GMT-0400 (Eastern Daylight Time)
>  America/New_York
>  8/20/2023, 8:34:04 PM
> 
> * * *
> 
> In conclusion this does seem to resolve all the cases that I had identified
> and since my second test doesn't seem to even attempt to open
> /usr/share/zoneinfo, I believe that just unveiling /etc/localtime is
> sufficient.
> 
> I see that George has already committed unveiling /etc/localtime for
> firefox content processes in the port, so many, _many_ thanks to George and
> Landry!
> 
> Morgan

Re: lang/ocaml and IBT WAS: amd64: IBT bulk build breakage

[Theo de Raadt]

> yes, -current has it enabled now. But in order to catch those problems
> you'll need a CPU that supports it, too ... on amd64 that would be
> Tiger Lake(?) and later. I think.

it is any "laptop / desktop" cpu from gen11 onwards, which is most things
in the last 3 years

Re: arm64 BTI support for mpg123

[Theo de Raadt]

Mark Kettenis  wrote:

> I'm not sure to what extent this makes IBT less effective.  Can the
> retpolines be used as gadgets to bypass IBT?  Should we stop enabling
> retpolines by default?
> 
> What *is* obvious is that retpolines are incompatible wuth shadow
> stacks.  Is there an alternative that doesn't replace the indirect
> branch with a return instruction?

It is clear however that both AMD and Intel have seperate (yet compatible)
strategies to encourage you to buy newer chips.

Re: arm64 BTI support for mpg123

[Theo de Raadt]

Christian Weisgerber  wrote:

> Mark Kettenis:
> 
> > This port has some infrastructure to use an optimized function that
> > uses a function pointer.  Not sure why for arm64 it actually uses that
> > infrastructure, since the only alternative is the generic C
> > implementation.  But adding a BTI instruction is the easiest fix.
> 
> ok naddy@
> 
> The question is whether there are any others hiding in there.  How
> did you find this in the first place?  It broke on the M2?
> 
> Because amd64 should suffer from the same problem:
> 
> fr->cpu_opts.the_dct36 = dct36_avx;
> ...
> fr->cpu_opts.the_dct36 = dct36_x86_64;
> 
> dct36_avx and dct36_x86_64 are assembly routines that lack the
> endbr64 landing pad.  And yet, on my IBT-enabled amd64 laptop,
> mpg123 plays just fine with both the avx and x86_64 decoders.

Maybe it requires specific files to go via those code paths?

Ayways, how will we know all the locations?  I think we will eventually
know based upon user reports.

It feels like there is a compilers or linker option missing to proactively
identify these problems.  Please don't bring up LTO.

Re: devel/zeal won't launch under amd64/6.3-stable due to QSharedMemory() error

[Theo de Raadt]

Morgan Aldridge  wrote:

> Since Ian mentioned devel/zeal for a USE_NOBTCFI update in -current, I
> figured I'd give it a try. Unfortunately, under OpenBSD
> amd64/6.3-stable, I get the following error when attempting to execute
> it:
> 
> QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-username'
> zeal.core.applicationsingleton: Singleton ID:
> _nGQfwnfPpFrP7E8fa8MHCJw0S0KmYxfPsN0l86qrnY
> zeal.core.applicationsingleton: Cannot attach to the shared memory
> segment: "QSharedMemory::handle:: UNIX key file doesn't exist"
> zeal.core.applicationsingleton: Cannot connect to the local service:
> "QLocalSocket::connectToServer: Invalid name"
> 
> There don't seem to be similar issues reported upstream. Can anyone
> else confirm this issue or provide any insight before I report?
> 
> I use an fvwm-based WM, not a full desktop environment, if there's
> something for Qt apps that would need initialization in my .xsession
> to initialize shared memory.

BIT/BTI failures result in SIGILL, generally visible in the shell.
If you are not sure, you use ktrace -di + kdump, to see if there is
a SIGILL.  If there is no SIGILL, it is unrelated to USE_NOBTCFI.

Re: lang/* IBT breakage

[Theo de Raadt]

Christian Weisgerber  wrote:

> (Let's call it "IBT" because this is on amd64.)
> 
> The remaining build failures in lang/* are:
> 
> lang/crystal
> lang/gprolog
> lang/ldc
> lang/ocaml
> lang/racket-minimal
> 
> Is anybody doing full package bulk builds on hardware that enforces
> IBT?  I could give it a try, but I'm not sure the Thinkpad T14 is
> up to it.

It has to be done on laptops for now, because the feature showed up about
3 years ago.  Server generations with IBT are only showing up now, brand
new.

Re: lang/* BTI breakage

[Theo de Raadt]

Brian Callahan  wrote:

> On 7/10/2023 9:33 AM, Theo de Raadt wrote:
> > Brian Callahan  wrote:
> > 
> >> Pushed a nobtcfi fix for DMD.
> > 
> > nobtcfi should never be considered a "fix".  It is a workaround we make
> > available to allow laggard software to continue running -- nothing more.
> > 
> > 
> > 
> 
> Agreed. And I made the same clear to them.


Let me explain this in a different way, which may help conversations with
upstreams.


In OpenBSD, we are experimenting with mandatory BTI (arm64) /IBT (x86).

In Linux, they have started a 20 year experiment with per-page BTI, and
elective IBT. 

On arm64, you can do BTI on a per-page basis.  One code page may have
BTI, and another page won't.  That allows a crappy shared library
without BTI to "work' inside a binary that has BTI.  One .so will be
labelled as "I am not ready for BTI enforcement", another .so will be
labelled as "OK to enforce BTI here". Obviously an attacker will use JOP
methodology inside the crappy library.  Such a scheme does not lead to
eventually having BTI everywhere, and JOP will remain alive.

On x86, you cannot do it perform it page-by page.  So if anything in the
process's address cannot accept BTI enforcement, you won't get BTI in that
process.  JOP will remain alive.


The mandatory behaviour will arrive in Linux eventually because openbsd
developers have pushed upstream library and application authors.

Eventually (adv)
10 years or more into the future

Re: lang/* BTI breakage

[Theo de Raadt]

Brian Callahan  wrote:

> Pushed a nobtcfi fix for DMD.

nobtcfi should never be considered a "fix".  It is a workaround we make
available to allow laggard software to continue running -- nothing more.

Re: lang/* BTI breakage

[Theo de Raadt]

Christian Weisgerber  wrote:

> The remaining build failures are:
> 
> lang/crystal
> lang/dmd
> lang/gprolog
> lang/ldc
> lang/mono
> lang/ocaml
> lang/racket-minimal

Have the upstreams been told that IBT/BTI instructions are going to
be required in all software (sometime in the future).

Re: lang/gambit build parallel

[Theo de Raadt]

at g2k23 we talked about this issue for a bit. The make(1) manual
page can be confusing because it says:

 -j max_processes
 Specify the maximum number of processes that make may have
 running at any one time.

Nope, that's wrong.  It can create vast number of processes including
their sub-processes upon pipelines, so it is very difficult to judge
what it will do.

We could fix it (with an ugly hack you don't want to hear about), but
then -j will probably end up way underutilizing cpus (because it would
count even your "sh" processes sitting idle), and then people would
probably start running -j 100 on 16 cpu machines and be right back
at the same underload vs overload situation.

> Peter Hessler:
> 
> > This package takes quite a while to build, so I marked it as parallel to
> > use more CPUs.
> 
> This appears inefficient.  Right now, I have a gambit build sitting
> here, taking up five CPU slots...
> 
> 5*lang/gambit(build) [29274] 26% frozen for 22mn
> 
> ... but running only two cc(1) processes.
> 
> 59060 p1  I+p  0:00.02   |   `-- /usr/bin/make build
> 97813 p1  I+p  0:00.00   | `-- /bin/sh -ec lock=gambit-4.9.4p0;  
> export
> 74087 p1  I+p  0:00.01   |   `-- /usr/bin/make _internal-build
>  3321 p1  I+p  0:00.02   | `-- /usr/bin/make do-build
> 54023 p1  I+p  0:00.00   |   `-- /bin/sh -ec ulimit -s 12288 && 
> cd 
> 72554 p1  I+p  0:00.01   | `-- /usr/bin/make mkdir_p=mkdir -p 
> -
> 21475 p1  I+p  0:00.01   |   `-- /bin/sh -ec for subdir in 
> incl
> 71313 p1  I+p  0:00.00   | `-- /bin/sh -ec for subdir in 
> in
> 19391 p1  I+p  0:00.05   |   `-- /usr/bin/make core
> 71280 p1  R+/10   26:59.87   | |-- /usr/bin/cc -B 
> /usr/obj/
>  4319 p1  R+/926:47.57   | `-- /usr/bin/cc -B 
> /usr/obj/
> 
> -- 
> Christian "naddy" Weisgerber  na...@mips.inka.de
> 

Re: lang/* BTI breakage

[Theo de Raadt]

Marc Espie  wrote:

> On Mon, Jul 03, 2023 at 12:11:09AM +0200, Christian Weisgerber wrote:
> > lang/ocaml
> 
> > 
> > I guess for ocaml the big hammer would be to disable native code
> > compilation altogether and fall back to bytecode.
> 
> How far behind are we on ocaml code releases ?
> 
> Considering the people writing the language, I'm a bit surprised
> bti isn't on their list to support natively.

In a few places I am seeing a subculture of

   we have a 'safe language', so our code-generation does not
   need to follow the safest practices.

Re: rclone

[Theo de Raadt]

amd64 snapshot contains a different IBT diff which appears to fix go.

Solène Rapenne  wrote:

> On Sun, 2023-07-02 at 18:36 -0500, Edward Ahlsen-Girard wrote:
> > Has it been removed from packages? rclone-browser is still a package,
> > but it can't install. I've tried number mirrors.
> > 
> 
> lang/go is broken on snapshots due to a general work on IBT
> 
> See https://marc.info/?t=16871853121&r=1&w=2
> 
> as a result, go programs can't be built at the moment
> 

Re: lang/* BTI breakage - lang/sbcl

[Theo de Raadt]

Sebastien Marie  wrote:

> sbcl compilation works by generating native code inside live managed memory, 
> and 
> permits to save the whole memory image to a file.
> 
> it is why the binary currently also needs WX and RX memory (I intent to work 
> a 
> bit on it if possible).
> 
> When generating an executable, it is copying /usr/local/bin/sbcl binary as 
> base, 
> and append the (optionally compressed) memory image to the file, to create a 
> standalone executable.
> 
> When the output file is executed, it is reading its own image, loads it in 
> memory, and use an entrypoint for loaded code.
> 
> So the generated file has all the flags it needs to run (because copied from 
> /usr/local/bin/sbcl binary).

It is ridiculous.

Even emacs stopped doing that.

Re: node package crash on latest snapshot (IBT)

[Theo de Raadt]

We know.  Wait a little bit longer.


Rémi Bougard  wrote:

> Hi,
> 
> On the latest snapshot node (node-18.16.1v0) crash immediately after starting.
> After recompiling it from /usr/ports with USE_NOBTCFI=Yes everything works as
> before.
> 
> I can provide further data if needed.
> 
> All the best,
> Rémi
> 
> 
> -- 
> Rémi Bougard
> 

Re: error when compiling lang/go

[Theo de Raadt]

Theo Buehler  wrote:

> On Mon, Jun 19, 2023 at 08:50:44AM -0600, Theo de Raadt wrote:
> > If you disable XSAVE_XSAVES, then userland IBT enforcement is also disabled.
> > 
> > XSAVES is required to manage the IBT enforcement mechanism's internal state
> > over a context switch.
> > 
> > All machines with IBT have XSAVES.
> 
> The thing is that this breaks it on machines without IBT>


Ah.

Well that does help a little -- it means the XSAVES state saving code is
losing some other context in some situation.

Re: error when compiling lang/go

[Theo de Raadt]

If you disable XSAVE_XSAVES, then userland IBT enforcement is also disabled.

XSAVES is required to manage the IBT enforcement mechanism's internal state
over a context switch.

All machines with IBT have XSAVES.

If I understand right, there are other ways of managing the state, but
this is the one that is recomended, and in use, and it appears there is
a bug.

Theo Buehler  wrote:

> On Mon, Jun 19, 2023 at 04:31:19PM +0200, Solene Rapenne wrote:
> > Hi, I can't get lang/go to compile on my system, which is a Xen VM.
> > 
> > I can compile almost anything, including qt or webkitgtk, but lang/go
> > is failing with various errors each time. I'm not sure it's a XEN bug
> > though, maybe an issue with recent IBT?
> 
> Yes, it's the IBT diff in snaps breaking the bootstrapping process.
> An older go binary or one compiled on a another machine where it compiles
> works quite well (but not perfectly) with that diff.
> 
> > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,AMCR8,ABM,SSE4A,MASSE,3DNOWP,DBKP,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> 
> As far as I know machines with XSAVES are affected as long as they don't
> take the XSAVES disabling path in the ibt diff. If I force my machines
> with XSAVES to do the eax &= ~XSAVE_XSAVES thing then go compiles and
> works. That's as far as I got with debugging.
> 
> I have no idea if this is a bug in the kernel diff or in lang/go or
> both.
> 

Re: lang/ghc and IBT?

[Theo de Raadt]

Greg Steuck  wrote:

> Matthias Kilian  writes:
> 
> > still slacking around like hell, but I guess we need a new bootstrap
> > for lang/ghc. If so, I'll try to enable USE_NOBTCFI, build a new
> > bootstrap with it, and then use that for building the regular ghc
> > package.
> 
> Yeah, sounds about right. I have no illusions about GHC ever supporting
> IBT considering their compilation model.

Why not?

Intel and ARM with IBT/BTI have confused the public. Branch Target generally
means "function entry point".

A compiler just needs to put IBT instructions at every calculated branch target,
ie. the start of every function that is reached by "calculating" the address.
Popping the address off the stack, with a RET, is not considered "calculating".

If they end up putting the instructions at non-calculated branch targets, that's
OK too.

A compiler could generate code that has endbr64 as every 2nd instruction, and
it would still work.  It would be non-optimal, and silly.  But it would work.

My point is there is nothing wrong with a compiler that inperfectly places
a few endbr64 that are not absolutely required.


So I think GHC could do easily adapt to a IBT world.

Re: USE_NOBTCFI for ports

[Theo de Raadt]

That looks right to me.

Should there perhaps be a vague mention here that the compiler defaults
have been changed, but if in doubt mention the name of the options that
cause the compiler to do so?

The compiler options are different between arm64 and amd64.  Because the
teams didn't talk and convinced llvm do do both?!?!.  Well, the arm64
mechanism is slightly more powerful and expressive, but this split is a
cognitive load the development community did not need.  It will retard
deployment pace.

This is the table?

   enable BTCFI (our default)   disable BTICFI

amd64  -fcf-protection=branch   -fcf-protection=none
arm64  -mbranch-protection=bti  -mbranch-protection=none

I figure the folk who are going to tweak the link-time flag to say "this
does not work", would also like to play with these options to check the
issue they see isn't related to something else.

Re: [new] sysutils/lsblk

[Theo de Raadt]

Stuart Henderson  wrote:

> On 2023/06/11 12:56, Benjamin Stürz wrote:
> > On 11.06.23 09:34, Stuart Henderson wrote:
> > > On 2023/06/10 23:40, Benjamin Stürz wrote:
> > > > Hi,
> > > > 
> > > > what should I do next?
> > > > I have at least 2 OKs now, but I don't have any commit rights.
> > > 
> > > I only count 1 developer ok so far (op@).
> > 
> > Sorry, I thought
> > >  Build and tests OK on current/amd64 in a VM on VirtualBox.
> > by Laurent Cheylus  also counted as an ok.
> 
> Only developer OKs count for that.

In OpenBSD, and "ok" is a formal statement made in a commit message to
indicate both review & shared responsibility.  The latter means, if an
an error is introduced, such persons are equally responsible to handle
the in-tree details such as potentially backing it out, further fixing
etc.  In addition, it also causes the commit log to track people who are
familiar with a particular subsystem.  In the future, this can suggest who
should see changes there, without throwing diffs into void and hoping for
an answer.
 

Re: Programs failing with "Illegal instruction"

[Theo de Raadt]

For some of those, I think you have old packages.

The versions were not increased during this test.

Run pkg_add -u -Dinstalled

Re: Programs failing with "Illegal instruction"

[Theo de Raadt]

There is a test being run in snapshots.

We are enumerating the programs that fail.

Thank you for participating.

sprits killshot  wrote:

> I'm running OpenBSD GENERIC.MP#1223 amd64 on a framework laptop.
> 
> I upgraded to the latest snapshot and updated packages. Then, a bunch of
> programs failed and exited with "Illegal instruction."  Programs include
> tint2, messagebus, colorls, xclip, firefox, and probably more.  All these
> programs exit with the same "Illegal instruction" error.
> 
> Do I need to wait for snapshots to catch up with the latest port snaps or
> is there a deeper issue to address?
> 
> Isaac
> 
> Dmesg below.
> 
> OpenBSD 7.3-current (GENERIC.MP) #1221: Wed Jun  7 00:12:50 MDT 2023
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 34006142976 (32430MB)
> avail mem = 32955842560 (31429MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x3f085000 (54 entries)
> bios0: vendor INSYDE Corp. version "03.05" date 08/23/2022
> bios0: Framework Laptop (12th Gen Intel Core)
> efi0 at bios0: UEFI 2.8
> efi0: INSYDE Corp. rev 0x305
> acpi0 at bios0: ACPI 6.3
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP UEFI SSDT SSDT SSDT SSDT SSDT SSDT SSDT TPM2
> SSDT LPIT WSMT SSDT SSDT DBGP DBG2 NHLT ECDT HPET APIC MCFG SSDT DMAR
> SSDT SSDT SSDT SSDT FPDT ASF! PHAT BGRT
> acpi0: wakeup devices PEG0(S4) PEGP(S4) PEGP(S4) PEGP(S4) XHCI(S4)
> XDCI(S4) HDAS(S4) CNVW(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4)
> RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpiec0 at acpi0
> acpihpet0 at acpi0: 1920 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: 12th Gen Intel(R) Core(TM) i5-1240P, 4390.59 MHz, 06-9a-03
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,WAITPKG,PKS,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> cpu0: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB
> 64b/line 10-way L2 cache, 12MB 64b/line 8-way L3 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 38MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.0.2.0.1.0.1, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: 12th Gen Intel(R) Core(TM) i5-1240P, 4390.59 MHz, 06-9a-03
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,PKS,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> cpu1: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB
> 64b/line 10-way L2 cache, 12MB 64b/line 8-way L3 cache
> cpu1: smt 1, core 0, package 0
> cpu2 at mainbus0: apid 8 (application processor)
> cpu2: 12th Gen Intel(R) Core(TM) i5-1240P, 4388.97 MHz, 06-9a-03
> cpu2: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,PKS,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> cpu2: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB
> 64b/line 10-way L2 cache, 12MB 64b/line 8-way L3 cache
> cpu2: smt 0, core 4, package 0
> cpu3 at mainbus0: apid 9 (application processor)
> cpu3: 12th Gen Intel(R) Core(TM) i5-1240P, 4390.66 MHz, 06-9a-03
> cpu3: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,PKS,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> cpu3: 48KB 64b/line 12-way D-c

Re: Question about net/curl and SFTP

[Theo de Raadt]

Vlad Meșco  wrote:

> On 7 June 2023 19:25:17 EEST, Allan Streib  wrote:
> >My goal is to copy from stdin to a remote system via sftp in a pipeline.
> >I thought curl would allow this with its "-T" argument by providing "-"
> >as the local filename to transfer, but the result was:
> >
> >curl: (1) Protocol "sftp" not supported or disabled in libcurl
> >
> >I tried to search the list archives for any discussion but found none.
> >Seems to have been this way for a long time. Is there an alternative?
> >
> >OpenBSD 7.2 GENERIC.MP#7 amd64
> >
> >curl 8.0.1 (x86_64-unknown-openbsd7.2) libcurl/8.0.1 LibreSSL/3.6.0 
> >zlib/1.2.12 nghttp2/1.49.0
> >Release-Date: 2023-03-20
> >Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt pop3 
> >pop3s rtsp smb smbs smtp smtps telnet tftp
> >Features: alt-svc AsynchDNS HSTS HTTP2 HTTPS-proxy IPv6 Largefile libz NTLM 
> >NTLM_WB SSL threadsafe UnixSockets
> >
> >Allan
> >
> 
> Curl is built without sftp or scp support; my guess is because "why would 
> you?" and "with libssh or libssh2?", but that doesn't change how it's 
> currently built.
> 
> You can do what I did: grab the ports tree, update net/curl/Makefile to 
> configure --with-libssh (and add libssh as a dependency), make package and 
> make install. 
> Package updates are annoying, but I've learnt to live with it.
> 
> I can share my diff if you're interested to build it yourself. I'm not near a 
> PC right now.

Oh, I see, privilege-seperation built into sfp + ssh client + other things it 
does
are strange, so instead link-all-the-libraries into one binary's address space,
especially great since will have to access the ssh keys, and there are no 
mitigations!

Once again, a privilege-seperation mitigation technology.

Next exercise: building ssh client support into the browsers!

Re: arm64 BTI for devel/gmp

[Theo de Raadt]

Mark Kettenis  wrote:

> So as far as I can tell, only arm64 has the -mmark-bti-property
> option.  On x86 there is a  include file that, when included,
> emits the "right" .note.gnu.property based on preprocessor macros that
> get set based on the compiler options.  As far as I can tell, this
>  include is an "Intel standard" that exists in all recent
> versions of clang, gcc and the Intel compiler.  The downside of this
> approach is that it requires modifications to every x86 assembly file.

I think I have a better way of explaining why it is pointless either way.

In the arm64 way, someone with 10 .S files will add -mmark-bti-property
to the Makefile, not read the actual .S files, and wait for a bug report
that says it doesn't work.

In the amd64 way, someone with 10 .S files will add cet.h to every .S files
but not actually read the actual .S files, and wait for a bug report
that says it doesn't work.

In our way, we'll change the kernel to assume all program is safe, and wait
for a bug report.  We've just skipped the first steps!

At which point someone will try to figure out the problem, work on a fix.
If no quick fix is possible, that program will be marked as shitty with a
linker flag, and the kernel will no longer enforce.  If the problem is in
a library, we can mark all the programs using that library.

Later passes can say "wait too many markers saying programs are shitty",
and the bugs can be fixed by ourselves or upstream.


We have followed this pattern since 2001 (W^X and wxneeded flagging),
and we understand how it works to clean the problems in applications.
On the other hand Linux has always done this the other way and done
effectively NOTHING to improve these types of problems, and always
ridden on our coattails.

yes I think their dumb mechanisms will show up in upstreams and it will
not help anyone.

Re: arm64 BTI for devel/gmp

[Theo de Raadt]

> The downside of this
> approach is that it requires modifications to every x86 assembly file.

What happens if I don't do that to an asm file included in the linux
plex client???

Re: arm64 BTI for devel/gmp

[Theo de Raadt]

+.if ${MACHINE_ARCH:Maarch64}
+CONFIGURE_ENV+= ASMFLAGS=-mmark-bti-property
+.endif

For some of these diffs, it might help to consider amd64 (and i386?) at
the same time.  Or, all architectures.  In theory this type of thing will
eventually show up on some other architectures.

The ELF tag doesn't hurt on a processor family which lacks the lower-level
capability.

When it comes to the compiler option, it is very unfortunate that arm64
uses different flags than the other architctures (I say other architectures,
meaning not just amd64 and i386, because based upon reading clang source,
they have written the -fcf-protection argument passing to be applicable to
other architectures as well)

Re: 7.3: speetest doesn't work

[Theo de Raadt]

Martin Schröder  wrote:

> Am So., 16. Apr. 2023 um 15:49 Uhr schrieb Stuart Henderson
> :
> > At this point I think you might be better served by dumping the
> > package list, uninstalling them all, and reinstalling with 022 umask.
> >
> > Borrowing the old instructions from the 5.5 time_t flag day release
> > notes, this also keeps the "auto installed" / "manually installed"
> > markers (so that pkg_delete -a still behaves how you want):
> >
> > pkg_info -mq >/root/pkg_list_manual
> > pkg_info -q >/root/pkg_list_full
> > pkg_delete -X /var/db/pkg/*-firmware-[0-9]*
> > pkg_add -z -l /root/pkg_list_manual
> > pkg_add -za -l /root/pkg_list_full

OK, that's ridiculous.


This got to be a bug.  I cannot see any situation where you want packages
to be installed in that way.  What is the justification?

Re: notify-send: silence vfprintf null

[Theo de Raadt]

> I question our wisdom of having printf() log instances of %s NULL,
> but then declaring that we can't fix the offenders and need to
> resort to intercepting arguments passed to printf().

Indeed, let's step back here.

The logging has cleaned numerous bugs in our base tree.

But ports, that's another matter.

I suspect a bunch of upstreams have used information from openbsd builds
on their own, or based upon feedback from openbsd ports builders, and that
this has resulted in repair numerous NULL conditions.

But not all.  There will be communities who don't care.

It remains an odd situation, I think a printf of %s NULL is permitted to
access and SIGSEGV, and I think one unix operating system in the past did,
but noone nowadays does. (Was it Ultrix?)

Anyways -- maybe we have achieved everything we wanted to achieve (I mean,
fixing base to be accurate), and it is time to disable this logging.

Also, maybe we can re-enable it for a couple months every few years,
(but not in release) to encourage fresh developer consideration of the issue?

Re: notify-send: silence vfprintf null

[Theo de Raadt]

Christian Weisgerber  wrote:

> Landry Breuil:
> 
> > I've had a quick look and got a bit lost in the maze, but my
> > understanding is that via various aliases/defines, the function called
> > is g_logv in
> > https://gitlab.gnome.org/GNOME/glib/-/blob/main/glib/gmessages.c#L1291 -
> > so the code should iterate on args and replace the NULL ones by '(null)' ?
> 
> You can't tell by looking at an argument whether it is a a pointer
> or a long (or a sign-extended int on most archs).  You need to
> examine the format string.
> 
> Also, how do you replace an element in a va_list?  I don't think
> you can.  I don't think you can construct a new va_list element by
> element either.

Whoa, no way -- you cannot touch them.  The pointers could be to objects
that the caller uses for an additional purpose.  There is no specification
which says they have to be unique to this call.

Re: On the remaining syscall(2) or __syscall(2) use in ports

[Theo de Raadt]

Stuart Henderson  wrote:

> > I've looked into fexecve() numerous times and I just cannot for the life
> > of me see how to avoid it becoming a component of attack methodology.
> > 
> > The people who invented must be completely unaware of the dangerous
> > tooling this brings to the table.
> > 
> > OpenBSD will never have it.
> 
> Surely they must be aware... In particular in an OS with memfd_create
> it seems particularly potent.

Correct.  It is a pivot mechanism.

Re: On the remaining syscall(2) or __syscall(2) use in ports

[Theo de Raadt]

Christian Weisgerber  wrote:

e> Theo Buehler:
> 
> > devel/p5-IO-AIO
> >   (?) strange mix of perl + m4
> 
> The m4 part are just autoconf macros that are included by the
> top-level configure.ac.  I looked over this and the syscalls are
> Linux-specific and behind #ifdef guards.  On OpenBSD this is
> already short-ciruited to syscall(-1, ...).  There is also a
> configure check for the presence of syscall() and
> 
> #if HAVE_SYSCALL
> #include 
> #else
> # define syscall(nr,...) (errno = ENOSYS, -1)
> #endif

Amusing.

Re: On the remaining syscall(2) or __syscall(2) use in ports

[Theo de Raadt]

Stuart Henderson  wrote:

> This port is broken; doesn't work with our Perl version. 4.79 needs
> a patch to avoid segfaults because we don't have fexecve() and with
> that fixed still doesn't work (same errors as 4.75).

I've looked into fexecve() numerous times and I just cannot for the life
of me see how to avoid it becoming a component of attack methodology.

The people who invented must be completely unaware of the dangerous
tooling this brings to the table.

OpenBSD will never have it.

Re: multimedia/libv4l: neuter syscall(2)

[Theo de Raadt]

The question remains: why the upstream doing that.

Sometihng is missing here, and it may not just be mechanical.


Klemens Nanni  wrote:

> Still waiting for pkg_add and then my build to finish, but the idea is
> 
> - make the existing maros NO-OPs, align with spaces to make it obvious
> - remove includes/defines to break any left-over syscalls
> 
> I didn't see a knob to fix this properly.
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/multimedia/libv4l/Makefile,v
> retrieving revision 1.29
> diff -u -p -r1.29 Makefile
> --- Makefile  2 Sep 2022 09:42:27 -   1.29
> +++ Makefile  19 Feb 2023 18:19:57 -
> @@ -3,7 +3,7 @@ COMMENT = libv4l userspace library
>  VERSION =1.20.0
>  DISTNAME =   v4l-utils-${VERSION}
>  PKGNAME =libv4l-${VERSION}
> -REVISION =   2
> +REVISION =   3
>  
>  SHARED_LIBS +=   v4l10.0 # 0.0
>  SHARED_LIBS +=   v4l20.0 # 0.0
> Index: patches/patch-lib_libv4l-mplane_libv4l-mplane_c
> ===
> RCS file: patches/patch-lib_libv4l-mplane_libv4l-mplane_c
> diff -N patches/patch-lib_libv4l-mplane_libv4l-mplane_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-lib_libv4l-mplane_libv4l-mplane_c   19 Feb 2023 18:37:13 
> -
> @@ -0,0 +1,20 @@
> +Stub out SYS_* macros to use syscalls directly not syscall(2)
> +
> +Index: lib/libv4l-mplane/libv4l-mplane.c
> +--- lib/libv4l-mplane/libv4l-mplane.c.orig
>  lib/libv4l-mplane/libv4l-mplane.c
> +@@ -36,11 +36,11 @@
> + #include "libv4l-plugin.h"
> + 
> + #define SYS_IOCTL(fd, cmd, arg) \
> +-syscall(SYS_ioctl, (int)(fd), (unsigned long)(cmd), (void *)(arg))
> ++ioctl(fd, cmd, arg)
> + #define SYS_READ(fd, buf, len) \
> +-syscall(SYS_read, (int)(fd), (void *)(buf), (size_t)(len));
> ++read(fd, buf, len)
> + #define SYS_WRITE(fd, buf, len) \
> +-syscall(SYS_write, (int)(fd), (const void *)(buf), (size_t)(len));
> ++write(fd, buf, len)
> + 
> + 
> + #if HAVE_VISIBILITY
> Index: patches/patch-lib_libv4l1_libv4l1_c
> ===
> RCS file: patches/patch-lib_libv4l1_libv4l1_c
> diff -N patches/patch-lib_libv4l1_libv4l1_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-lib_libv4l1_libv4l1_c   19 Feb 2023 18:37:13 -
> @@ -0,0 +1,14 @@
> +Use dup(2) not syscall(2)
> +
> +Index: lib/libv4l1/libv4l1.c
> +--- lib/libv4l1/libv4l1.c.orig
>  lib/libv4l1/libv4l1.c
> +@@ -472,7 +472,7 @@ int v4l1_dup(int fd)
> + int index = v4l1_get_index(fd);
> + 
> + if (index == -1)
> +-return syscall(SYS_dup, fd);
> ++return dup(fd);
> + 
> + devices[index].open_count++;
> + 
> Index: patches/patch-lib_libv4l2_libv4l2_c
> ===
> RCS file: patches/patch-lib_libv4l2_libv4l2_c
> diff -N patches/patch-lib_libv4l2_libv4l2_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-lib_libv4l2_libv4l2_c   19 Feb 2023 18:37:13 -
> @@ -0,0 +1,14 @@
> +Use dup(2) not syscall(2)
> +
> +Index: lib/libv4l2/libv4l2.c
> +--- lib/libv4l2/libv4l2.c.orig
>  lib/libv4l2/libv4l2.c
> +@@ -880,7 +880,7 @@ int v4l2_dup(int fd)
> + int index = v4l2_get_index(fd);
> + 
> + if (index == -1)
> +-return syscall(SYS_dup, fd);
> ++return dup(fd);
> + 
> + devices[index].open_count++;
> + 
> Index: patches/patch-lib_libv4lconvert_libv4lsyscall-priv_h
> ===
> RCS file: patches/patch-lib_libv4lconvert_libv4lsyscall-priv_h
> diff -N patches/patch-lib_libv4lconvert_libv4lsyscall-priv_h
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-lib_libv4lconvert_libv4lsyscall-priv_h  19 Feb 2023 
> 18:37:13 -
> @@ -0,0 +1,59 @@
> +Stub out SYS_* macros to use syscalls directly not syscall(2)
> +
> +Index: lib/libv4lconvert/libv4lsyscall-priv.h
> +--- lib/libv4lconvert/libv4lsyscall-priv.h.orig
>  lib/libv4lconvert/libv4lsyscall-priv.h
> +@@ -63,15 +63,6 @@
> + #define MMAP2_PAGE_SHIFT 0
> + #endif
> + 
> +-#if defined(__OpenBSD__)
> +-#include 
> +-#include 
> +-#include 
> +-#define _IOC_NR(cmd) ((cmd) & 0xFF)
> +-#define _IOC_TYPE(cmd) IOCGROUP(cmd)
> +-#define MMAP2_PAGE_SHIFT 0
> +-#endif
> +-
> + #undef SYS_OPEN
> + #undef SYS_CLOSE
> + #undef SYS_IOCTL
> +@@ -84,19 +75,19 @@
> + 
> + #ifdef SYS_openat
> + #define SYS_OPEN(file, oflag, mode) \
> +-syscall(SYS_openat, AT_FDCWD, (const char *)(file), (int)(oflag), 
> (mode_t)(mode))
> ++open(file, oflag, mode)
> + #else
> + #define SYS_OPEN(file, oflag, mode) \
> +-syscall(SYS_open, (const char *)(file), (int)(oflag), (mode_t)(mode))
> ++open(file, oflag, mode)
> + #endif
> + #define SYS_CLOSE(fd) \
> +-syscall

Re: lang/sbcl will not work with x-only

[Theo de Raadt]

Josh Elsasser  wrote:

> On Fri, Jan 27, 2023 at 05:02:33PM +0100, Christian Weisgerber wrote:
> > lang/sbcl will not work with x-only.
> > 
> > I took another look at the warnings about data directives in .text.
> > In runtime/x86-64-assem.S we have snippets like these:
> > 
> > GNAME(fun_end_breakpoint_trap):
> > TRAP
> > .byte   trap_FunEndBreakpoint
> > hlt # We should never return here.
> > 
> > GNAME(do_pending_interrupt):
> > TRAP
> > .byte   trap_PendingInterrupt
> > ret
> > 
> > GNAME(memory_fault_emulation_trap):
> > TRAP
> > .byte   trap_MemoryFaultEmulation
> > 
> > Where TRAP is defined to int3, and trap_* are consecutively numbered
> > constants.  The other half of this is sigtrap_handler() in
> > runtime/x86-64-arch.c, which reads the byte after the int3 instruction
> > 
> > trap = *(unsigned char *)OS_CONTEXT_PC(context);
> > 
> > and then dispatches accordingly.
> > 
> > ... And this brief analysis marks the end of my own involvement
> > with this port.
> 
> Unfortunately I don't have a new enough CPU to test xonly, so someone
> should probably mark it USE_NOEXECONLY
> 

It sounds like that could be fixed by removing that .byte, and creating
some other sort of fast-lookup method that looks up the PC it came from
to decide where it came from.  But that's a problem for upstream.  If
upstream ever wants to run on xonly systems.  Will xonly systems become
popular in the next 10 years?  I suspect they will...  people said W^X and
lots of other cheap security mitigations were unreasonable and would never
make it into other operating systems and what happened?

Re: www/seamonkey: xonly amd64 assembly fix

[Theo de Raadt]

So there is an approach which can be taken for these big chunks, which
I came up with yesterday.

Put them into .openbsd.mutable section.

At program startup they will be RW, so Immediately mprotect)
PROT_EXEC|PROT_READ, and if you feel like it use mimmutable() also,
which they would have been if started a different way.

Make sure the object is page aligned, or you'll cut yourself.

Re: lang/node - patch for xonly

[Theo de Raadt]

Theo Buehler  wrote:

> On Sat, Jan 21, 2023 at 05:36:17PM +0100, Volker Schlecht wrote:
> > Here's a patch that builds node without USE_NOEXECONLY and without those
> > warnings, producing a working binary on amd64 ... I'm starting builds on
> > i386 and arm64, but since I'm not sure I understand the problem to its full
> > extent, it may - figuratively - need some adult supervision.
> 
> Unfortunately, this diff does not work. Node still segfaults during the
> build. To test, you need an amd64 machine showing PKU in the cpu line in
> dmesg plus a linker that defaults to --execute-only. This was only
> enabled in -current a couple hours ago - I don't know if it's already
> made it into snaps.

Heading out right now.

Re: lang/node - patch for xonly

[Theo de Raadt]

Stuart Henderson  wrote:

> On 2023/01/21 17:36, Volker Schlecht wrote:
> > 
> > 
> > On 1/19/23 22:56, Theo Buehler wrote:
> > 
> > > The trick to apply such patches is to add .diff to the
> > > github link.
> 
> Or .patch, then you get a nice header to paste into the top of
> the patch file too.
> 
> > Neat! I just noted that down ... ;-)
> > 
> > Here's a patch that builds node without USE_NOEXECONLY and
> > without those warnings, producing a working binary on amd64 ...
> > I'm starting builds on i386 and arm64, but since I'm not sure I
> > understand the problem to its full extent, it may - figuratively
> > - need some adult supervision.
> 
> i386 doesn't have execute-only anyway (though as it's touching a file
> which looks like it may affect i386 too, testing that it doesn't break
> is helpful).

moving tables from text into rodata on other architectures will not
create any harm, except there maybe PIC considerations, so some changes
for that may need to be written and tested.

Re: tor-browser can't see ffmpeg

[Theo de Raadt]

onatinadr...@tutanota.com wrote:

> I have no intention to disable unveil permanently. I was just trying
> to solve a bug.

But it does not solve a bug.

It does not even identify the bugs.

If you really wanted to try to act like a developer, you would grab a
huge piece of disk and ktrace -di the browser.

I have also edited source code to add utrace() calls so I can identify
the chunks of code I am in, when reading the ktrace output.

Disabling unveil and pledge is going to provide you with no insight
you can follow.


 When I saw that it didn't work, I enabled it again.
> Yes, I considered using linux. I give it a go from time to time. It gets
> worse every time. It moves away from unix philosophy. I don't like
> it. If I could, I would use plan9 (joking). OpenBSD does not currently
> support the wifi chip on my laptop and the touchpad freezes after
> a while. But I plug in a dongle and a USB mouse and continue
> using OpenBSD. Thank you all for this great operating system.
> 
> Jan 14, 2023, 18:04 by dera...@openbsd.org:
> 
>  At some point you have to realize two things
> 
>  - the restrictions we added to browsers inside are *intentional*
>  to reduce access outside of their general usage, in particular
>  restrictions inside your home directory
> 
>  - But some libraries and applications you are trying to use are
>  designed to violate those principles *intentionally*, because
>  they are written by people on other operating systems, and they
>  either believe they should have access to everything, or they are
>  written to inadvertently access such things.
> 
>  So these principles are incompatible.
> 
>  Sometimes a middle ground can be reached, but there are so many of these
>  circumstances that it is likely that all the possible use cases will
>  never be satisfied. So it is a huge amount of developer time being
>  spent _for the atypical user_.
> 
>  So, have you considered using Linux instead? And I'm really not joking.
>  I'm very serious. That is a system, like Windows, bending over backwards to
>  ensure that applications can do anything they want inside your home
>  directory.
> 
>  It's so bizzare. You are disabling one type of security to gain what
>  you believe is another type of security, hammering nails you do not know.
> 
>  Do you not sense the dissonance?
> 
>  onatinadr...@tutanota.com wrote:
> 
>  (sorry, I forgot to break lines)
> 
>  ok, I disabled unveil by renaming all unveil* files and creating new files
>  that contain only "# disable". the issue persists though. another hint:
>  libmozav* files in /usr/local/lib/tor-browser have the extension .7.0.
>  those in /usr/local/lib/firefox-esr, have the extension 9.0. maybe
>  that's the reason.
> 
>  Jan 13, 2023, 23:55 by :
> 
>  > ok, I disabled unveil by renaming all unveil* files and creating new files
>  that contain only "# disable". the issue persists though. another hint:
>  libmozav* files in /usr/local/lib/tor-browser have the extension .7.0. those
>  in /usr/local/lib/firefox-esr, have the extension 9.0. maybe that's the
>  reason.
>  >
>  > Jan 13, 2023, 14:26 by s...@spacehopper.org:
>  >
>  >> On 2023/01/13 13:30, onatinadr...@tutanota.com wrote:
>  >>
>  >>> before installing ffmpeg, both tor-browser and firefox-esr play
>  >>> youtube videos with sound. after installing ffmpeg, firefox-esr
>  >>> plays videos on other sites too but tor-browser does not. it
>  >>> shows a warning that I need to install codecs. I wonder if it's
>  >>> an unveil issue. I would try disabling unveil for tor-browser
>  >>> but I couldn't find any documentation on how to disable unveil
>  >>>
>  >>
>  >> Should be same as firefox, but in /etc/tor-browser instead.
>  >>
> 

Re: tor-browser can't see ffmpeg

[Theo de Raadt]

At some point you have to realize two things

- the restrictions we added to browsers inside are *intentional*
  to reduce access outside of their general usage, in particular
  restrictions inside your home directory

- But some libraries and applications you are trying to use are
  designed to violate those principles *intentionally*, because
  they are written by people on other operating systems, and they
  either believe they should have access to everything, or they are
  written to inadvertently access such things.

So these principles are incompatible.

Sometimes a middle ground can be reached, but there are so many of these
circumstances that it is likely that all the possible use cases will
never be satisfied.  So it is a huge amount of developer time being
spent _for the atypical user_.

So, have you considered using Linux instead?  And I'm really not joking.
I'm very serious.  That is a system, like Windows, bending over backwards to
ensure that applications can do anything they want inside your home
directory.

It's so bizzare.  You are disabling one type of security to gain what
you believe is another type of security, hammering nails you do not know.

Do you not sense the dissonance?

onatinadr...@tutanota.com wrote:

> 
> 
> (sorry, I forgot to break lines)
> 
> ok, I disabled unveil by renaming all unveil* files and creating new files
>  that contain only "# disable". the issue persists though. another hint:
>  libmozav* files in /usr/local/lib/tor-browser have the extension .7.0.
>  those in /usr/local/lib/firefox-esr, have the extension 9.0. maybe
>  that's the reason.
> 
> Jan 13, 2023, 23:55 by :
> 
> > ok, I disabled unveil by renaming all unveil* files and creating new files 
> > that contain only "# disable". the issue persists though. another hint: 
> > libmozav* files in /usr/local/lib/tor-browser have the extension .7.0. 
> > those in /usr/local/lib/firefox-esr, have the extension 9.0. maybe that's 
> > the reason.
> >
> > Jan 13, 2023, 14:26 by s...@spacehopper.org:
> >
> >> On 2023/01/13 13:30, onatinadr...@tutanota.com wrote:
> >>
> >>> before installing ffmpeg, both tor-browser and firefox-esr play
> >>> youtube videos with sound. after installing ffmpeg, firefox-esr
> >>> plays videos on other sites too but tor-browser does not. it
> >>> shows a warning that I need to install codecs. I wonder if it's
> >>> an unveil issue. I would try disabling unveil for tor-browser
> >>> but I couldn't find any documentation on how to disable unveil
> >>>
> >>
> >> Should be same as firefox, but in /etc/tor-browser instead.
> >>
> 

Re: aarch64 bulk build report

[Theo de Raadt]

> makedepend: error:  out of space: increase MAXFILES

Software that demands infinite resources and will not accept and cope
with failure -- including transient and temporary failure -- on
shared-resource machines, is utterly offensive.  Go back to your
one-program-at-time VIC-20 please.

Re: socksify (from security/dante) and pledged programs

[Theo de Raadt]

How about we delete LD_PRELOAD support from ld.so?

This concept of extending programs underneath is utterly retarded,
because it is fragile in precisely this way, and there is absolutely
nothing we can or should do to help it work.


Caspar Schutijser  wrote:

> Hi all,
> 
> Using socksify (from the security/dante port) in combination with
> pledged programs doesn't go very well. For those who don't know,
> socksify makes programs communicate through a SOCKS proxy by using
> LD_PRELOAD.
> 
> Example:
>   # pkg_add dante # No configuration necessary for this example
>   $ socksify ftp -o /dev/null https://example.org/
>   Trying 93.184.216.34...
>   Abort trap (core dumped)
>   $ dmesg | tail -1
>   ftp[14267]: pledge "inet", syscall 118
> 
> Using gdb and reading the code, I found that a call to getsockopt()
> related to multicast stuff in the dante code is to blame:
> lib/socket.c, line 699:
>683int
>684socks_socketisforlan(s)
>685   const int s;
>686{
> ...
>693   /*
>694* make an educated guess as to whether the socket is 
> intended for
>695* lan-only use or not.
>696*/
>697
>698   len = sizeof(addr);
>699   if (getsockopt(s, IPPROTO_IP, IP_MULTICAST_IF, &addr, &len) 
> != 0) {
>700  slog(LOG_DEBUG, "%s: getsockopt(IP_MULTICAST_IF) failed: 
> %s",
>701   function, strerror(errno));
>702
>703  errno = errno_s;
>704  return 0;
>705   }
> 
> (The socks_socketisforlan() function is called in Rconnect() located
> in lib/Rconnect.c.)
> 
> What would be the best way forward here? Patch away the code that calls
> getsockopt(IP_MULTICAST_IF)? Something else? I don't have any good
> ideas, in part because I don't know enough about why dante cares about
> this, and because I'm not a multicast expert.
> 
> Caspar
> 

Re: Repeated gimp crashes?

[Theo de Raadt]

 597   undo_size = gimp_get_physical_memory_size ();

Any software which does this is written by stupid people.

I have tried to push back against this, but it keeps happening.

The only way the ports community will ever fix this general problem
which keeps being repeated, is by finding a way to be *extremely loud*
about how stupid it is.

Re: Repeated gimp crashes?

[Theo de Raadt]

Stuart Henderson  wrote:

> On 2022/09/20 14:07, Marc Espie wrote:
> > Note that gimp itself has some control over memory used
> > under various circumstances in its Preferences.
> > 
> > I haven't seen any indication that authors in this thread
> > are even aware those parameters exist.
> 
> Probably not because users shouldn't have to fiddle with memory prefs
> (whether that's in the OS or the application) for basic use of the
> software..

what do you mean?!?! i've been tuning my system to allow succesfull use
of ls and emacs for decades!  what a crazy idea that software should
"Just Work", in these days of rampant elephants, that idea will never
take off.

I really have no idea what "control over memory" means.  The only
"control" method I know is MAP_FIXED in mmap.  If deep down that means a
love affair with MAP_FIXED is going on, the pain will continue until it
stops doing that.

Re: Documenting the ENABLE_WASM flag for chrome

[Theo de Raadt]

Yifei Zhan  wrote:

> > WASM is not required on the open internet.  Not required Today.  Hopefully 
> > never.
> 
> I think we unfortunately now already live in such a world, both 
> BigBlueButton and jitsi make use of WASM, and BigBlueButton won't let 
> me join a meeting without having WASM enabled, I think they are by far 
> the most open online meeting software out there.

2 pieces of software does not make a standard.

Maybe you should use zoom or microsoft teams instead -- they use standards,
rather than agenda.

Re: Documenting the ENABLE_WASM flag for chrome

[Theo de Raadt]

My take on this is that WASM is quite simply just new attack surface.

Hear me out.

Imagine tomorrow someone invents WebX86.  One website uses it.  Support
arrives for browsers, now 10 websites use it.  So it gets added.

And next year, someone inventest webARM64thingy.  One website uses it.  Support
arrives for browsers, now 10 websites use it.  So it gets added.

Eventually browsers have so many additional things they must 'parse' and 
'execute'
to perform a web experience.

Of course all of these pieces of code are bugfree.  /sarc.  No everything has
at least one bug, so the potential attack surface of the browser keeps 
increasing,
and the maintainance efforts required by the browser maintainance groups keeps
increasing.

So eventually those groups of people will become even more overwhelmed, and
not be on-their-game ahead of a problem, and the whole security dance will
happen over and over.

I promise you, major security issues will occur.  It won't neccessarily be
in the wasm "executed language", but it will be in the capabilities exported
by the browser code to create the environment, and it is going to suck.

WASM is not required on the open internet.  Not required Today.  Hopefully 
never.

We want software which has the maximum powerful behaviours, but there is a
friction because we really should insist it is done with the least amount of
increased complexity.  And the tradeoff with wasm seems quite poor.