Re: Upgrade 7.5 -> 7.6 fails with fatal page fault in supervisor mode
> Since efifb claimed the console, it should have attached. Yep.
Re: Repeated lines in SHA256
Does it break anything? No. Not important. I'll get to it eventually. Toni Born wrote: > In both files 7.6/amd64/SHA256 and 7.6/amd64/SHA256.sig there are the > following lines: > > SHA256 (install76.img) = > 973dfa837e4998f6c0f29d0afc9f40d85e29a3d2b25fcea8b3f13b4491fbedc0 > SHA256 (install76.img) = > 973dfa837e4998f6c0f29d0afc9f40d85e29a3d2b25fcea8b3f13b4491fbedc0 > SHA256 (install76.iso) = > 60cba8cb391b50bba8fa10fc768bd0529636f5345d82133c93e22c798d8e5269 > SHA256 (install76.iso) = > 60cba8cb391b50bba8fa10fc768bd0529636f5345d82133c93e22c798d8e5269 > > For both image files the checksum appears twice. > May be a feature or a bug. > Same for -current. > > Thanks and best regards. >
Re: [ksh?] quote missing exit error message
So you've got an opinion. And you are loud. But noone cares. Anon Loli wrote: > On Fri, Aug 30, 2024 at 06:41:50PM +0200, Omar Polo wrote: > > On 30/08/24 18:09, Anon Loli wrote: > > > On Thu, Aug 29, 2024 at 07:03:11PM -0400, Nick Holland wrote: > > >> On 8/29/24 16:11, Anon Loli wrote: > > >>> Okay, I have an vague idea about what happens, let me 1st add this to > > >>> the bug > > >>> report: > > >>> > > >>> So I launched a half a dozen tmux windows and they had archivemedia > > >>> script > > >>> running and while I started all the windows, I went on to edit the > > >>> script and > > >>> add a few lines, > > >> so...you were editing a running script? I do believe that falls under > > >> the > > >> category, "undefined behavior". Yeah, I kinda expect things to go bad > > >> when you do that. > > >> > > >> You are probably assuming the file is loaded in RAM at start and stays > > >> there > > >> until done. That's not how it works, I am pretty sure I've tried it and > > >> not > > >> got away with it before, too. > > >> > > >> Nick. > > > Of course I assumed that the file would be loaded in RAM lol why wouldn't > > > I? > > > > Because it's a waste of both memory and time to load an entire file in > > memory before executing it, especially since the nature of the shell. > > > > Also, IIRC the Thompson shell relied on this to implement conditionals. > > I am not fully aware of "the nature of the shell", but I believe that the > current implementation is a hazard to reliability, brings confusion and > undefined behavior, and is an inconvenience. > > Waste of memory? Look I don't know how many scripts OpenBSD actually executes > like for root/system and what-not, but for the userland, this would be a > extremely minor problem. > I'm assuming that non-root or non-system shells like user-executed shells will > have a extremely small memory and time-to-load resource requirements. > I might as well say that an old computer could function like this. > > > > > > It's the only thing that makes sense to me, but then again I don't know > > > how > > > executing scripts works exactly *shrug*. > > > > > > I would like to know why that is, perhaps this is already answered in > > > e-mails > > > I'm yet to read, but my OS will not have this unlogical and unreliable and > > > actually I'm assuming that this is also UNDOCUMENTED undefined behavior, > > > and as > > > > > > such, ksh.1 manual page is at fault here, this is a bugs. > > > > unfortunately, this is how unix actually works. Even if ksh used > > memory-mapped I/O, it could still concurred edits to the files. Heck, in > > some cases using memory-mapped I/O could lead to worst issues (imagine a > > concurrent process truncating the file while you're reading it, and say > > hello to SIGBUS.) > > If the issue is as serious as you make it, and if there is no other approach > to > this which can prevent this issue, then: > you could get the file modes of the file, change it to read-only to the > users/groups who already could read it, read it to memory, and then chmod it > to > the original file modes. > > By the way, what is this "\xc2\xa0" twice, some Android version of quotes? > > > > > > Note that this also depends on how the editor you're using writes the files > > back to the disk. Some editors will just rewrite the file in-place, which > > means that other processes can see these concurred edits, while others will > > use a tempfile + rename scheme. No one is strictly better than the other. > > Interesting. > The issue happens when editing with vi(1) as well as neatvi. >
Re: Signed integer overflow in telnet.
Noone uses telnet, we (mostly) killed it!
https://www.openbsd.org/images/tshirt-9b.jpg
There is no way in heck this code is going to be converted in OpenBSD
to use strtol(), which is even more willing to eat junk.
In our world, someone should adapt this to strtonum(), which is
a cynical string to integer API with range-control built in.
Collin Funk wrote:
> Hi,
>
> Earlier this week I committed this change in GNU Inetutils [1]. When
> sending the 'send dont ' telnet command, the value is not checked
> for overflow. Likewise for 'do', 'will', 'wont'.
>
> Another GNU Inetutils developer segfaults doing 'send dont 2147483648'
> and 'send dont 9223372034707292160' but I cannot reproduce it.
>
> Here is a rough patch I wrote to usr.bin/telnet/commands.c that should
> fix it. I don't have an OpenBSD machine at the moment so I can't compile
> and test it. Sorry about that.
>
> --- commands.c2024-08-25 19:21:24.316731997 -0700
> +++ commands-fixed.c 2024-08-25 19:27:17.500422616 -0700
> @@ -358,7 +358,7 @@
> {
> char **cpp;
> extern char *telopts[];
> -int val = 0;
> +long int val = 0;
>
> if (isprefix(name, "help") || isprefix(name, "?")) {
> int col, len;
> @@ -389,14 +389,12 @@
> if (cpp) {
> val = cpp - telopts;
> } else {
> - char *cp = name;
> + char *cp = NULL;
>
> - while (*cp >= '0' && *cp <= '9') {
> - val *= 10;
> - val += *cp - '0';
> - cp++;
> - }
> - if (*cp != 0) {
> + errno = 0;
> + val = strtol(name, &cp, 10);
> +
> + if (*cp != 0 || errno != 0) {
> fprintf(stderr, "'%s': unknown argument ('send %s ?' for
> help).\r\n",
> name, cmd);
> return 0;
>
> Collin
>
> [1]
> https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=a6d9848a32fafa763548e54b44cb094abdac915d
>
Re: sysupgrade Verifying sets FAILED
Never. UDENIX wrote: > >> I wish OpenBSD supported using mirrors hosted on the Tor or I2P networks > >> for > >> system and package installation and upgrades. For instance, Debian not only > >> supports but also maintains official mirrors on the Tor network. > > Not going to happen. If you can find a trustworthy source of files > > on > > one of those networks you could download the img or iso and install > > from there, but the install kernel is a very constrained environment - > > there's no space to add things like that. > > I'm not asking for Tor or I2P to be added to the base system, but > rather for the ability to use mirrors hosted on these networks without > having to go through a lot of steps [1]. Ideally, it should be as > simple as installing the necessary software (even if it's from the > ports tree), configuring and running it, and then adding the mirror > address to installurl(5). This should be sufficient to install and > update the system and packages. > > On the other hand, there are kernel drivers for WireGuard, but > WireGuard is not included in the base system because it violates > OpenBSD's copyright policy. In contrast, the Tor and I2Pd routing > software is licensed under the 3-Clause BSD license. > > [1] > https://dataswamp.org/~solene/2024-05-25-openbsd-privacy-friendly-mirror.html >
Re: Oneshot S0
I think the check should definately be removed. It is not right for what we are trying to do -- best effort suspend. This driver contains more than enough for success, and that ACPI bit is meaningless. At most it is "advisory".
Re: Oneshot S0
Greg Steuck wrote: > Mark Kettenis writes: > > > The diff also defines CONFIG_AMD_PMC and #ifdefs out the FADT check. > > With that suspend-to-idle also works on that m715q. I'm still not > > entirely sure what to do there. But I'll probably propose to commit > > those separately such that we can easily back those bits out. > > > > Thoughts? Tests? ok? > > My machine is now reliably going to sleep and wakes up. Thanks for the patch! Well, there is sleep and there is sleep. Do pay attention to the "wakeups" line. Something like "wakeups: 3 3" isn't bad, but "wakeups: 7923434 3" is bad.
Re: Oneshot S0
> Or maybe the code that checks S0i support is buggy? Or maybe we should not be looking at this ACPI bit, and instead carry on trying to do best-effort idle. It's better than not doing anything.
Re: Oneshot S0
Well you can do the same thing as the rest of us, sadly. printf debugging!
Re: Wake up to crash in sd_buf_done
Greg Steuck wrote: > Mark Kettenis writes: > > > Anyway, I think you're right in thinking that nvme_intr() needs some > > belt and suspenders. In nvme_shutdown() we delete the "normal" > > command queue, but nvme_intr() inconditionally looks at both of them. > > Now nvme_shutdown() masks the interrupt and nvme_resume() unmasks it > > only after it re-creates the "normal" command queue. But I think > > there are scenarios where we can get a spurious interrupt and it would > > check a queue that isn't there. So I think something like the diff > > below would make sense. > > > > Greg, does this fix your crash? > > I applied this on top of -current. Sadly I'm still getting the same > crashes in sd_buf_done. Can you add some printf's to track what happens to sc_q ?
Re: Wake up to crash in sd_buf_done
nvme resume is really crazy, since it does not believe the device is stopped, tries to use high-level operations to stop it and then restart it, but it ends up reusing queue structures from before. dv spent time in here, and I tried to figure it out also. The code is highly suspect since it isn't doing the MINIMUM, which is: at suspend time, ensure the soft state is good, and shut the hw down HARD. On resume, reset the hardware HARD in the minimum fashion, and then reconfigure it to match the soft state. it sounds so simple, but the code that exists is about 20x more complicated than this, and it doesn't make any sense to me why it is so complicated. dlg, jmatthew, can you show up?
Re: Wake up to crash in sd_buf_done
No the problem will be in nvme_intr(), it should not be reaching nvme_q_complete(), let alone finding something in the queue to hand off to scsi_done(). I suspect it has gotten confused by an index that has been reset, and is replying an operation it finds in the memory.
Re: Wake up to crash in sd_buf_done
I think this nvme thing is possibly related to a whole bunch of hidden resume failures.
Re: Wake up to crash in sd_buf_done
Mark Kettenis wrote: > > 0(d85fe50a7e0,2,35d87c,4505,8025c000,fd85fe50a7e0) at 0 > > scsi_done(fd85fe50a7e0) at scsi_done+0x31 > > nvme_q_complete(80255000, 82c79a80) at nume_q_complete+0x134 > > nume_intr(80255000) at nume_intr+0x2b > > intr_handler(800049e24990, 80254200) at intr_handler+0x91 > > Xintr_ioapic_edge28_untramp() at Xintr_ioapic_edge28_untramp+0x18f > > acpicpu_idle() at acpicpu_idle+0x131 > > sched_idle(82770ff0) at sched_idle+0x298 > > > > end trace frame: 0x0, count: 8 > > I think this is a bug in nvme(4). For some reason it gets a > (spurious?) interrupt while in the suspended state with stuff torn > down and dereferences a stale pointer. We probably need to do a > better job quiescing the thing when we suspend. No kidding. dv, did you get anywhere with your various diffs? Greg, can you try out the various diffs he sent? It's a mishmash of solutions not yet entirely decided. The nvme driver doesn't seem to have any soft state variable which will indicate that it is "down". Comparing against ahci, it also has no such variable, but inspection of an ahci port will never show work to do. It is curious that nvme_q_complete() will find anything to do inside a ring. There is no way a scsi transaction should be sitting on a queue. The bufq layer has ensured there is no transaction. I think the ring contains garbage for some reason. dlg / jmatthew, any thoughts?
Re: pf: UDP divert-to to a local addr won't send traffic back
> OK to violate RFC for performance and simplicity? I also think the RFC is asking too much (insensitive to the cost on software routers).
Re: crontab(5) clarification: "~" field is evaluated once at install time
Stuart Henderson wrote: > The '~' character gets expanded to a random value when the > .Nm crontab > is loaded. Yes. > "The allowed values for the fields" above misses the various > possibilities involving ~ too. It's crazy text, especially the phrase "(within the legal range)" just loses the plot, and later on using "inclusive" doesn't help either. The paragraph needs to be rewritten. It's a strong feature, but described very evasively.
Re: Macmini8,1 fixes and problems
That kind of doesn't matter. It's the spoofed label. It does not indicate workable IO. The 3 issues together... it smells like an interrupt problem.
Re: strmode should take a mode_t instead of int.
ok deraadt
I anticipate no fallout, or very minor and we can handle it then.
Otto Moerbeek wrote:
> On Thu, Jun 20, 2024 at 09:17:38AM +0200, Otto Moerbeek wrote:
>
> > On Wed, Jun 19, 2024 at 06:44:56PM +0200, Theo Buehler wrote:
> >
> > > These are the ports using strmode.
> > >
> > > archivers/libarchive
> > > archivers/libtar
> > > editors/emacs
> > > games/gemrb
> > > math/octave
> > > misc/findutils
> > > net/lftp
> > > security/ssh-ldap-helper
> > > shells/ksh93
> > > sysutils/bfs
> > > sysutils/colorls
> > > sysutils/coreutils
> > > sysutils/lnav
> > > sysutils/tarsnap
> > >
> > > Given the short list and the nature of the change, I don't think it's
> > > necessary to run a bulk, but inspecting a few of them would be good,
> > > especially libarchive and coreutils are depended upon by a lot of ports.
> > > And there's emacs in this list.
> >
> > New diff, taking the suggestion (but not all of it, the implementation
> > can use mode_t as it includes sys/types.h
> >
> > I tested base + coreutils + emacs builds with this.
>
> ping...
>
> >
> > -Otto
> >
> > Index: include/string.h
> > ===
> > RCS file: /home/cvs/src/include/string.h,v
> > diff -u -p -r1.32 string.h
> > --- include/string.h5 Sep 2017 03:16:13 - 1.32
> > +++ include/string.h20 Jun 2024 07:13:03 -
> > @@ -37,7 +37,7 @@
> >
> > #include
> > #include
> > -#include
> > +#include
> >
> > /*
> > * POSIX mandates that certain string functions not present in ISO C
> > @@ -128,7 +128,7 @@ size_t strlcat(char *, const char *, si
> > __attribute__ ((__bounded__(__string__,1,3)));
> > size_t strlcpy(char *, const char *, size_t)
> > __attribute__ ((__bounded__(__string__,1,3)));
> > -voidstrmode(int, char *);
> > +voidstrmode(__mode_t, char *);
> > char *strsep(char **, const char *);
> > int timingsafe_bcmp(const void *, const void *, size_t);
> > int timingsafe_memcmp(const void *, const void *, size_t);
> > Index: lib/libc/string/strmode.c
> > ===
> > RCS file: /home/cvs/src/lib/libc/string/strmode.c,v
> > diff -u -p -r1.8 strmode.c
> > --- lib/libc/string/strmode.c 31 Aug 2015 02:53:57 - 1.8
> > +++ lib/libc/string/strmode.c 20 Jun 2024 07:13:03 -
> > @@ -32,10 +32,8 @@
> > #include
> > #include
> >
> > -/* XXX mode should be mode_t */
> > -
> > void
> > -strmode(int mode, char *p)
> > +strmode(mode_t mode, char *p)
> > {
> > /* print type */
> > switch (mode & S_IFMT) {
> >
>
Re: strmode should take a mode_t instead of int.
Todd C. Miller wrote: > On Wed, 19 Jun 2024 15:17:05 +0200, Otto Moerbeek wrote: > > > Additionally, the implementation in src/libn/libc/string/strmode.c > > needs to start using mode_t. > > > > Building base now with the diff below. So far so good. > > > > But this is more tricky you would think. Modifying string.h to include > > more could have unwanted side effects for applications. > > This looks fine to me but I agree with kettenis@ that just using > __mode_t directly in the prototype would be a bit safer since it > avoids any namespace pollution. I don't expect any problems including > sys/_types.h in place of machine/_types.h. Agree. I don't think it needs any API/ABI cranks, either.
Re: Minor doc-vs-implemention conflict in /etc/daily vs test(1)
I am finding myself in agreement.
Have we decided who will die on the hill?
Ingo Schwarze wrote:
> Not a bug.
> But which one is preferable, test -L or test -h?
>
> TLDR:
> If you follow David Korn, -L is the way to go.
> If you feel nostalgic about old SunOS, -h looks nicer.
> Both were standardized in POSIX Issue 6 (2001), with no preference given
> there.
> Both always worked on OpenBSD, no matter which base system shell was used.
> In the OpenBSD ancestry, there was no difference in portability
> except between June 1993 and June 1995 (at most).
>
> I admit that usually, when there are two equivalent syntaxes, deprecating
> one of them makes sense. But in this case, with POSIX setting both in
> stone over 20 years ago, attempting to die on that particular molehill
> seems pointless to me.
>
> Hence i suggest the patch below; OK?
>
> More complete history follows after the patch (just for the curious :-).
> This does not contradict what jmc@ wrote, but contains more information.
>
> Yours,
> Ingo
>
>
> Index: test.1
> ===
> RCS file: /cvs/src/bin/test/test.1,v
> diff -u -p -r1.34 test.1
> --- test.110 Jun 2023 07:19:39 - 1.34
> +++ test.117 Jun 2024 21:22:30 -
> @@ -110,6 +110,8 @@ is set.
> True if
> .Ar file
> exists and is a symbolic link.
> +Identical to
> +.Fl L .
> .It Fl k Ar file
> True if
> .Ar file
> @@ -118,11 +120,8 @@ exists and its sticky bit is set.
> True if
> .Ar file
> exists and is a symbolic link.
> -This operator is for compatibility purposes.
> -Do not rely on its existence;
> -use
> -.Fl h
> -instead.
> +Identical to
> +.Fl h .
> .It Fl n Ar string
> True if the length of
> .Ar string
> Index: test.c
> ===
> RCS file: /cvs/src/bin/test/test.c,v
> diff -u -p -r1.20 test.c
> --- test.c11 Oct 2022 13:40:38 - 1.20
> +++ test.c17 Jun 2024 21:22:31 -
> @@ -110,7 +110,7 @@ struct t_op {
> {"-t", FILTT, UNOP},
> {"-z", STREZ, UNOP},
> {"-n", STRNZ, UNOP},
> - {"-h", FILSYM, UNOP}, /* for backwards compat */
> + {"-h", FILSYM, UNOP},
> {"-O", FILUID, UNOP},
> {"-G", FILGID, UNOP},
> {"-L", FILSYM, UNOP},
>
>
> - 8< - schnipp - >8 - 8< - schnapp - >8 -
>
> History in OpenBSD ancestry:
>
> OpenBSD:
> ksh(1) had both since the beginning, Aug 14, 1996 (pdksh 5.2.7).
> Before that, /bin/sh, which was ash, did not have a "test" builtin
> at all but used /bin/test instead, which also had both.
> csh(1) never had a "test" builtin.
>
> NetBSD:
> /bin/test has -h since Feb 19, 1994 ("a la SunOS")
> -L since Jun 30, 1994 ("from pdksh")
>
> 4.4 BSD (June 1993) and 4.4BSD-Lite2 (June 1995):
> /bin/sh (ash) did not have a "test" builtin but used /bin/test instead.
> /bin/test had -h but not -L.
>
> Version 7 AT&T UNIX (1979) and 4.3BSD-Reno (June 1990):
> /bin/sh (Bourne) did not have a "test" builtin but used /bin/test instead.
> /bin/test had neither -h nor -L.
>
Re: Unchartevice 6640MA dmesg + AHCI MSI quirk
And the big comment is correct. It may not be this specific chip.
It's this specific chip on this specific machine. Later on we
may know more, to identify the problem better.
Mark Kettenis wrote:
> > Date: Sun, 16 Jun 2024 16:37:10 +
> > From: Klemens Nanni
> >
> > GENERIC cpu(4) fix and pcidevs have been committed.
> > Now only this ahci(4) quirk is pending to fix the SSD.
> >
> > Neither Linux nor FreeBSD seem to have AHCI and/or MSI specific
> > quirks for this, but contrary to OpenBSD they can boot and use the
> > SSD.
> >
> > Until there's a better way, this disabling MSI for that specific
> > AHCI controller like already done for specific Intel MacBooks make
> > snapshhots usable for me.
> >
> > Feedback? Objection? OK?
>
> Since other devices seem to work fine with MSI, this is the right fix.
>
> ok kettenis@
>
> > Index: sys/dev/pci/ahci_pci.c
> > ===
> > RCS file: /cvs/src/sys/dev/pci/ahci_pci.c,v
> > diff -u -p -r1.17 ahci_pci.c
> > --- sys/dev/pci/ahci_pci.c 24 May 2024 06:02:53 - 1.17
> > +++ sys/dev/pci/ahci_pci.c 15 Jun 2024 20:19:30 -
> > @@ -71,6 +71,8 @@ int ahci_intel_attach(struct
> > ahci_soft
> > struct pci_attach_args *);
> > intahci_samsung_attach(struct ahci_softc *,
> > struct pci_attach_args *);
> > +intahci_storx_attach(struct ahci_softc *,
> > + struct pci_attach_args *);
> >
> > static const struct ahci_device ahci_devices[] = {
> > { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_HUDSON2_SATA_1,
> > @@ -148,7 +150,10 @@ static const struct ahci_device ahci_dev
> > NULL, ahci_samsung_attach },
> >
> > { PCI_VENDOR_VIATECH, PCI_PRODUCT_VIATECH_VT8251_SATA,
> > - ahci_no_match,ahci_vt8251_attach }
> > + ahci_no_match,ahci_vt8251_attach },
> > +
> > + { PCI_VENDOR_ZHAOXIN, PCI_PRODUCT_ZHAOXIN_STORX_AHCI,
> > + NULL, ahci_storx_attach },
> > };
> >
> > intahci_pci_match(struct device *, void *, void *);
> > @@ -279,6 +284,19 @@ ahci_samsung_attach(struct ahci_softc *s
> > * as the XP941 SSD controller.
> > * https://bugzilla.kernel.org/show_bug.cgi?id=60731
> > * https://bugzilla.kernel.org/show_bug.cgi?id=89171
> > +*/
> > + sc->sc_flags |= AHCI_F_NO_MSI;
> > +
> > + return (0);
> > +}
> > +
> > +int
> > +ahci_storx_attach(struct ahci_softc *sc, struct pci_attach_args *pa)
> > +{
> > + /*
> > +* Disable MSI with the ZX-100/ZX-200/ZX-E StorX AHCI Controller
> > +* in the Unchartevice 6640MA notebook, otherwise ahci(4) hangs
> > +* with SATA speed set to "Gen3" in BIOS.
> > */
> > sc->sc_flags |= AHCI_F_NO_MSI;
> >
> >
> >
>
Re: xterm configuration breaks tmux feature
I don't think you've considered how bad the design of the feature is. If a program terminates by accident in the wrong state, other software running afterwards is unaware that the session is behaving incorrectly, and there are some dangerous conditions that a user cannot recover from. (There are other tty-related things which have similar issues; our handling of this is to avoid creating more of a mess) Kyle Markley wrote: > There is a second layer of defense present: xterm can be configured at > runtime, through its disallowedWindowOps resource, to enable or > disable the SetSelection and GetSelection operations individually. > > I think it would be more user friendly to have this feature compiled > in, but left disabled by default via disallowedWindowOps. It was not > user friendly for SetSelection and GetSelection support to be absent > without any hint of their removal in the xterm man page. > > These options would not need to be enabled in ~/.Xresources, but could > be enabled only as needed e.g. with xterm -xrm stuff -e tmux, and tmux > configured with set-clipboard external (rather than on). I think this > would give clipboard access only to tmux but not the applications > within it. > > > On 4/18/24 10:14, Theo de Raadt wrote: > > It is an extremely dangerous anti-feature. > > > >> I observed that in OpenBSD 7.5, the configuration of xterm is such that > >> xtermcfg.h gets #define OPT_PASTE64 0. A consequence of this is that > >> OSC 52 support is compiled out, and a consequence of that is that tmux > >> cannot set the primary X selection (for copying text out of a tmux pane) > >> via its set-clipboard option, which uses OSC 52. > >> > >> I encountered this problem as a frustrating silent failure after > >> following the instructions at the tmux wiki > >> (https://github.com/tmux/tmux/wiki/Clipboard). > >> > >> Is there a reason that paste64 is configured out, or could we change > >> this (e.g. with --enable-paste64) so that OPT_PASTE64 is 1? > >> > >> -- Kyle Markley > >> > >> > > -- > Kyle Markley >
Re: xterm configuration breaks tmux feature
It is an extremely dangerous anti-feature. >I observed that in OpenBSD 7.5, the configuration of xterm is such that >xtermcfg.h gets #define OPT_PASTE64 0. A consequence of this is that >OSC 52 support is compiled out, and a consequence of that is that tmux >cannot set the primary X selection (for copying text out of a tmux pane) >via its set-clipboard option, which uses OSC 52. > >I encountered this problem as a frustrating silent failure after >following the instructions at the tmux wiki >(https://github.com/tmux/tmux/wiki/Clipboard). > >Is there a reason that paste64 is configured out, or could we change >this (e.g. with --enable-paste64) so that OPT_PASTE64 is 1? > >-- >Kyle Markley > >
Re: httpd build error on 7.5 on Intel Core i7-2600
Your machine is not actually running 7.5, because your /usr/include directory has old files. Kevin wrote: > Hey gang, > > Got the below error when building httpd from source on a bare metal > Intel Core i7-2600 with 4 CPUs. > > Ran the identical command on a virtualized AMD EPYC without issue. > > And, was also able to copy and run successfully the resultant httpd > binary from the AMD EPYC on the Core i7. > > For the record, I used _the same_ src.tar.gz and sys.tar.gz files on > both machines. > > Both machines produce identical sha512s of those two files. > > Both machines began life at 7.3 and have been tracking official > releases / patches / upgrades since 7.3 and have been updated / > upgraded in a timely fashion using sysupdate / sysupgrade. > > Here are the steps that caused the error: > > # cd /usr/src/usr.sbin/httpd > > # make clean > rm -f a.out [Ee]rrs mklog *.core y.tab.h httpd parse.o config.o > control.o httpd.o log.o logger.o proc.o server.o server_http.o > server_file.o server_fcgi.o patterns.o parse.c css.h js.h parse.d > config.d control.d httpd.d log.d logger.d proc.d server.d > server_http.d server_file.d server_fcgi.d patterns.d > > # make obj > /usr/src/usr.sbin/httpd/obj -> /usr/obj/usr.sbin/httpd > > # make > yacc -o parse.c /usr/src/usr.sbin/httpd/parse.y > cc -O2 -pipe -Wall -I/usr/src/usr.sbin/httpd > -I/usr/src/usr.sbin/httpd/obj -Wstrict-prototypes -Wmissing-prototypes > -Wmissing-declarations -Wshadow -Wpointer-arith -Wsign-compare > -Wcast-qual -Werror-implicit-function-declaration -MD -MP -c parse.c > cc -O2 -pipe -Wall -I/usr/src/usr.sbin/httpd > -I/usr/src/usr.sbin/httpd/obj -Wstrict-prototypes -Wmissing-prototypes > -Wmissing-declarations -Wshadow -Wpointer-arith -Wsign-compare > -Wcast-qual -Werror-implicit-function-declaration -MD -MP -c > /usr/src/usr.sbin/httpd/config.c > /usr/src/usr.sbin/httpd/config.c:638:7: error: call to undeclared > function 'imsg_get_fd'; ISO C99 and later do not support implicit > function declarations [-Werror,-Wimplicit-function-declaration] > fd = imsg_get_fd(imsg); > ^ > /usr/src/usr.sbin/httpd/config.c:638:7: note: did you mean 'imsg_get'? > /usr/include/imsg.h:116:10: note: 'imsg_get' declared here > ssize_t imsg_get(struct imsgbuf *, struct imsg *); > ^ > 1 error generated. > *** Error 1 in /usr/src/usr.sbin/httpd (:87 'config.o') > > > Here's the dmesg from the Intel: > > OpenBSD 7.5 (GENERIC.MP) #82: Wed Mar 20 15:48:40 MDT 2024 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 17085018112 (16293MB) > avail mem = 16546058240 (15779MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xeb1d0 (104 entries) > bios0: vendor American Megatrends Inc. version "9005" date 09/18/2018 > bios0: ASUSTeK COMPUTER INC. P8H67-M PRO > acpi0 at bios0: ACPI 4.0 > acpi0: sleep states S0 S1 S3 S4 S5 > acpi0: tables DSDT FACP APIC MCFG HPET SSDT SSDT SSDT DMAR > acpi0: wakeup devices PS2K(S4) P0P1(S4) RP01(S4) PXSX(S4) RP02(S4) > PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) > RP06(S4) PXSX(S4) RP07(S4) PXSX(S4) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3411.61 MHz, 06-2a-07, > patch 002f > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 8-way L2 cache, 8MB 64b/line 16-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 100MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3411.74 MHz, 06-2a-07, > patch 002f > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 8-way L2 cache, 8MB 64b/line 16-way L3 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 4 (application processor) > cpu2: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3411.86 MHz, 06-2a-07, > patch 002f > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PS
Re: pcidevs_data.h relies on pcireg.h despite not including it.
Gibson Pilconis wrote: > I'm working on a project that supports OpenBSD and I noticed that > pcidevs_data.h uses > structures defined in pcireg.h but doesn't include the file. As a result, > pcireg.h has > to be included before pcidevs_data.h or else the compiler will throw an > error. > > I'm not sure if this is considered a bug or not, but I couldn't find any > documentation > of it and I could easily see it confusing newer developers. If adding an > include to > the header isn't an option, perhaps adding in a comment informing developers > they need > to import pcireg.h would prove useful. Have you ever found a header file called everything.h? Imagine if you would. You'd be able to do #include and since everything.h would include everything, you would not need to specify subsets of things you are interested in. But that's not how the world works. We very often intentionally require manual includes of things before they are used. Not trying to be argumentive. It just Is How It Is.
Re: Stopped at smu7_powergate_uvd+0x23
You can try booting with:
boot -c
> disable amdgpu0
> quit
That will probably put you into boring vga graphics, you can compile, and
test quickly.
Avon Robertson wrote:
> On Thu, Mar 07, 2024 at 03:50:15PM +1100, Jonathan Gray wrote:
> > Thanks for the detailed report.
> >
> > smu7_powergate_uvd+0x23
> > pp_set_powergating_by_smu+0x15a
> > amdgpu_dpm_enable_uvd+0xc1
> > taskq_thread
> >
> > POLARIS10 has UVD 6.3
> >
> > If driver init fails the task gets removed by:
> >
> > cancel_delayed_work_sync(&adev->uvd.idle_work);
> >
> > uvd_v6_0_hw_fini
> > amdgpu_device_ip_fini_early
> > amdgpu_device_fini_hw
> > amdgpu_driver_unload_kms
> > amdgpu_driver_load_kms
> > amdgpu_attachhook
> >
> > but your trace must occur before that gets cleaned up
> >
> > smu7_powergate_uvd+0x23 is
> > /sys/dev/pci/drm/amd/pm/powerplay/hwmgr/smu7_clockpowergating.c:118
> >
> >114 void smu7_powergate_uvd(struct pp_hwmgr *hwmgr, bool bgate)
> >115 {
> >116 struct smu7_hwmgr *data = (struct smu7_hwmgr
> > *)(hwmgr->backend);
> >117
> >118 data->uvd_power_gated = bgate;
> >
> > Try the following revert of
> > 'drm/amd/pm/smu7: fix a memleak in smu7_hwmgr_backend_init'
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.6.y&id=ae7cbf935b9a1b41f65fe6443e7cd0c401500b20
> >
> > The matching OpenBSD commit was rev 1.9
> > date: 2024/01/29 01:51:19; author: jsg; state: Exp; lines: +5 -1;
> > commitid: cUHNbtd9MymExldJ;
> >
> > Index: sys/dev/pci/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c
> > ===
> > RCS file: /cvs/src/sys/dev/pci/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c,v
> > diff -u -p -r1.10 smu7_hwmgr.c
> > --- sys/dev/pci/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c 6 Feb 2024
> > 03:55:02 - 1.10
> > +++ sys/dev/pci/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c 7 Mar 2024
> > 02:43:27 -
> > @@ -2974,8 +2974,6 @@ static int smu7_hwmgr_backend_init(struc
> > result = smu7_get_evv_voltages(hwmgr);
> > if (result) {
> > pr_info("Get EVV Voltage Failed. Abort Driver
> > loading!\n");
> > - kfree(hwmgr->backend);
> > - hwmgr->backend = NULL;
> > return -EINVAL;
> > }
> > } else {
> > @@ -3021,10 +3019,8 @@ static int smu7_hwmgr_backend_init(struc
> > }
> >
> > result = smu7_update_edc_leakage_table(hwmgr);
> > - if (result) {
> > - smu7_hwmgr_backend_fini(hwmgr);
> > + if (result)
> > return result;
> > - }
> >
> > return 0;
> > }
> >
>
> Thank you for your response Jonathon.
>
> I will do as you have suggested and inform bugs@ of the result.
>
> It will take me a day or so to do that however. Compiling the new
> kernel on another machine will be ok. Getting it installed on the
> problem machine will need some reconfiguration using an install75.img
> USB flash drive's shell which should be staightforward.
>
> --
> aer
>
Re: panic: kernel diagnostic assertion "p->p_wchan == NULL" failed
Claudio Jeker wrote: > Thanks for the details. I suggest to commit this so we can get some tests > quickly and hopefully it helps to fix some of the wg(4) crashes people > hit. According to your other mail there are some additional races that > require fixing. quickly means now, and we have about 2 weeks to pull it out (it has a .h file diff in it, but userland does not really look at it)
Re: Gajim msyscall error
Mark Kettenis wrote: > > From: "Theo de Raadt" > > Date: Sun, 03 Mar 2024 08:20:33 -0700 > > > > It almost feels as if libc.so equivelancy should be closer to > > _dl_find_shlib(), > > > > (in particular, meaning searchpath[0] in _dl_find_shlib() coming > > from lpath in _dl_load_shlib() > > > > Is testing for this in loader.c not the right place, and that > > code should be moved to a deeper place, reached by more variations? > > Yes, the diff below would make more sense. Anyway, probably something > to do after the next release? > > > The thing that would break is if someone dlopen() of > > "libc.so.not-a-system-library", and that is a real .so but not a real > > full libc; imagine it just contains 1 stub function which isn't a > > system call. it would now fail to load that stub function. So maybe > > it is better if we force the applications to request "libc.so". No, I'm scared because this diff still converts "libc.so.tinysomething" with reference to the preloaded "libc.so". I think stuart's diff to python is safer.
Re: Gajim msyscall error
Stuart Henderson wrote: > +allow dlopen() to search for libc rather than parsing ldconfig -r to > +decide on a version number. > + > +(would this make sense for all libraries? I'm not sure exactly what > +parameters this might be called with, whether it's just a bare name or > +could have a path/version in it). I wonder how many places we have the same problem with other libraries. libc.so is just being strict and failing hard. Other libraries may fail in extremely subtle ways. One caller changes global state in libfoo.so.A.A's mapping, another caller uses libfoo.so.X.X's mapping without having the initialized state. Why would we ever want two libfoo.so.?.? mapped into memory? I suspect the hard-to-diagnose bugs are more dangerous than the capability to do so.
Re: Gajim msyscall error
It almost feels as if libc.so equivelancy should be closer to _dl_find_shlib(), (in particular, meaning searchpath[0] in _dl_find_shlib() coming from lpath in _dl_load_shlib() Is testing for this in loader.c not the right place, and that code should be moved to a deeper place, reached by more variations? The thing that would break is if someone dlopen() of "libc.so.not-a-system-library", and that is a real .so but not a real full libc; imagine it just contains 1 stub function which isn't a system call. it would now fail to load that stub function. So maybe it is better if we force the applications to request "libc.so".
Re: Gajim msyscall error
Stuart Henderson wrote: > > aha: gajim is calling setproctitle via ctypes, which dlopen()'s libc.so > > (without a specific version number). ld.so is picking the latest and > > loading it, but libc.so.98.0 was already loaded, so we hit msyscall > > error. > > oh, it's not ld.so which is picking the latest version, it's python's > ctypes code, which parses the output of "ldconfig -r" to decide. That's just so ridiculous. On all other operating systems that is not neccessary, because they don't do versioning, so they only have one library. That approach is wrong. Does it work if this is modified to just ask for "libc.so"? > I don't think there's anything we can sanely do in ld.so to work > around this. No, actually maybe we can. It just isn't what the current ld.so diff was trying to do. It was more conservative. It could perform more aggressive remapping, but then we need a long test cycle to ensure there's no bad effects.
Re: Gajim msyscall error
> aha: gajim is calling setproctitle via ctypes, which dlopen()'s libc.so > (without a specific version number). ld.so is picking the latest and > loading it, but libc.so.98.0 was already loaded, so we hit msyscall > error. Time to explain the msyscall thing a bit. msyscall(2) will go away after release, since pinsyscalls(2) has replaced it. msyscall(2) was the first mechanism for "range of memory where system calls occur from", pinsyscalls(2) is the new mechanism with "precise entry points for system calls". The failure to msyscall(2) prints a warning message in ld.so. But the failure of pinsyscalls(2) in ld.so does not print a warning message. However the pinsyscalls(2) failure is visible in the ktrace. Both of them fail. The reality is if a system call is called from that 2nd libc.so library mapping, the process will exit hard with SIGABRT. It isn't the msyscall message that matters here, but that you simply can't have another region containing the ability to call system calls. ld.so was modified to coerce additional "libc.so" mapping requests into reusing the first libc.so choice made by ld.so. The ld.so/loader.c logic has not chosen to do that in this case, and I can't see why that didn't happen. There's two bugs, really. 1. the application chose to load another library version, because it is compiled or discovered somehow. We cannot find and fix all those cases because programs do really weird things to get those library names. 2. ld.so must do the job of coercing all "libc.so*" requests to the original libc.so choice, and the ld.so diff isn't sufficient for this case. We can't fix 1, so #2 is what kettenis has been trying to do.
Re: pkg_add -u not working since last sysupgrade (openbsd-current)
Sylvain Saboua wrote: > Le 2024-03-02 21:40, Todd C. Miller a écrit : > > On Sat, 02 Mar 2024 21:26:23 +0100, Sylvain Saboua wrote: > > > >> This works to retrieve and install/update packages as > >> expected, but I don't get why it should be necessary > >> since I am not running a release kernel. Or am I ? > >> $uname -a > >> OpenBSD lap.saboua.xyz 7.5 GENERIC.MP#44 amd64 > > Because there is no -current or -beta suffix in the kernel version > > pkg_add doesn't know to use the snapshots directory. That is why > > you need to use -Dsnap. This happens at the end of every release > > cycle before the final packages are built. > > - todd > > Really ? I don't remember having to do this when using > the -current back then. Maybe read the reply. > > If so then shouldn't it feature in the second example > given in the upgrade.site manpage ? > https://man.openbsd.org/upgrade.site.5#EXAMPLES > > At least, I don't know how but the sysupgrade and pkg_add > eventually worked. No. They have both behaved strangely at release time, and problems like this will likely persist because we are terrified of introducing a logic which sneaks into a release, such that it accidentally downloads from the wrong place for everyone for 6 months.
Re: Gajim msyscall error
Is this a situation where two libc's are being loaded into the address space? And the 2nd one is refused for pinsyscalls & msyscall, etc etc. We solved that for most programs. Something special about python? Stuart Henderson wrote: > On 2024/03/02 20:32, Lucas Gabriel Vuotto wrote: > > gajim is reporting a msyscall error on launch since today's snapshot. > > This is likely to be fixed by updating to packages built against the new > libc version when they're available. > > > OpenBSD 7.5 (GENERIC.MP) #46: Fri Mar 1 19:36:05 MST 2024 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > 99921 python3.10 CALL munmap(0xfbdb9aea778,0x6e8) > > 99921 python3.10 RET munmap 0 > > 99921 python3.10 CALL > > pinsyscalls(0xfbdbb503000,0xa8000,0xfbdb71b7000,0x14b) > > 99921 python3.10 RET pinsyscalls -1 errno 1 Operation not permitted > > 99921 python3.10 CALL msyscall(0xfbdbb503000,0xa8000) > > 99921 python3.10 RET msyscall -1 errno 1 Operation not permitted > > 99921 python3.10 CALL write(2,0xfbe2e754020,0x21) > > 99921 python3.10 GIO fd 2 wrote 33 bytes > >"msyscall fbdbb503000 a8000 error > >" > > 99921 python3.10 RET write 33/0x21 > > 99921 python3.10 CALL close(9) > > 99921 python3.10 RET close 0 > > 99921 python3.10 CALL > > mmap(0,0x1000,0x3,0x1002,-1,0) > > 99921 python3.10 RET mmap 17308774350848/0xfbe0358c000 > > 99921 python3.10 CALL issetugid() > > 99921 python3.10 PSIG SIGSEGV SIG_DFL code=SEGV_ACCERR addr=0xfbdbb54cfcb > > trapno=0 > > > > I can share the full ktrace. egdb only shows a ?? traceback. Should I > > try building the debug package for it? Last time I tried it with Gajim > > it didn't provide much information as lot of things happened in > > libraries. > > > > Lucas > > >
Re: incorrect pledge error report
When a syscall is denied, pledge cannot reverse map the required promise.
It is not possible. Think about it for a bit.
It is best effort. It helps 95% of the developers. When you get close
to ioctl, there is no plausible way to say what promise is required.
cho...@jtan.com wrote:
> I decided late in an application's life to start using pledge, so
> I put a call in at the top and started running it and adding the
> requirements reported by dmesg on each iteration.
>
> Eventually it reported that the tty promise was breached so I added
> that and it reported again that the tty promise was breached.
>
> From GDB the relevant part of the stack trace is:
>
> (gdb) bt
> #0 ioctl () at /tmp/-:2
> #1 0x606521cbcd89301f in ?? ()
> #2 0x03089d94d4a2 in drmGetVersion (fd=8) at
> /usr/xenocara/lib/libdrm/mk/libdrm/../../xf86drm.c:708
> #3 0x0308b1d3b7e1 in loader_get_driver_for_fd (fd=8) at
> /usr/xenocara/lib/mesa/mk/libloader/../../src/loader/loader.c:108
> #4 0x0308b1d02ed6 in dri3_create_screen (screen=0, priv=Unhandled
> dwarf expression opcode 0xa3) at
> /usr/xenocara/lib/mesa/mk/libGL/../../src/glx/dri3_glx.c:829
> #5 0x0308b1cf5956 in __glXInitialize (dpy=0x3083034c000) at
> /usr/xenocara/lib/mesa/mk/libGL/../../src/glx/glxext.c:800
> #6 0x0308b1d080a5 in glXQueryVersion (dpy=Unhandled dwarf expression
> opcode 0xa3) at /usr/xenocara/lib/mesa/mk/libGL/../../src/glx/glxcmds.c:483
>
> loader_get_driver_for_fd is calling:
>
> drmVersionPtr version = drmGetVersion(fd);
>
> xf86drm.c at line 708 is in drmIoctl which I presume is the result
> of some preprocessor magic, calling:
>
> ret = ioctl(fd, request, arg);
>
> dmesg reports (many times with different PID, same syscall):
>
> turtle[32350]: pledge "tty", syscall 54
>
> Clearly pledge is correct: whatever 'request' has this ioctl doing
> doesn't use the tty promise (fd is probably the X connection). The
> problem here is the error report in dmesg that the breach is in
> something which is already included in the list of promises ("stdio
> inet unix rpath recvfd tty", NULL).
>
> I shall continue investigating to get my application to work and
> follow up if I find anything useful but I hope this is enough
> information for somebody familiar with the implementation of pledge
> to quickly figure out where its, or my, misunderstanding is.
>
> Cheers,
>
> Matthew
>
Re: External display doesn't work (start?) anymore
Please stop sending bug reports as images. I am pretty much deleting all bug reports from you because they show no effort on your part. Kirill A. Korinsky wrote: > Meanwhile I'd like to add that seems another bug. > > I attach two pictures to this message. > 1. is screenshot of some corner of the screen; > 2. is a picture taken by phone (well, I need to clean it, yeah). > > As you may see (2) contians some arifacts which is a real element of UI of > Telegram Desktop on antoher virtual screen. I've tried to move the screen, > but doesn't remove an artifact. > > Reboot helps. Disconnect doesn't. > > Thus, artifcat appears only after > > drm:pid76201:drm_atomic_helper_wait_for_flip_done *ERROR* [drm] *ERROR* > [CRTC:51:pipe A] flip_done timed out > > before it, no artifact. > > -- > wbr, Kirill
Re: amd64 boot reordering warning
No, you can ignore this "warning". It is unimportant and temporary. Jacqueline Jolicoeur wrote: > >Synopsis:amd64 boot reordering warning > >Category:boot > >Environment: > System : OpenBSD 7.5 > Details : OpenBSD 7.5-beta (GENERIC.MP) #25: Sat Feb 24 20:50:14 > MST 2024 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > >Description: > reordering: ld.sold: warning: _dl_start: missing endbr64 libcld: > warning: __mcount: missing endbr64 libcrypto sshd. > >How-To-Repeat: > # reboot > # dmesg -s > >Fix: > Revert to amd64 snapshot 2024-02-23 >
Re: unveil on MFS
Christian Weisgerber wrote: > Theo de Raadt: > > > Is it mfs specific -- or is it anytime there are layered mountpoints? > > Layered mountpoints, it turns out. I can reproduce it by mounting > another FFS over /usr/obj. I suspect unveil isn't aware of this situation and caches the first mount.
Re: unveil on MFS
Stuart Henderson wrote: > On 2024/02/19 23:00, hahahahacker2009 wrote: > > I cannot reproduce the problem with your code > > If I mount an MFS /usr/obj *over the top* of an existing FFS /usr/obj > then I can reproduce it, but not with MFS mounted on /mnt, /mnt/1, /usr/obj/1 Is it mfs specific -- or is it anytime there are layered mountpoints?
Re: bwfm: no rx after changing lladdr
Yes, the normal pattern is to update the driver soft state, and
then do perform a backside "down / up" transition.
Stefan Sperling wrote:
> On Sat, Feb 17, 2024 at 06:27:40PM -1000, Todd Carson wrote:
> >
> > On a Raspberry Pi 4 running a recent snapshot, I found that the built-in
> > bwfm interface would fail to receive non-broadcast traffic after
> > changing the MAC address with ifconfig (for example by having
> > "lladdr random" in hostname.bwfm0).
> >
> > It looks like this was happening because the new MAC address was set in
> > the kernel network stack but the bwfm driver wasn't doing anything
> > to write the address to the device.
> >
> > The below diff fixes it for me.
> > I don't have any other bwfm devices to test.
>
> An alternative approach is to memcpy the stack's MAC into ic_myaddr
> whenever the interface comes up. E.g. iwx does this in iwx_preinit():
>
> if (sc->attached) {
> /* Update MAC in case the upper layers changed it. */
> IEEE80211_ADDR_COPY(sc->sc_ic.ic_myaddr,
> ((struct arpcom *)ifp)->ac_enaddr);
> return 0;
> }
>
> This way the new value of ic_myaddr is propagated to firmware as
> part of the usual startup process.
>
> A possible problem with your approach is that the bwfm_fwvar_set_data()
> call might occur while the interface is still down and no firmware has
> been loaded. It looks like you handle this case by returning EIO, which
> means a hostname.bwfm0 file like the following would run into this I/O
> error on the first line during boot:
>
> lladdr random
> nwid foo wpakey bar
> inet autoconf
>
> With the approach taken by iwx(4) such files will work without errors
> and the random MAC will be set in the stack only at first, while being
> passed to the device when hardware comes up.
>
> > diff /usr/src
> > commit - 6c24eb55e021991196003dc7f0a643e806b14295
> > path + /usr/src
> > blob - dfa7a1973d2ab6be7e4b2fbd869b38c441d4eae0
> > file + sys/dev/ic/bwfm.c
> > --- sys/dev/ic/bwfm.c
> > +++ sys/dev/ic/bwfm.c
> > @@ -827,6 +827,17 @@ bwfm_ioctl(struct ifnet *ifp, u_long cmd, caddr_t data
> > error = 0;
> > }
> > break;
> > + case SIOCSIFLLADDR:
> > + ifr = (struct ifreq *)data;
> > + error = 0;
> > + if (bwfm_fwvar_var_set_data(sc, "cur_etheraddr",
> > + ifr->ifr_addr.sa_data, ETHER_ADDR_LEN)) {
> > + error = EIO;
> > + } else {
> > + memcpy(ic->ic_myaddr, ifr->ifr_addr.sa_data,
> > + sizeof(ic->ic_myaddr));
> > + }
> > + break;
> > case SIOCGIFMEDIA:
> > case SIOCG80211NODE:
> > case SIOCG80211ALLNODES:
> >
> >
>
Re: Small bug in /usr/src/distrib/riscv64/ramdisk/Makefile?
There is no bug. The distrib directory requires building inside a "full snapshot build" sequence. Workaround shortcuts can done to make it work, but I will not be adding workarounds inside the tree to encourage shorcuts, because they will encourage other fragile breakage. libstubs has dependencies upon fresh build and relatioship to /usr/obj that you aren't seeing. Peter J. Philipp wrote: > kn@: I will take a look at my earlier bug report with the RISCV disk > encryption > bug in the installer. > > Right now I have installed OpenBSD/riscv64 on my Mango Pi. Thank you very > much OpenBSD! This is a great effort making this mango pi work! > > I found that I needed a new kernel to detect the sd/mmc tf cards. So I > went about making a new ramdisk with /usr/src/distrib/riscv64/ramdisk/ > > I noticed that there is a problem with libstubs in this process from a > "vanilla" riscv64 build box. It will error out. The work around is to > go into /usr/src/distrib/special/libstubs and manually make it there, where > it gets ranlib'ed. Then go back to the former path and continue making the > ramdisk. > > Wanted to let you know this. Dmesg follows: > > > OpenBSD 7.4-current (MANGOPI) #0: Fri Feb 16 16:32:50 CET 2024 > p...@stern.delphinusdns.org:/sys/arch/riscv64/compile/MANGOPI > real mem = 1073741824 (1024MB) > avail mem = 1008390144 (961MB) > SBI: OpenSBI v1.3, SBI Specification Version 1.0 > random: good seed from bootblocks > mainbus0 at root: MangoPi MQ Pro > cpu0 at mainbus0: T-Head arch 0 imp 0 rv64imafdc > intc0 at cpu0 > cpu0: 32KB 64b/line 128-way L1 I-cache, 32KB 64b/line 256-way L1 D-cache > "fit-images" at mainbus0 not configured > "dcxo-clk" at mainbus0 not configured > simplebus0 at mainbus0: "soc" > sxipio0 at simplebus0: 88 pins > sxiccmu0 at simplebus0 > plic0 at simplebus0 > sxitimer0 at simplebus0: 24000 kHz > sxidog0 at simplebus0 > com0 at simplebus0: dw16550 > com0: console > com1 at simplebus0: dw16550 > "syscon" at simplebus0 not configured > "dma-controller" at simplebus0 not configured > "efuse" at simplebus0 not configured > "crypto" at simplebus0 not configured > "dram-controller" at simplebus0 not configured > sximmc0 at simplebus0 > sdmmc0 at sximmc0: 4-bit, sd high-speed, mmc high-speed, dma > sximmc1 at simplebus0 > sdmmc1 at sximmc1: 4-bit, sd high-speed, mmc high-speed, dma > "usb" at simplebus0 not configured > "phy" at simplebus0 not configured > ehci0 at simplebus0 > usb0 at ehci0: USB revision 2.0 > uhub0 at usb0 configuration 1 interface 0 "Generic EHCI root hub" rev > 2.00/1.00 addr 1 > ohci0 at simplebus0: version 1.0 > "clock-controller" at simplebus0 not configured > "mixer" at simplebus0 not configured > "mixer" at simplebus0 not configured > "phy" at simplebus0 not configured > "tcon-top" at simplebus0 not configured > "lcd-controller" at simplebus0 not configured > "lcd-controller" at simplebus0 not configured > "power-controller" at simplebus0 not configured > "clock-controller" at simplebus0 not configured > sxirtc0 at simplebus0 > sxidog1 at simplebus0 > sxidog2 at simplebus0 > gpio0 at sxipio0: 32 pins > gpio1 at sxipio0: 32 pins > gpio2 at sxipio0: 32 pins > gpio3 at sxipio0: 32 pins > gpio4 at sxipio0: 32 pins > gpio5 at sxipio0: 32 pins > gpio6 at sxipio0: 32 pins > usb1 at ohci0: USB revision 1.0 > uhub1 at usb1 configuration 1 interface 0 "Generic OHCI root hub" rev > 1.00/1.00 addr 1 > "opp-table-cpu" at mainbus0 not configured > "pmu" at mainbus0 not configured > "vcc" at mainbus0 not configured > "vcc-3v3" at mainbus0 not configured > "leds" at mainbus0 not configured > "avdd2v8" at mainbus0 not configured > "dvdd" at mainbus0 not configured > "vdd-cpu" at mainbus0 not configured > "wifi-pwrseq" at mainbus0 not configured > "binman" at mainbus0 not configured > scsibus0 at sdmmc0: 2 targets, initiator 0 > sd0 at scsibus0 targ 1 lun 0: removable > sd0: 30436MB, 512 bytes/sector, 62333952 sectors > manufacturer 0x024c, product 0xd723 at sdmmc1 function 1 not configured > uhub2 at uhub0 port 1 configuration 1 interface 0 "vendor 0x1a40 USB 2.0 Hub" > rev 2.00/1.11 addr 2 > ure0 at uhub2 port 4 configuration 1 interface 0 "Realtek USB 10/100 LAN" rev > 2.10/20.00 addr 3 > ure0: RTL8152 (0x4c10), address 00:e0:4c:36:00:e9 > rlphy0 at ure0 phy 0: RTL8201E 10/100 PHY, rev. 2 > vscsi0 at root > scsibus1 at vscsi0: 256 targets > softraid0 at root > scsibus2 at softraid0: 256 targets > root on sd0a (ff09abc802626de6.a) swap on sd0b dump on sd0b > sxiccmu_d1_set_frequency: 0x0084 > cpu0: clock not implemented > > > Thanks and best regards! > -pjp > > - > Note: My signature has changed. >
Re: cu hw.ucomnames / cu.c 1.29 problem
So everyone I should commit both diffs?
Re: cu hw.ucomnames / cu.c 1.29 problem
Kenneth Westerback wrote:
> Looks correct to me. The value returned by get_ucomnames() is only
> passed to find_ucom() where it is checked against NULL.
Alternative diff in the kernel, *in addition* to the other diff.
On a ucom-supporting kernel, if there are no matching devices the
sysctl returns the empty string.
The correct value for the sysctl node should be "no ucom translations
information".
So lack of support should return the empty string, not EINVAL. From
sysctl(2), EINVAL means either of these two conditions:
[EINVAL] The name array is less than two or greater than
CTL_MAXNAME.
[EINVAL] A non-null newp pointer is given and its specified
length in newlen is too large or too small.
Neither of them apply. It's a made-up errno. Maybe some other error
would be more suitable, but empty string works just as well.
Compile tested on GENERIC and RAMDISK, I did not try more than that.
Index: kern_sysctl.c
===
RCS file: /cvs/src/sys/kern/kern_sysctl.c,v
diff -u -p -u -r1.424 kern_sysctl.c
--- kern_sysctl.c 19 Jan 2024 01:43:27 - 1.424
+++ kern_sysctl.c 10 Feb 2024 03:39:16 -
@@ -771,14 +771,13 @@ hw_sysctl(int *name, u_int namelen, void
case HW_ALLOWPOWERDOWN:
return (sysctl_securelevel_int(oldp, oldlenp, newp, newlen,
&allowpowerdown));
-#if NUCOM > 0
case HW_UCOMNAMES: {
- const char *str = sysctl_ucominit();
- if (str == NULL)
- return EINVAL;
+ const char *str = "";
+#if NUCOM > 0
+ str = sysctl_ucominit();
+#endif /* NUCOM > 0 */
return (sysctl_rdstring(oldp, oldlenp, newp, str));
}
-#endif /* NUCOM > 0 */
#ifdef __HAVE_CPU_TOPOLOGY
case HW_SMT:
return (sysctl_hwsmt(oldp, oldlenp, newp, newlen));
Re: cu hw.ucomnames / cu.c 1.29 problem
Yes, this code should not fail in that circumstance. It should silently
carry on.
Note the code:
#if NUCOM > 0
case HW_UCOMNAMES: {
If the kernel has no USB com, the sysctl code is disabled. That is why
it MUST silently carry on.
But your bug report is incomplete. Where is the full dmesg for the machine
where this happened?
Probably this diff.
Index: cu.c
===
RCS file: /cvs/src/usr.bin/cu/cu.c,v
diff -u -p -u -r1.30 cu.c
--- cu.c21 Dec 2023 11:25:38 - 1.30
+++ cu.c10 Feb 2024 02:37:32 -
@@ -488,13 +488,13 @@ get_ucomnames(void)
size = 0;
for (;;) {
if (sysctl(mib, 2, NULL, &size, NULL, 0) == -1 || size == 0)
- err(1, "hw.ucomnames");
+ return NULL;
if ((names = realloc(names, size)) == NULL)
err(1, NULL);
if (sysctl(mib, 2, names, &size, NULL, 0) != -1)
break;
if (errno != ENOMEM)
- err(1, "hw.ucomnames");
+ return NULL;
}
return names;
}
The code that uses the return value from get_ucomnames() may be safe.
I'm rushed, don't want to burn dinner.
aphekz wrote:
> hi
>
> ~ > cu -l cua00 -s 115200
> (on -stable) quits with an error
> cu: hw.ucomnames: Operation not supported
>
> as there is only
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> and no any ucom devices on that machine
>
> so as below there is no hw.ucomnames value
> ~ > sysctl hw.ucomnames
> sysctl: hw.ucomnames: value is not available
>
> seems one of last changes
> src/usr.bin/cu/cu.c 2023/10/02 1.29
>
> in
> char *
> get_ucomnames(void)
> ...
> if (sysctl(mib, 2, NULL, &size, NULL, 0) == -1 || size == 0)
> err(1, "hw.ucomnames");
>
> makes problem in my case.
>
> shouldn't we have
> - err(1, "hw.ucomnames");
> + break;
>
> as i'm not experienced enough to suggest diff (i might be missing sth)
> so.. verify that please.
>
> aphekz
>
Re: potential buffer overflow in usr.sbin/tcpdump/print-gre.c
Jose Maldonado wrote: > El Fri, 02 Feb 2024 08:54:58 -0700 > "Theo de Raadt" escribió: > > tcpdump will *NEVER* be updated to newer code, because our tcpdump is > > a significant rewrite for privsep. The upstream tcpdump developers > > don't understand what privsep is. > > > > This means the parsers are run without any permissions. They should > > still be correct (so someone will look at this diff), but exploitation > > of bugs, beyond a boring crash, is exceedingly difficult. > > > > As Theo says, the implementation of tcpdump in OpenBSD is completely > different and the checks performed on the functions pointed by the > commits are treated differently due to privsep on OpenBSD. No, that's incorrect. Buffer mismanagement is still serious, and needs to be fixed. It just isn't as serious a crisis, because of the layered defense. There's another thing going on. The range checks mechanisms are slightly different. I've punted this to the experts in our group.
Re: potential buffer overflow in usr.sbin/tcpdump/print-gre.c
tcpdump will *NEVER* be updated to newer code, because our tcpdump is a significant rewrite for privsep. The upstream tcpdump developers don't understand what privsep is. This means the parsers are run without any permissions. They should still be correct (so someone will look at this diff), but exploitation of bugs, beyond a boring crash, is exceedingly difficult.
Re: smtpd segfault when starting with hostname "localhost"
Todd C. Miller wrote: > This looks like fallout from the changes in localhost handling in > the resolver. It seems strange for getaddrinfo() to return success > but not set res->ai_canonname when AI_CANONNAME is specified. Setting the actual hostname to "localhost" probably SHOULD result in some extremely negative experiences, but not crashes.
Re: netstart fails to parse complex wpa2 passphrases
What you are asking for is too difficult to do. netstart is a shell script. shell script arguments are not 8 bit clean, because the the sh language has many meta & escape characters. Your configuration exceeds what can be done.
Re: vxlan(4) custom destination UDP port seems not working
David Gwynne wrote: > On Wed, Nov 15, 2023 at 06:13:15AM -0700, Theo de Raadt wrote: > > Luca Di Gregorio wrote: > > > > > I'm not sure about this, but I think that public cloud datacenters filter > > > out > > > (or do something with) udp traffic to standard udp vxlan port. > > > > But that would not be a reason for allowing selection of the pre-standard > > port number. > > > > Rather, it would be a reason for provididing *any non-standard port number* > > > > Which is perhaps what the code does. But noone would actually want this. > > VXLAN on port 54? 80? Noone would want this. > > > > And if they filter it, then put it inside an underlay. The standard says > > nothing about permitting vxlan on any old random stupid port number. > > from a quick look around it appears that at least linux, juniper and > arista allow for the configuration of a non-standard port for vxlan. > linux documentation even says it defaults to the pre-iana assigned port > because their driver pre dates the standard, which is peak linux. > > independent of whether our vxlan(4) driver should support it or not, > ifconfig should be fixed to handle setting up sockaddrs for these > ioctls better anyway. OK, I am convinced.
Re: nmap sendto in send_ip_packet_sd: sendto => Permission denied
If you check in your syslog (or console), you will probably see a message telling you that build_udp_raw() has performed an 'backwards memcpy' which is not allowed because the result is undefined, therefore we check for this and then log + abort. this code should be using memmove(). Rafael Sadowski wrote: > I stumbled across the following. Maybe only our nmap port is broken. > > $ doas nmap -vvv -sU -sT google.de > Starting Nmap 7.91 ( https://nmap.org ) at 2023-11-16 21:28 CET > Warning: Hostname google.de resolves to 2 IPs. Using 142.250.74.195. > Initiating Ping Scan at 21:28 > Scanning google.de (142.250.74.195) [4 ports] > sendto in send_ip_packet_sd: sendto(4, packet, 40, 0, 142.250.74.195, 16) => > Permission denied > Offending packet: TCP 10.0.23.5:58160 > 142.250.74.195:80 A ttl=39 id=51533 > iplen=40 seq=0 win=1024 > Completed Ping Scan at 21:28, 0.01s elapsed (1 total hosts) > Initiating Parallel DNS resolution of 1 host. at 21:28 > Completed Parallel DNS resolution of 1 host. at 21:28, 0.00s elapsed > DNS resolution of 1 IPs took 0.01s. Mode: Async [#: 1, OK: 1, NX: 0, DR: 0, > SF: 0, TR: 1, CN: 0] > Initiating UDP Scan at 21:28 > Scanning google.de (142.250.74.195) [1000 ports] > zsh: abort (core dumped) doas nmap -vvv -sU -sT google.d > > Tested on: > dmesg|head > OpenBSD 7.4-current (GENERIC.MP) #16: Fri Nov 3 21:38:55 MDT 2023 > dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP > real mem = 8432713728 (8042MB) > avail mem = 8137003008 (7760MB) > random: good seed from bootblocks > mainbus0 at root: Raspberry Pi 4 Model B Rev 1.4 > psci0 at mainbus0: PSCI 1.1, SMCCC 1.2 > efi0 at mainbus0: UEFI 2.7 > efi0: https://github.com/pftf/RPi4 rev 0x1 > smbios0 at efi0: SMBIOS 3.3.0 > > and > > OpenBSD 7.4-current (GENERIC.MP) #1447: Wed Nov 15 09:56:54 MST 2023 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 34026549248 (32450MB) > avail mem = 32975663104 (31448MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.4 @ 0x8dfda000 (81 entries) > bios0: vendor LENOVO version "N3AET77W (1.42 )" date 09/21/2023 > > backtrace: > > #1 0x010a3cca7262 in _libc_abort () at > /usr/src/lib/libc/stdlib/abort.c:51 > #2 0x010a3ccfdda3 in memcpy (dst0=, src0=, > length=) at /usr/src/lib/libc/string/memcpy.c:74 > #3 0x01078eaf3ddd in build_udp_raw(in_addr const*, in_addr const*, int, > unsigned short, unsigned char, bool, unsigned char*, int, unsigned short, > unsigned short, char const*, unsigned short, unsigned int*) () > #4 0x01078eadcc3e in sendIPScanProbe(UltraScanInfo*, HostScanStats*, > probespec const*, unsigned char, unsigned char) () > #5 0x01078ead6601 in ultra_scan(std::__1::vector std::__1::allocator >&, scan_lists*, stype, timeout_info*) () > #6 0x01078eaa5554 in nmap_main(int, char**) () > #7 0x01078ea7c1a1 in _start () >
Re: vxlan(4) custom destination UDP port seems not working
Luca Di Gregorio wrote: > I'm not sure about this, but I think that public cloud datacenters filter out > (or do something with) udp traffic to standard udp vxlan port. But that would not be a reason for allowing selection of the pre-standard port number. Rather, it would be a reason for provididing *any non-standard port number* Which is perhaps what the code does. But noone would actually want this. VXLAN on port 54? 80? Noone would want this. And if they filter it, then put it inside an underlay. The standard says nothing about permitting vxlan on any old random stupid port number.
Re: vxlan(4) custom destination UDP port seems not working
Stuart Henderson wrote: > On 2023/11/15 05:59, Theo de Raadt wrote: > > Otto Moerbeek wrote: > > > > > On Wed, Nov 15, 2023 at 12:42:46PM +0100, Luca Di Gregorio wrote: > > > > > > > # uname -a > > > > OpenBSD X.my.domain 7.4 GENERIC#0 amd64 > > > > > > > > # ifconfig vxlan0 tunnel SOURCE_IP DEST_IP:8472 vnetid 5 > > > > # ifconfig vxlan0 inet 192.168.5.1/30 > > > > # ifconfig vxlan0 up > > > > > > > > # ifconfig vxlan0: I can't see the dest UDP port 8472 anywhere > > > > vxlan0: flags=8843 mtu 1500 > > > > lladdr fe:e1:ba:d9:e4:0b > > > > index 18 llprio 3 > > > > encap: vnetid 5 parent none txprio 0 rxprio outer > > > > groups: vxlan > > > > tunnel: inet SOURCE_IP --> DEST_IP ttl 1 nodf > > > > Addresses (max cache: 100, timeout: 240): > > > > inet 192.168.5.1 netmask 0xfffc broadcast 192.168.5.3 > > > > > > > > # ping 192.168.5.2 > > > > > > > > In tcpdump, I see that arp packets are sent to UDP port 4789, not 8472: > > > > SOURCE_IP.4789 > DEST_IP.4789: VXLAN vni 5: arp who-has 192.168.5.2 > > > > tell > > > > 192.168.5.1 [ttl 1] > > > > > > > > Is this a bug? > > > > > > It helps to read the vxlan(4) manpage, specifcially the paragraph abouts > > > ports. > > > > Is there any reason to allow people to use non-standard ports? Equipment > > that > > does this is rare. > > pre-RFC implementations used 8472 That doesn't answer the question. I checked all the devices i have, none of them can do 8472. So they must be very rare. Why does OpenBSD need to interop with them?
Re: vxlan(4) custom destination UDP port seems not working
Otto Moerbeek wrote: > On Wed, Nov 15, 2023 at 12:42:46PM +0100, Luca Di Gregorio wrote: > > > # uname -a > > OpenBSD X.my.domain 7.4 GENERIC#0 amd64 > > > > # ifconfig vxlan0 tunnel SOURCE_IP DEST_IP:8472 vnetid 5 > > # ifconfig vxlan0 inet 192.168.5.1/30 > > # ifconfig vxlan0 up > > > > # ifconfig vxlan0: I can't see the dest UDP port 8472 anywhere > > vxlan0: flags=8843 mtu 1500 > > lladdr fe:e1:ba:d9:e4:0b > > index 18 llprio 3 > > encap: vnetid 5 parent none txprio 0 rxprio outer > > groups: vxlan > > tunnel: inet SOURCE_IP --> DEST_IP ttl 1 nodf > > Addresses (max cache: 100, timeout: 240): > > inet 192.168.5.1 netmask 0xfffc broadcast 192.168.5.3 > > > > # ping 192.168.5.2 > > > > In tcpdump, I see that arp packets are sent to UDP port 4789, not 8472: > > SOURCE_IP.4789 > DEST_IP.4789: VXLAN vni 5: arp who-has 192.168.5.2 tell > > 192.168.5.1 [ttl 1] > > > > Is this a bug? > > It helps to read the vxlan(4) manpage, specifcially the paragraph abouts > ports. Is there any reason to allow people to use non-standard ports? Equipment that does this is rare.
Re: installer should work around ocsp failure
> It occurred to me later maybe the clock was off? Oh now people want a ntp client on the installer??!?! The independent relationships are getting really ridiculous.
Re: installer should work around ocsp failure
Ted Unangst wrote: > As of this moment, one of the cdn mirrors doesn't work with the installer. > Whichever lucky one I landed on. > > TLS handshake failure: ocsp verify failed: ocsp response not current > > This is annoying, and it's not easy to fix while in the installer. > > If the cert has not actually expired (or even if it has), we're not relying > on https for integrity here, so this shouldn't be a fatal error. That's very surprising, because cdn.openbsd.org is fastly. Please be more specific, IP address, etc.
Re: Crash on TOSHIBA PORTEGE Z30-A laptop
Mike Larkin wrote: > On Sat, Oct 21, 2023 at 01:27:21PM +0400, wes...@technicien.io wrote: > > Hi Philip, > > > > Thank you very much for your answer. > > > > I tried to disable all options (+devices) possible. Same issue. > > And what's about disable acpi in the kernel using the bsd.re-config? > > > > Not advisable. You'll probably end up causing even more problems. You mean, like > disable acpi* Meaning, using a glob, which is a lot like a regular expression. Are you not aware of the wise words on the internet about 'and now you have two problems'? Anytime anyone says 'disable acpi', they should be corrected. The correct command is 'disable pci'. Trust me.
Re: `man backtrace` should name the required linker flag (`-lexecinfo`)
> The project would be better off if you weren't so abrasive to folks > that honestly want to help things and have real user feedback. I get > that you may not care, but it is sad to witness. No, really, you are the one took it abrasive. I replied with my THOUGHTFUL perpective on why the manual pages don't need to have this information. I made an technical argument about minimalism. But you called it a hill! You made a personal judgement. You were the one to use the word "foolish". You were the one who made it personal. So get lost, immediately. Get the hell out of here. We don't need crybabys like you around here who convert TECHNICAL discussions into that kind of garbage. AND DON'T COME BACK. Re-including Christoff's whole email to show it for what it is: --- > Christoff Humphries christoff@deadbeef.monster wrote: > > > > Marc Espie marc.espie.open...@gmail.com wrote: > > > > > > > On Mon, Oct 09, 2023 at 01:58:27PM +1100, Jonathan Gray wrote: > > > > > > > > > > So tldr: `man backtrace` should name the required linker flag > > > > > > (-lexecinfo) > > > > > > > > > > from mdoc(7): > > > > > > > > > > .\" .Sh LIBRARY > > > > > .\" For sections 2, 3, and 9 only. > > > > > .\" Not used in OpenBSD. > > > > > > > > > > note about it not being used added by jmc@ in 2010 > > > > > > > > > > Only use in base is in libelf. > > > > > > > > Independently of using LIBRARY or not, functions not in libc > > > > should probably mention the library somewhere in the manpage ? > > > > > > It is really surprisingly that programming society managed to get by for > > > decades and build an incredible number of things without these details. > > > Wow. > > > > > > What really happened is the people (or person) who needs to find what > > > they needs to find, always finds it really damn quickly because it is > > > already domain-knowledge in the area they are working, they edit a > > > Maefile, and carry on. Once it is encoded into the Makefile ,note it is > > > usually the same value on every operating system and if it isn't we all > > > know make(1) doesn't read manual pages. That Makefile gets copied > > > around to other systems. People pass on the domain knowledge > > > organically. > > > > > > There's really no drama here. > > > > > > However, adding 3 lines (including the blank) to a ton of manuals, that > > > is drama. Because obviously there'll need to be a Task Force to go on > > > this Mission and splatter the shit everywhere. > > > > > > This is not like lines describing #include files, because those are > > > different for every function in every manual page. > > > > > > So I personally think it is a fools errand. > > > > So because it has always been done that way and people got by then it > > is not worth it to document development manual pages for developers > > with pertinent information they would need for development? That seems > > like a foolish argument and logic, and perhaps the worst anti-pattern. > > > > But this isn't my circus. Seems an odd hill to stand on. > > > Then why are you standing on that hill? You win, Theo. You win. Enjoy your winning. It's sad, man. It's true. No one has to use OpenBSD, as you're well at helping make happen when attacking people's valid arguments on your mailing lists. We're all not worthy of having assertions that disagree with you? It's sad. A community exists for every software project and it is sad when you tend to opt for attacking folks with sarcasm and talking down to folks. You have a choice of how to respond and it seems you choose poorly often, giving an impression that folks are not worthy to even have an opinion and push people away. Perhaps you do not care, I don't know, but damn it is abrasive. I thought you lightened up over the years. I was wrong. Like many others, just going to leave the mailing lists and use OpenBSD selfishly than participate in any capacity. Living in a silo seems to be the preferred method here, I thought the Unix world has progressed past that, especially in OpenBSD. The project would be better off if you weren't so abrasive to folks that honestly want to help things and have real user feedback. I get that you may not care, but it is sad to witness. I was excited to dive in and use and contribute to the project, and you are so good at destroying any energy to that end. And I've heard it from others all the same. It's sad because it is completely preventable if you'd just consider your replies aren't constructive but push people away. Anyway, you're the boss here. I can't say anything about it. Enjoy the silo life, it seems to be working for you. Just sucks for anyone that you don't agree with. I'm done. Won't get another cent or advocacy from me again. But I'm sure you could not care about that either. In the end you won. Enjoy.
Re: `man backtrace` should name the required linker flag (`-lexecinfo`)
Oh you hurt my feelings. However, I am glad you got that off your chest. Christoff Humphries wrote: > > > --- Original Message --- > On Monday, October 9th, 2023 at 12:16 PM, Theo de Raadt > wrote: > > > > > > Christoff Humphries christoff@deadbeef.monster wrote: > > > > > > Marc Espie marc.espie.open...@gmail.com wrote: > > > > > > > > > On Mon, Oct 09, 2023 at 01:58:27PM +1100, Jonathan Gray wrote: > > > > > > > > > > > > So tldr: `man backtrace` should name the required linker flag > > > > > > > (-lexecinfo) > > > > > > > > > > > > from mdoc(7): > > > > > > > > > > > > .\" .Sh LIBRARY > > > > > > .\" For sections 2, 3, and 9 only. > > > > > > .\" Not used in OpenBSD. > > > > > > > > > > > > note about it not being used added by jmc@ in 2010 > > > > > > > > > > > > Only use in base is in libelf. > > > > > > > > > > Independently of using LIBRARY or not, functions not in libc > > > > > should probably mention the library somewhere in the manpage ? > > > > > > > > It is really surprisingly that programming society managed to get by for > > > > decades and build an incredible number of things without these details. > > > > Wow. > > > > > > > > What really happened is the people (or person) who needs to find what > > > > they needs to find, always finds it really damn quickly because it is > > > > already domain-knowledge in the area they are working, they edit a > > > > Maefile, and carry on. Once it is encoded into the Makefile ,note it is > > > > usually the same value on every operating system and if it isn't we all > > > > know make(1) doesn't read manual pages. That Makefile gets copied > > > > around to other systems. People pass on the domain knowledge > > > > organically. > > > > > > > > There's really no drama here. > > > > > > > > However, adding 3 lines (including the blank) to a ton of manuals, that > > > > is drama. Because obviously there'll need to be a Task Force to go on > > > > this Mission and splatter the shit everywhere. > > > > > > > > This is not like lines describing #include files, because those are > > > > different for every function in every manual page. > > > > > > > > So I personally think it is a fools errand. > > > > > > So because it has always been done that way and people got by then it > > > is not worth it to document development manual pages for developers > > > with pertinent information they would need for development? That seems > > > like a foolish argument and logic, and perhaps the worst anti-pattern. > > > > > > But this isn't my circus. Seems an odd hill to stand on. > > > > > > Then why are you standing on that hill? > > You win, Theo. You win. Enjoy your winning. It's sad, man. > > It's true. No one has to use OpenBSD, as you're well at helping make > happen when attacking people's valid arguments on your mailing > lists. We're all not worthy of having assertions that disagree with > you? It's sad. A community exists for every software project and it is > sad when you tend to opt for attacking folks with sarcasm and talking > down to folks. > > You have a choice of how to respond and it seems you choose poorly > often, giving an impression that folks are not worthy to even have an > opinion and push people away. Perhaps you do not care, I don't know, > but damn it is abrasive. I thought you lightened up over the years. I > was wrong. Like many others, just going to leave the mailing lists and > use OpenBSD selfishly than participate in any capacity. > > Living in a silo seems to be the preferred method here, I thought the > Unix world has progressed past that, especially in OpenBSD. > > The project would be better off if you weren't so abrasive to folks > that honestly want to help things and have real user feedback. I get > that you may not care, but it is sad to witness. > > I was excited to dive in and use and contribute to the project, and > you are so good at destroying any energy to that end. And I've heard > it from others all the same. It's sad because it is completely > preventable if you'd just consider your replies aren't constructive > but push people away. > > Anyway, you're the boss here. I can't say anything about it. Enjoy > the silo life, it seems to be working for you. Just sucks for anyone > that you don't agree with. > > I'm done. Won't get another cent or advocacy from me again. But I'm > sure you could not care about that either. In the end you won. Enjoy. >
Re: `man backtrace` should name the required linker flag (`-lexecinfo`)
Christoff Humphries wrote: > > Marc Espie marc.espie.open...@gmail.com wrote: > > > > > On Mon, Oct 09, 2023 at 01:58:27PM +1100, Jonathan Gray wrote: > > > > > > > > So tldr: `man backtrace` should name the required linker flag > > > > > (-lexecinfo) > > > > > > > > from mdoc(7): > > > > > > > > .\" .Sh LIBRARY > > > > .\" For sections 2, 3, and 9 only. > > > > .\" Not used in OpenBSD. > > > > > > > > note about it not being used added by jmc@ in 2010 > > > > > > > > Only use in base is in libelf. > > > > > > Independently of using LIBRARY or not, functions not in libc > > > should probably mention the library somewhere in the manpage ? > > > > > > It is really surprisingly that programming society managed to get by for > > decades and build an incredible number of things without these details. > > Wow. > > > > What really happened is the people (or person) who needs to find what > > they needs to find, always finds it really damn quickly because it is > > already domain-knowledge in the area they are working, they edit a > > Maefile, and carry on. Once it is encoded into the Makefile ,note it is > > usually the same value on every operating system and if it isn't we all > > know make(1) doesn't read manual pages. That Makefile gets copied > > around to other systems. People pass on the domain knowledge > > organically. > > > > There's really no drama here. > > > > However, adding 3 lines (including the blank) to a ton of manuals, that > > is drama. Because obviously there'll need to be a Task Force to go on > > this Mission and splatter the shit everywhere. > > > > This is not like lines describing #include files, because those are > > different for every function in every manual page. > > > > So I personally think it is a fools errand. > > So because it has always been done that way and people got by then it > is not worth it to document development manual pages for developers > with pertinent information they would need for development? That seems > like a foolish argument and logic, and perhaps the worst anti-pattern. > > But this isn't my circus. Seems an odd hill to stand on. Then why are you standing on that hill?
Re: `man backtrace` should name the required linker flag (`-lexecinfo`)
Marc Espie wrote: > On Mon, Oct 09, 2023 at 01:58:27PM +1100, Jonathan Gray wrote: > > > So tldr: `man backtrace` should name the required linker flag (-lexecinfo) > > > > from mdoc(7): > > > > .\" .Sh LIBRARY > > .\" For sections 2, 3, and 9 only. > > .\" Not used in OpenBSD. > > > > note about it not being used added by jmc@ in 2010 > > > > Only use in base is in libelf. > > Independently of using LIBRARY or not, functions not in libc > should probably mention the library somewhere in the manpage ? It is really surprisingly that programming society managed to get by for decades and build an incredible number of things without these details. Wow. What really happened is the people (or person) who needs to find what they needs to find, always finds it really damn quickly because it is already domain-knowledge in the area they are working, they edit a Maefile, and carry on. Once it is encoded into the Makefile ,note it is usually the same value on every operating system and if it isn't we all know make(1) doesn't read manual pages. That Makefile gets copied around to other systems. People pass on the domain knowledge organically. There's really no drama here. However, adding 3 lines (including the blank) to a ton of manuals, that is drama. Because obviously there'll need to be a Task Force to go on this Mission and splatter the shit everywhere. This is not like lines describing #include files, because those are different for every function in every manual page. So I personally think it is a fools errand.
Re: [USB] Cirque Glidepoint bDescriptorType == 0
Cheap broken USB devices not following spec?? Tell me that isn't possible!
:-)
neirac wrote:
> I have a Cirque Corporation, USB GlidePoint, that's not working in 7.3.
> Checking the code I realized that this device is returning 0 as
> bDescriptorType, so I relaxed the error condition to just looked at the size.
> Is it common that devices don't return the expected UDES_DEVICE descriptor?.
> Maybe my understanding of this problem is incorrect, but after this change
> the mouse started working.
> here is the patch:
>
> Index: usb_subr.c
> ===
> RCS file: /cvs/src/sys/dev/usb/usb_subr.c,v
> retrieving revision 1.158
> diff -u -p -u -p -r1.158 usb_subr.c
> --- usb_subr.c16 Feb 2022 06:23:42 - 1.158
> +++ usb_subr.c6 Oct 2023 13:09:59 -
> @@ -1149,8 +1149,7 @@ usbd_new_device(struct device *parent, s
>dd->bDeviceProtocol, dd->bMaxPacketSize, dd->bLength,
>dev->speed));
>
> - if ((dd->bDescriptorType != UDESC_DEVICE) ||
> - (dd->bLength < USB_DEVICE_DESCRIPTOR_SIZE)) {
> + if (dd->bLength < USB_DEVICE_DESCRIPTOR_SIZE) {
> err = USBD_INVAL;
> goto fail;
> }
>
> --
> Devices:
>
> Controller /dev/usb0:
> addr 01: 1022: AMD, xHCI root hub
> addr 02: 041e:3042 Creative Technology, SB X-Fi Surround 5.1
> Controller /dev/usb1:
> addr 01: 1022: AMD, xHCI root hub
> Controller /dev/usb2:
> addr 01: 1022: AMD, EHCI root hub
> Controller /dev/usb3:
> addr 01: 1022: AMD, EHCI root hub
> Controller /dev/usb4:
> addr 01: 1022: AMD, OHCI root hub
> Controller /dev/usb5:
> addr 01: 1022: AMD, OHCI root hub
> addr 02: 058f:9254 ALCOR, Generic USB Hub
> addr 03: 05f3:0081 PI Engineering, Kinesis Keyboard Hub
> addr 04: 05f3:0007 P.I. Engineering, product 0x0007
> addr 05: 0461:4d22 Primax Electronics, USB Optical Mouse
> addr 06: 0488:0022 Cirque Corporation, USB GlidePoint
> addr 07: 2101:1407 D-Link, USB KVM
> Controller /dev/usb6:
> addr 01: 1022: AMD, OHCI root hub
>
> ---
> dmesg with kernel compiled with USB_DEBUG option
>
> OpenBSD 7.3-stable (TEST.MP) #14: Fri Oct 6 10:12:10 -03 2023
> nei...@litre.lan:/usr/src/sys/arch/amd64/compile/TEST.MP
> real mem = 7716323328 (7358MB)
> avail mem = 7463051264 (7117MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebe50 (50 entries)
> bios0: vendor American Megatrends Inc. version "V30.0" date 10/25/2013
> bios0: MSI MS-7721
> acpi0 at bios0: ACPI 5.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC FPDT MCFG HPET IVRS SSDT SSDT CRAT SSDT SSDT
> acpi0: wakeup devices SBAZ(S4) P0PC(S4) OHC1(S4) EHC1(S4) OHC2(S4) EHC2(S4)
> OHC3(S4) EHC3(S4) OHC4(S4) XHC0(S4) XHC1(S4) PE20(S4) PE21(S4) PE22(S4)
> PE23(S4) PB2_(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 16 (boot processor)
> cpu0: AMD A8-5600K APU with Radeon(tm) HD Graphics, 3593.52 MHz, 15-10-01
> cpu0:
> 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,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,TBM,TOPEXT,CPCTR,ITSC,BMI1
> cpu0: 16KB 64b/line 4-way D-cache, 64KB 64b/line 2-way I-cache, 2MB 64b/line
> 16-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 99MHz
> cpu0: mwait min=64, max=64, IBE
> cpu1 at mainbus0: apid 17 (application processor)
> cpu1: AMD A8-5600K APU with Radeon(tm) HD Graphics, 3593.56 MHz, 15-10-01
> cpu1:
> 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,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,TBM,TOPEXT,CPCTR,ITSC,BMI1
> cpu1: 16KB 64b/line 4-way D-cache, 64KB 64b/line 2-way I-cache, 2MB 64b/line
> 16-way L2 cache
> cpu1: smt 1, core 0, package 0
> cpu2 at mainbus0: apid 18 (application processor)
> cpu2: AMD A8-5600K APU with Radeon(tm) HD Graphics, 3593.65 MHz, 15-10-01
> cpu2:
> 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,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,TBM,TOPEXT,CPCTR,ITSC,BMI1
> cpu2: 16KB 64b/line 4-way D-cache, 64KB 64b/line 2-way I-cache,
Re: Consistent boot problem with video card needing a DP to HDMI adaptor and multiple attempts
Quoting you: "This condition exists without any hard drive or OS available." So apparently it has nothing to do with us. Please don't abuse our time. Chris Bennett wrote: > > > >Synopsis:Boot problems. DP needs conversion to HDMI to get anything on > >screen > >Category:system > >Environment: > System : OpenBSD 7.3 > Details : OpenBSD 7.3 (GENERIC.MP) #0: Wed Jul 12 05:09:49 MDT 2023 > > r...@syspatch-73-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > >Description: > I cannot boot or get anything on screen without converting a DP into an > HDMI with an appropriate adapter. > This condition exists without any hard drive or OS available. When I boot, it > may take multiple tries to get to a > boot select screen (which I have setup to be necessary and I have to hit F12 > to pull it up. I can kill the power > without a problem. Getting a BIOS screen with F2 is also sketchy. After > booting, I can either continue with HDMI > or switch to DP on the monitor. The onboard video is two DP ports only. I > have tried multiple DP to HDMI adaptors > until I found one that brings up the full card max resolution and refresh > rates. I am having more problems with > booting and I did have a full crash for the first time a few weeks ago. > Sometimes the BIOS Dell logo shows up > briefly. When this happens, it won't reach the boot select screen and needs > to be powered off. > I want to get this sent quickly. I will check for a newer BIOS update after > sending this bug report. I will ask > for advice on buying a video card that supports chromium browser unlike this > one on misc@. > >How-To-Repeat: > Try to boot, reboot or access BIOS. > >Fix: > Boot multiple tries until HDMI works and then there is usually no > problem. > This does not solve the problem but does allow booting successfully. > I suspect that adding in a different video card instead of using the > motherboard video will be the only fix. > > > dmesg: > OpenBSD 7.3 (GENERIC.MP) #0: Wed Jul 12 05:09:49 MDT 2023 > > r...@syspatch-73-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 34179473408 (32596MB) > avail mem = 33124167680 (31589MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec410 (93 entries) > bios0: vendor Dell Inc. version "A23" date 06/25/2018 > bios0: Dell Inc. OptiPlex 9020 > efi0 at bios0: UEFI 2.3.1 > efi0: American Megatrends rev 0x4028d > acpi0 at bios0: ACPI 5.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP APIC FPDT SLIC LPIT SSDT SSDT SSDT HPET SSDT MCFG > SSDT ASF! MSDM DMAR > acpi0: wakeup devices UAR1(S3) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) > PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) EHC2(S3) > XHC_(S4) HDEF(S4) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz, 3791.33 MHz, 06-3c-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,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 8-way L2 cache, 8MB 64b/line 16-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 99MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz, 3791.44 MHz, 06-3c-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,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 8-way L2 cache, 8MB 64b/line 16-way L3 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 4 (application processor) > cpu2: Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz, 3791.51 MHz, 06-3c-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,V
Re: flags & (M_WAITOK | M_NOWAIT) kern_malloc assertion
Rafael Sadowski wrote: > On Wed Jul 19, 2023 at 02:36:28PM -0600, Theo de Raadt wrote: > > Rafael Sadowski wrote: > > > > > I can reproduce the following panic: > > > > > > 1.) Boot > > > 2.) Start firefox (firefox-115.0.2) > > > 3.) zzz > > > 4.) resume and go to the window with firefox > > > 5.) panic: kernel diagnostic assertion "flags & (M_WAITOK | M_NOWAIT)" > > > failed: file "/usr/src/sys/kern/kern_malloc.c", line 176. > > > > > > What is interesting in the analysis. > > > > No, what is interesting is that upon seeing the panic, you did not collect a > > trace and provide it to us. > > > > That's interesting. And also sad. > > Because then I can't do anything. The whole system is frozen. Try turning off ddb.panic, and see if it helps you get a trace.
Re: flags & (M_WAITOK | M_NOWAIT) kern_malloc assertion
Rafael Sadowski wrote: > I can reproduce the following panic: > > 1.) Boot > 2.) Start firefox (firefox-115.0.2) > 3.) zzz > 4.) resume and go to the window with firefox > 5.) panic: kernel diagnostic assertion "flags & (M_WAITOK | M_NOWAIT)" > failed: file "/usr/src/sys/kern/kern_malloc.c", line 176. > > What is interesting in the analysis. No, what is interesting is that upon seeing the panic, you did not collect a trace and provide it to us. That's interesting. And also sad.
Re: could there be a breach of license in efiboot?
Your interpretation is not correct. It is often possible to find old terms and conditions replaced with newer terms and conditions. Intel moved away from foolishly restrictive terms and conditions around the time of the wireless device firmware licensing pressure
Re: kernel reordering happily consumes invalid objects
>So you personally vouch for the machine code in the official release not >containing any hidden surprises at present? I don't vouch for anything, I don't have to. If you don't like it go scuttle off to someone else who satisfies you. But your sha256 invocation is going to solve nothing. >By the way there is a bug in >the text of the FAQ for installing the xenocara source that clobbers usr >because it's missing a mkdir -p command for an expected directory. So file a bug report about it. Stop moving the goalposts. I'm done with you.
Re: kernel reordering happily consumes invalid objects
"Schech, C. W. (\"Connor\")" wrote: > I want to avoid derailing into trusting trust or designing a system > from scratch. The official build not being portable and the recursion > it introduces is orthogonal to system integrity.. Adding say, official > distcc support, and bringing back say, GCC avoids that recursion. I am > concerned with simple system integrity aspects and cross-build > contamination. SLS3 is the current buzzword framework for that, with > up-to-date terminology, if you think that adding checksums to objects > that are signed is just something I dreamt up that no one is thinking > or has thought about. I don't have money to pay a consulting firm to > develop a POSIX build script for me that I can run on a junk HP-UX > workstation and be "totally assured". We have signed checksums on the entire install. There is no need to revalidate them. If some attacker is going to attack the relink kit, they are going to attack the other 99.9% of the files also. Actually they are more likely to attack the other 99.9% of files because it is easier and more effective. You are afraid of 2nd and 3rd order problems. Solving that one little narrow problem of sha256 on .o files in a directory is not a step in the same direction as the buzzwords salad above.
Re: kernel reordering happily consumes invalid objects
What you are saying makes no sense.
So then the compiler runs to link these binaries, and you trust it?
Also, it is using various libraries, including libc.so, and you have
to trust those files? But those library routines in there trust all sorts
of other files also, to not be corrupted.
By extension, I guess you are saying you don't trust any file on the system.
And going only a tiny step further --- Who will sha256 the sha256 file?
Did you think about how you solve that?
I wish you luck designing your own system which overcomes all this vague
trusting trust "my root owned files might be corrupt"
OpenBSD is not that system.
"Schech, C. W. (\"Connor\")" wrote:
> I don't trust anyone upstream to keep the .o files safe - that's the
> central problem - the hardware reliability is an aside from the
> central problem, which is that you are creating a "virtual compiler"
> for arbitrary programs when you reorder the kernel, which shouldn't be
> a "general purpose compiler" like, for instance clang or gcc, but only
> one that can generate "OpenBSD binaries", so it needs a specification
> of what a "OpenBSD binary" is. The checksums just keep that
> specification abstract. Sorry if it's too theoretical. What a "OpenBSD
> binary" from a given release is modulo a given compiler is the
> reference objects that that compiler would generate from the source of
> the release. Keeping the compiler abstract, or opaque from the
> perspective of someone looking at the system as a whole.
>
> Talking about the compiler's correct properties is the inverse problem
> of the surface problem that you are trying to solve by reordering the
> kernel, which is on-line attacks against the entry points for each
> object that's linked into the final /bsd kernel binary, to do that and
> compute the entry points off-line you only need the lorder file (which
> contains the names and order of the objects), a sample /bsd binary,
> the reference object file names, and the size (in bytes) of each
> object.
>
> What I am suggesting is that the hardware only needs to keep safe the
> lorder file and the binary and the size and checksum of each object,
> and reorder_kernel can compute those without needing the orginal
> objects to be kept around, by rearranging opaque segments of the /bsd
> binary, purely at the link-level.
>
> What I am trying to express is that the compile and link phases that
> should always be separate are being intermixed, because (for now) with
> reference to the current generation of compilers and the current
> hardware there is a lack of typed assembly language or a typed
> intermediate representation (in the compiler) for the intermediate
> compilation objects, so anyone can slip things in by attacking the
> system at the object level, which is opaque from the linker's
> perspective, and should be from reorder_kernel's as well.
>
> As far as syspatch is concerned - that is probably the right
> abstraction to look at - what should syspatch and reorder_kernel
> support? Because right now it's possible for reorder_kernel to reorder
> any old program that you might have clang-output objects for and the
> right recipe for reordering them - I want to always ensure
> kernel_reorder is only reordering valid kernels with reference to what
> syspatch can also patch, in other words a "virtual compiler" for only
> syspatch, not arbitrary programs produced by a reference compiler.
> Keeping everything the relinker does strictly at the link-level
> satisfies that (logical) property, so that it can't be attacked
> trivially to patch the kernel surreptitiously, in other words a
> sanity-check of its input.
>
>
>
>
>
>
>
>
>
> On Wed, Jun 14, 2023 at 6:50 AM Stuart Henderson wrote:
> >
> > On 2023/06/14 04:12, Schech, C. W. ("Connor") wrote:
> > > There's no check of the checksums for all the object files that the
> > > /rc task consumes
> > >
> > > This can be trivially fixed by generating them in, say
> > >
> > > In /sys/conf/newvars.sh, add the line:
> > >
> > > +sha512 -h /var/db/obj.${id}.sha512 *.o lorder
> > >
> > > above the segment starting with:
> > >
> > > cat >vers.c < > >
> > > [...]
> > >
> > > then the right checksums always persist in /var/db on release or
> > > between builds, labelled with the {id}
> > >
> > > in /etc/rc or kernel_reorder, before invoking the kernel reordering
> > > routine, make a guard statement that checks that all the object
> > > checksums are OK, i.e.,
> >
> > How do you know the .o files from the build are ok in the first place?
> > If you don't trust your hardware to keep the installed copy safe, why
> > would the build be any different?
> >
> > > Also consider moving the relinking to "only at shutdown", so no other
> > > jobs are running concurrently in case that causes a random kernel
> > > fault due to extreme load on faulty hardware, and to make the boot
> > > time as fast as possible, since the relinked kernel isn't used until
> > > the boot after AFAIK.
> >
> > Consider
Re: On 2013-06-12 snapshot xfce4 session dies immediately after xenodm login
> We have an annotation we can use during ports build to mark binaries to > disable enforcement, this will get added to some ports with known > problems (but I think it maybe a bit problematic when it's a library > which doesn't yet work with IBT enforcement - in that case AIUI we'll > need to annotate all binaries using that library..) That is the same mechanism wxneeded. The idea would be to immediately mark complicated binaries that don't work with IBT enforcement, and then things are good enough for users, revisit the situation to find out where actual problems are, and iterate at fixing them, learning the solution methods along the way.
Re: On 2013-06-12 snapshot xfce4 session dies immediately after xenodm login
Peter N. M. Hansteen wrote: > On Mon, Jun 12, 2023 at 04:47:41PM +0200, Sebastien Marie wrote: > > > (gdb) > > > > > > with some instruction I might be able to extract more information. > > > > > > > failing in _start is odd. it look like the binary wasn't build with > > cf-protection=branch, and the compiler has it since few weeks now (since > > 2023-04-26 exactly). > > > > Could you check the signature date of your package ? > > > > $ grep @digital-signature /var/db/pkg/xfce4-session-*/+CONTENTS > > @digital-signature signify2:2023-06-10T10:18:49Z:external > > [Mon Jun 12 16:49:33] peter@zaida:~$ grep @digital-signature > /var/db/pkg/xfce4-session-*/+CONTENTS > @digital-signature signify2:2023-04-16T09:46:52Z:external You are using snapshots incorrectly.
Re: On 2013-06-12 snapshot xfce4 session dies immediately after xenodm login
Yep -- it is definately an old binary. > failing in _start is odd. it look like the binary wasn't build with > cf-protection=branch, and the compiler has it since few weeks now (since > 2023-04-26 exactly). > > Could you check the signature date of your package ? > > $ grep @digital-signature /var/db/pkg/xfce4-session-*/+CONTENTS > @digital-signature signify2:2023-06-10T10:18:49Z:external > > it could be a good indication for the build date. > > > In gdb, could you get the 'disassemble' output (beware, it could be long) ? I > am > interested to the current instructions (to ensure that it is failing in a > jmp). > It could permit to check that the backtrace is right. > > Thanks. > -- > Sebastien Marie >
Re: Process (pid 1) got signal 31 on PC Engines APU2
Paul de Weerd wrote: > lpt0 at isa0 port 0x378/4 irq 7 > intr_establish: pic ioapic0 pin 7: can't share type 3 with 2 > wbsio0 at isa0 port 0x2e/2: NCT5104D rev 0x52 > vmm0 at mainbus0: SVM/RVI > acpi.c: acpi_powerdown_task pre prsignal > acpi.c: acpi_powerdown_task post prsignal > uhub2 at uhub1 port 1 configuration 1 interface 0 "Advanced Micro Devices > Hub" rev 2.00/0.18 addr 2 > vscsi0 at root > scsibus2 at vscsi0: 256 targets > softraid0 at root > scsibus3 at softraid0: 256 targets > root on sd0a (425cdd38685451a6.a) swap on sd0b dump on sd0b > Process (pid 1) got signal 31 > > So, somehow, the system is convinced the power button has been > pressed (acpi_powerdown_task is called from acpi_pbtn_task in acpi.c > and from acpibtn_notify in acpibtn.c, both when the power button is > pressed). > > With some more experimenting - this signal doesn't appear when the > machine is rebooted, only when it cold boots. Now, the APU doesn't > really have a power button, but "plugging in* power basically has the > same effect of course (it's just .. to *turn on* the system, not to > turn it off). > > Is the conclusion here that the system behaves erratically by > signalling its power button has been pressed, but the machine doesn't > power down because init hasn't installed its signal handlers (probably > hasn't even been started) yet? The conclusion should be that it's ACPI is buggy and crappy. That is the point to start at. Then figure out what workaround to apply.
Re: wsdisplay_switch2: not switching
Klemens Nanni wrote: > Snapshots with 'disable inteldrm' to reduce corruption/hangs on a > Intel T14 gen 3 always print the following on shutdown/reboot: > > syncing disks... done > wsdisplay_switch2: not switching > rebooting... > > Unmodified bsd.mp does not show this. > > It is always a single "wsdisplay_switch2: not switching" line, i.e. never > "wsdisplay_switch1" or "wsdisplay_switch3" as wsdisplay also provides. > > I do not observe any other misbehaviour wrt. this, reboot/shutdown works. > > Is this a bug or expected behaviour when manually forcing efifb(4) in UKC? > The wsdisplay code returns EINVAL when logging this, so it reads like an > error case to me, but I don't know anything about wsdisplay. x13s gives this also, so it has nothing to do with "disable inteldrm". It is suspend/resume wscons acting on non-drm framebuffers clearly. That said, noone is going to be interested in non-drm amd64 effects gained from using config -e. Relying on config -e to make things work is a great way to avoid hunting for the real problem. It's why I have occasionally argued for removing config -e, because of how often it is used as a crutch.
Re: Is it possible to use torrent to distribute OpenBSD?
A A wrote: > Hello, Some Linux distros use torrent to distribute installers (such as > iso file), it will reduce server's capacity and bandwith, and accelerate > download. Is it possible to use torrent to distribute OpenBSD too? Looking > forward to your reply! > Yours,Tom I do not think cdn.openbsd.org is strugging for capacity or bandwidth. Just use it.
Re: Some programs appear to cause system to leak memory, fill ram
> Well, then the stategy is not to have a strategy, which is perfectly fine. The strategy is to teach the principle of not over commiting. > It still doesn't matter for the use case under discussion here. The "bug" > reporter expected some OOM type situation, and didn't observe any, because > the reported "memory leak" does not exist. Case closed, original bug report > in the "rejected" queue, bug reporter educated about file system cache. Sometimes I wonder if we should remove all the diagnostic tooling.
Re: Some programs appear to cause system to leak memory, fill ram
Theo de Raadt wrote: > Rudolf Leitgeb wrote: > > > Lots of people (including myself) come from linux background and use > > OpenBSD for specific security sensitive tasks. Since OpenBSD, like > > every other desktop&server OS these days, has some strategy to deal > > with OOM conditions, the term "OOM killer" is perfectly clear > > regardless of what the actual implementation in OpenBSD is called. > > But it has strategy like that. ^ I mean: OpenBSD has no > > If you run it out of memory plus swap, it will deadlock. This situation > must be prevented by establishing resource limits ahead of time, which > we ship with pretty strict defaults. > > There is nothing dynamic. You are trying to compare a pig and a moon rocket. >
Re: Some programs appear to cause system to leak memory, fill ram
Rudolf Leitgeb wrote: > Lots of people (including myself) come from linux background and use > OpenBSD for specific security sensitive tasks. Since OpenBSD, like > every other desktop&server OS these days, has some strategy to deal > with OOM conditions, the term "OOM killer" is perfectly clear > regardless of what the actual implementation in OpenBSD is called. But it has strategy like that. If you run it out of memory plus swap, it will deadlock. This situation must be prevented by establishing resource limits ahead of time, which we ship with pretty strict defaults. There is nothing dynamic. You are trying to compare a pig and a moon rocket.
Re: OpenBSD 7.3 arm64: config(8) mentions boot.conf(8) but that does not exist
'man boot.conf' shows the boot(8) manual page. It needs to be written. Other architectures are also missing such a file. Are you going to write it? Mike Fischer wrote: > I have successfully installed a OpenBSD 7.3 arm64 VM on UTM 4.2.5 on a Mac > mini (2023) with an M2 Pro CPU. > > In order to see console output I needed to enter »set tty fb0« at the boot> > prompt. Later I was able to create a /etc/boot.conf file with that content. > This worked fine for the following reboots. No more manual entry of the > setting necessary. > > When trying to research the syntax and possible content of the /etc/boot.conf > file, I came across config(8). It mentions boot.conf(8). But that man page > does not exist on the arm64 platform. I found > https://man.openbsd.org/OpenBSD-7.3/boot.conf.8 though. > > https://man.openbsd.org/arm64/boot.conf.8 is also missing so this has not > been fixed in -current. > > Seems like a bug to me. I think there should be a boot.conf(8) man page on > arm64 as that file clearly works when present. > > vm# uname -srmv > OpenBSD 7.3 GENERIC.MP#2080 arm64 > vm# man 8 config > > vm# man 8 boot.conf > man: No entry for boot.conf in section 8 of the manual. > vm# > > > dmesg: > OpenBSD 7.3 (GENERIC.MP) #2080: Sat Mar 25 14:20:25 MDT 2023 > dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP > real mem = 2137935872 (2038MB) > avail mem = 2037706752 (1943MB) > random: good seed from bootblocks > mainbus0 at root: ACPI > psci0 at mainbus0: PSCI 1.1 > cpu0 at mainbus0 mpidr 0: Unknown, MIDR 0x0 > cpu0: 192KB 64b/line 6-way L1 PIPT I-cache, 128KB 64b/line 8-way L1 D-cache > cpu0: 16384KB 128b/line 16-way L2 cache > cpu0: > TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPI,LRCPC+LDAPUR,FCMA,JSCVT,API+PAC,DPB,SpecSEI,PAN+ATS1E1,LO,HPDS,CSV3,CSV2,DIT > cpu1 at mainbus0 mpidr 1: Unknown, MIDR 0x0 > cpu1: 192KB 64b/line 6-way L1 PIPT I-cache, 128KB 64b/line 8-way L1 D-cache > cpu1: 16384KB 128b/line 16-way L2 cache > cpu1: > TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPI,LRCPC+LDAPUR,FCMA,JSCVT,API+PAC,DPB,SpecSEI,PAN+ATS1E1,LO,HPDS,CSV3,CSV2,DIT > efi0 at mainbus0: UEFI 2.7 > efi0: EDK II rev 0x1 > smbios0 at efi0: SMBIOS 3.0.0 > smbios0: > smbios0: QEMU QEMU Virtual Machine > apm0 at mainbus0 > ampintc0 at mainbus0 nirq 288, ncpu 2 ipi: 0, 1, 2: "interrupt-controller" > ampintcmsi0 at ampintc0: nspi 64 > agtimer0 at mainbus0: 24000 kHz > acpi0 at mainbus0: ACPI 6.0 > acpi0: sleep states > acpi0: tables DSDT FACP APIC PPTT GTDT MCFG SPCR DBG2 IORT BGRT > acpi0: wakeup devices > acpimcfg0 at acpi0 > acpimcfg0: addr 0x401000, bus 0-255 > acpiiort0 at acpi0 > "ACPI0007" at acpi0 not configured > "ACPI0007" at acpi0 not configured > pluart0 at acpi0 COM0 addr 0x900/0x1000 irq 33 > pluart0: console > "QEMU0002" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > acpipci0 at acpi0 PCI0 > pci0 at acpipci0 > 0:1:0: rom address conflict 0xfffc/0x4 > "Red Hat Host" rev 0x00 at pci0 dev 0 function 0 not configured > virtio0 at pci0 dev 1 function 0 "Qumranet Virtio Network" rev 0x00 > vio0 at virtio0: address 0e:25:ed:1c:38:1d > virtio0: msix shared > virtio1 at pci0 dev 2 function 0 "Qumranet Virtio 1.x GPU" rev 0x01 > virtio1: no matching child driver; not configured > azalia0 at pci0 dev 3 function 0 "Intel 82801FB HD Audio" rev 0x01: msi > azalia0: No codecs found > xhci0 at pci0 dev 4 function 0 "NEC xHCI" rev 0x03: msi, xHCI 0.0 > usb0 at xhci0: USB revision 3.0 > uhub0 at usb0 configuration 1 interface 0 "NEC xHCI root hub" rev 3.00/1.00 > addr 1 > xhci1 at pci0 dev 5 function 0 vendor "Red Hat",
Re: installer: 30 minutes of watchdog kills automatic upgrade
Mikolaj Kucharski wrote: > On Thu, Apr 13, 2023 at 05:18:15PM +, Klemens Nanni wrote: > > On Thu, Apr 13, 2023 at 04:43:39PM +, Mikolaj Kucharski wrote: > > > I have an amd64 based cheap laptop, which has extremly slow I/O and even > > > slower I/O in the installer. The result is, that fsck during upgrade, > > > triggered via sysupgrade -s, takes ages. Basically makes upgrade > > > non-usable. > > > > Resetting the watchdog between fsck runs might help, can you try that? > > > > > Would it be possible to bump it to 60 minutes? > > > > We've deliberately lowered it from 60 to 30 minutes years ago, after the > > the single timeout for the whole upgrade was split and made resettable. > > > So I tested your below diff and I still needed to bump > WATCHDOG_PERIOD_SEC to 45 minutes. I am not insisting on bumping to 45 > minutes, but I don't see any regress by our change. If you think it is an > improvement, then I guess it can go in. That diff will not go in, because it is just hiding an underlying issue on your specific machine. I detailed some (complicated) steps you could take to learn what the issue is, but if you aren't going to do that we are not going to apply a diff which hurts other people.
Re: unwind is too noisy on sendto failures
Peter J. Philipp wrote: > On Fri, Apr 14, 2023 at 10:20:39AM -0600, Theo de Raadt wrote: > > Doctor! Doctor! It hurts when I stick a knife in here! > > > > When you do weird, harsh, or unrealistic packet filtering, application > > software will occasionally log that you are losing packets which should > > not be filtered, to alert that normal network operation isn't occuring. > > That is to be expected. It is even desirable. > > > > So I think you are only thinking of your own usage case, and trying > > too hard to show that it is synthetic. > > > > But let's get back to the real story: libunbound is upstream software. > > We carry diffs against upstream software, but only when the case is > > extremely compelling. > > > > So how about taking your case up with those doctors, instead. > > Perhaps I didn't explain myself well enough. I understand. You don't > want to deal with it, and you're protecting Florian from unrealistic waste > of time. In my network port 53 had a free course before I got these weird > messages which I thought my software was causing. When I examined unwind a > little it was ignoring my "forwarder" that I set for it and went to the > destination nameservers (arpa. NS's perhaps, or pool.ntp.org.'s) on > it's own accord. I only added stricter firewall rules so that I could > isolate the issue and then it became clearer what the log was trying to > say. If you don't want misleading logs then why log at all? > > I know next to nothing about libunbound and I'm trying to understand what > unwind was telling me in my logs. So I won't bother with going upstream > because they can tell me something but I will only understand the half. I think you explained yourself quite well: 1. When you create a synthetic network filtering condition, log messages are generated from a piece of upstream software 2. And you want to remove those log messages. 3. You are showing little concern if those log messages matter in other non-synthetic conditions experienced by other users 4. You are not interested in having a discussion with the upstream about how those messages could be modified so that they don't bother you, but still serve the other purposes intended by that code they wrote. 5. It is easier to accuse Theo of protecting Florian. Have a nice day!
Re: unwind is too noisy on sendto failures
Doctor! Doctor! It hurts when I stick a knife in here!
When you do weird, harsh, or unrealistic packet filtering, application
software will occasionally log that you are losing packets which should
not be filtered, to alert that normal network operation isn't occuring.
That is to be expected. It is even desirable.
So I think you are only thinking of your own usage case, and trying
too hard to show that it is synthetic.
But let's get back to the real story: libunbound is upstream software.
We carry diffs against upstream software, but only when the case is
extremely compelling.
So how about taking your case up with those doctors, instead.
Peter J. Philipp wrote:
> On Fri, Apr 14, 2023 at 05:18:33PM +0200, Florian Obser wrote:
> > Sorry, this doesn't make any sense.
> >
> > I could never reproduce the -1 or > 65535 case reliably, I see it once
> > in a while, but I can't trigger it. I also can't reproduce it with your
> > instructions.
> >
> > As far as I can work out these weird answer_len numbers come from
> > libworker_event_done_cb() in libworker.c, specifically:
> >
> > (*cb)(cb_arg, rcode, (buf?(void*)sldns_buffer_begin(buf):NULL),
> > (buf?(int)sldns_buffer_limit(buf):0), sec, why_bogus,
> > was_ratelimited);
> >
> > So you are comparing against sldns_buffer_limit(buf), that can just be
> > anything, you can't derive from that "remote server had no listening
> > port".
> >
> > I get "rcode: 2, answer_len: 128" or something else sensibly if I point
> > unwind at a non-responsive forwarder.
> >
> > Since you can reproduce it, can you try this diff please and report
> > back?
> >
> > Does it hit that code path when answer_len is -1 or when answer_len
> > is 65552?
>
> Hi Florian,
>
> In earlier mails (in this thread) I think I showed a pf.conf entry that I
> used to make unwind only hit my forwarder. Again I killed it before this
> trial. In fact I had to do the trial twice since it didn't log in syslog.
>
> root@polarstern# unwind -d - 2>&1 | grep answer_len
>
> [1681487082] libunbound[90786:0] warning: libworker_event_done_cb: rcode: 2,
> answer_len: 28
> [1681487082] libunbound[90786:0] warning: libworker_event_done_cb: rcode: 2,
> answer_len: 128
> [1681487083] libunbound[90786:0] warning: libworker_event_done_cb: rcode: 2,
> answer_len: 128
> [1681487083] libunbound[90786:0] warning: libworker_event_done_cb: rcode: 2,
> answer_len: 28
> [1681487085] libunbound[90786:0] warning: libworker_event_done_cb: rcode: 2,
> answer_len: 128
> [1681487086] libunbound[90786:0] warning: libworker_event_done_cb: rcode: 2,
> answer_len: 28
> [1681487089] libunbound[90786:0] warning: libworker_event_done_cb: rcode: 2,
> answer_len: 128
> [1681487090] libunbound[90786:0] warning: libworker_event_done_cb: rcode: 2,
> answer_len: 28
> [1681487098] libunbound[90786:0] warning: libworker_event_done_cb: rcode: 2,
> answer_len: 128
> [1681487099] libunbound[90786:0] warning: libworker_event_done_cb: rcode: 2,
> answer_len: 28
> [1681487100] libunbound[90786:0] warning: libworker_event_done_cb: rcode: 2,
> answer_len: 65552
> [1681487114] libunbound[90786:0] warning: libworker_event_done_cb: rcode: 2,
> answer_len: 128
> [1681487115] libunbound[90786:0] warning: libworker_event_done_cb: rcode: 2,
> answer_len: 28
> [1681487118] libunbound[90786:0] warning: libworker_event_done_cb: rcode: 2,
> answer_len: 65552
> ...
>
> That's again after I pinged centroid.eu with the forwarding nameserver off. I
> couldn't get it to reply -1, I could not reproduce a "too short" message even
> though I saw permission denied (error 13) in a ktrace. And it didn't
> hit that code path...
>
> You know what the second (most recent) patch I sent was bad too I just
> realised. It didn't cover all the "too short" instances like the first
> patch did. For that I'm sorry. It was covered in:
> Message-ID: <438f75c61b9ef...@stern.delphinusdns.org>
>
> Best Regards,
> -peter
>
> > diff --git libunbound/libunbound/libworker.c
> > libunbound/libunbound/libworker.c
> > index 11bf5f9db55..6bb34001ee9 100644
> > --- libunbound/libunbound/libworker.c
> > +++ libunbound/libunbound/libworker.c
> > @@ -680,6 +680,9 @@ libworker_event_done_cb(void* arg, int rcode,
> > sldns_buffer* buf,
> > context_query_delete(q);
> > lock_basic_unlock(&ctx->cfglock);
> >
> > + log_warn("%s: rcode: %d, answer_len: %d\n", __func__,
> > + rcode, buf?(int)sldns_buffer_limit(buf):0);
> > +
> > if(!cancelled) {
> > /* call callback */
> > int sec = 0;
> >
> >
> > >
> > > >
> > > Apr 13 20:53:26 polarstern unwind[73363]: terminating
> > > Apr 13 20:53:27 polarstern resolvd[81113]: rebuilding: new unwind
> > > Apr 13 20:54:12 polarstern unwind[16252]: remote nameserver had no
> > > lis
Re: installer: 30 minutes of watchdog kills automatic upgrade
No laptop should be that slow. Something is wrong. If not running the installer, does 'systat vm 1' show interrupt storms or other root causes? Or is it only the installer. So the way to debug this is a bit quirky, I've done this before. It is not simply, I will describe it in small rough steps. First, you want a GENERIC or GENERIC.MP kernel for the installer, but with the RAMDISK features. Diff the config files to tell the difference. You don't want SMALL_KERNEL, in particular. The kernel will now support more features. At this point, get it up and running in the installer, and see if it is slow. If it is still slow, you can now download proper test binaries like vmstat and systat, and full sysctl, and see if you can see what hw.sensors and interrupts look like. You need to identify something that is different. The installer timeouts are serving people with common cases, so they don't need to wait. Making the timeouts ridiculously long does not serve those people Mikolaj Kucharski wrote: > Hi, > > I have an amd64 based cheap laptop, which has extremly slow I/O and even > slower I/O in the installer. The result is, that fsck during upgrade, > triggered via sysupgrade -s, takes ages. Basically makes upgrade > non-usable. I need to follow manual upgrade or I edit via the > gzip, rdsetroot -x, vnconfig, mount, vi, umount, vnconfig -u, > rdsetroot, gzip dance the WATCHDOG_PERIOD_SEC in install.sub and > bump it to 60 minutes, then I can sysupgrade the machine. > > Would it be possible to bump it to 60 minutes? > > I have that laptop powered off at the moment, but I will upgrade to > -current in coming days and will post in the thread dmesg from > GENERIC.MP and RAMDISK_CD. > > -- > Regards, > Mikolaj >
Re: pledge allows /dev/null to be any file type
Your report is complete bullshit.
If /dev/null isn't the right device, then either you were holed by someone who
is trying to mess with you, or your root operator is an idiot.
p...@delphinusdns.org wrote:
> >Synopsis:pledge allows /dev/null to be any file type
> >Category:kernel
> >Environment:
> System : OpenBSD 7.2
> Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
>
> r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
>
> Architecture: OpenBSD.arm64
> Machine : arm64
> >Description:
> I was testing pledge on a 7.2 system and as a test opened /dev/null.
> I was astonished that it didn't abort. OK perhaps it needs to do that but
> doesn't it work better if /dev/null is major/minor (2,2) device? I have a
> ktrace for you to show what I mean.
> >How-To-Repeat:
> spica# mkdir dev
> mkdir: dev: File exists
> spica# touch dev/null
> spica# ktrace -i ./testprog
> spica# ls -l dev/null
> -rw-r--r-- 1 root pjp 5 Mar 19 22:51 dev/null
> spica# cat dev/null
> test
> spica#
>
> The ktrace I'm gonna edit it to show only the juicy parts:
>
> 13252 testprog CALL chroot(0x995cc0ea640)
> 13252 testprog NAMI "/home/pjp"
> 13252 testprog RET chroot 0
> 13252 testprog CALL kbind(0x7f7f95b8,24,0xd10fcc1b312a79c0)
> 13252 testprog RET kbind 0
> 13252 testprog CALL chdir(0x995cc0ea64a)
> 13252 testprog NAMI "/"
> 13252 testprog RET chdir 0
> 13252 testprog CALL kbind(0x7f7f95b8,24,0xd10fcc1b312a79c0)
> 13252 testprog RET kbind 0
> 13252 testprog CALL pledge(0x995cc0ea652,0)
> 13252 testprog STRU promise="stdio"
> 13252 testprog RET pledge 0
> 13252 testprog CALL kbind(0x7f7f95b8,24,0xd10fcc1b312a79c0)
> 13252 testprog RET kbind 0
> 13252 testprog CALL open(0x995cc0ea658,0x1)
> 13252 testprog NAMI "/dev/null"
> 13252 testprog RET open 4
> 13252 testprog CALL kbind(0x7f7f95b8,24,0xd10fcc1b312a79c0)
> 13252 testprog RET kbind 0
> 13252 testprog CALL write(4,0x995cc0ea64c,0x5)
> 13252 testprog GIO fd 4 wrote 5 bytes
>"test
>
> So writing to a file called {CHROOT}/dev/null is allowed on stdio pledge.
> This is very suboptimal to me. Can't it perform a check for major 2, minor 2?
>
> spica# ls -l /dev/null
> crw-rw-rw- 1 root wheel2, 2 Mar 19 10:14 /dev/null
>
> >Fix:
> From github I got this for the HEAD of CVS from:
>
> https://github.com/openbsd/src/blob/master/sys/kern/kern_pledge.c
>
>
> ->
> case SYS_open:
> /* daemon(3) or other such functions */
> if ((ni->ni_pledge & ~(PLEDGE_RPATH | PLEDGE_WPATH)) == 0 &&
> strcmp(path, "/dev/null") == 0) {
> ni->ni_cnd.cn_flags |= BYPASSUNVEIL;
> return (0);
> }
> <--
>
> I figure that's the code for this, partially. But someone else would surely
> know better. And has surely a better fix on hand?
>
>
> dmesg:
> see previous reports.
>
Re: resistance against single-even upsets
Peter J. Philipp wrote: > On Tue, Mar 14, 2023 at 10:34:48AM -0600, Theo de Raadt wrote: > > Good god, imagine this bit flip happened *anywhere else*, like in the > > page tables, or in the code or data or stack of chrome, or basically > > *anywhere* > > > > Shall we change them all? > > The example I gave was the last resort other than pf enabled to a kernel > compromise afaik. There is a few of them perhaps, they've not been fixed > for decades lying dormant with a sysctl knob to turn them off. There are a few of them???!?! You must be pretty uneducated about how computation actually happens. There are billions.
Re: resistance against single-even upsets
Good god, imagine this bit flip happened *anywhere else*, like in the
page tables, or in the code or data or stack of chrome, or basically
*anywhere*
Shall we change them all?
Shall we change the compiler to not allow checks like this?
Shall we wait for a compiler diff from you?
p...@delphinusdns.org wrote:
> >Synopsis:can we resist agains bit flipping?
> >Category:system
> >Environment:
> System : OpenBSD 7.2
> Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
>
> r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
>
> Architecture: OpenBSD.arm64
> Machine : arm64
> >Description:
> https://en.wikipedia.org/wiki/Single-event_upset
>
> A single event upset gave someone in belgium who was in a poll, 4096
> extra votes. When I think about this bit flip and look at the kernel
> code for an ultra secure operating system there is not much stopping
> someone to try an attack during a cosmic storm or increased solar
> activity. Perhaps a bit flips somewhere in the CPU or RAM?
>
> pjp@polarstern$ grep sourceroute ip_input.c
> int ip_dosourceroute = 0;
> if (!ip_dosourceroute) {
> if (!ip_dosourceroute)
> &ip_dosourceroute);
>
> Like here. As you know someone found something last week if this were
> enabled. But the way this check is. It doesn't check for the low bit set to
> one but it checks for the inverted value, so if the 12th bit was flipped in a
> solar storm ip_dosourceroute would now be 4096. And the system would be wide
> open.
>
> >How-To-Repeat:
> Hackers probably check the weather report like
> https://spaceweather.com/ for increased solar activity and then fill
> the CPU caches with attempts to get a bit flip happening. The odds
> aren't in their favour but who knows they may get lucky.
> >Fix:
> I propose all these variables to be monitored occasionally with a CRC
> check and if there is a bit flip happening to unset it to the right value.
> This is a lot of work but may be worth it. OpenBSD would never be faring to
> space right? I have no code but trying to think around how to do this.
>
>
> dmesg:
> cut
>
Re: possible segmentation violation in login_radius
Using a global variable like that is poor style.
Re: possible segmentation violation in login_radius
+ if (auth.length > total_length) Isn't auth.length a network byte order value?
Re: redmi laptop keyboard problem
Mark Kettenis wrote: > I really wonder how these things happen. Cause presumably older > versions of Windows didn't look at what the DSDT says about the > polarity, which meant that vendors released DSDTs with the wrong > polarity. But now Windows does look at what the DSDT says? Does that > mean that running newer Windows versions on these older laptops > doesn't work anymore? The invention of interrupts was a bad idea. We should dedicate a core to polling. /sarc
Re: tcpdump/print-cdp.c
It should use vis(3), similar to this:
print-pfsync.c: cp = vis(cp, clr->ifname[i], VIS_WHITE, 0);
p...@delphinusdns.org wrote:
> >Synopsis:tcpdump/print-cdp.c allows escape codes to be sent to terminal
> >Category:system
> >Environment:
> System : OpenBSD 7.2
> Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
>
> r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
>
> Architecture: OpenBSD.arm64
> Machine : arm64
> >Description:
> While trying to disturb tcpdump for the last few days (see earlier posts
> to bugs@), I came across tcpdump's CDP protocol. I was able to change the
> terminal colour of my tcpdump with a specially crafted packet (see earlier
> posts too). CDP does no filtering of what gets send and outputs everything
> from the
> wire like so:
>
> 84 switch(type) {
> 85 case 0x01:
> 86 printf(" DevID '%.*s'", len - 4, p + i + 4);
> 87 break;
>
> >How-To-Repeat:
> code-reading.
> >Fix:
> for (x = 0; x < len - 4; x++) {
> printf("%c", isprint(*(p + i + x + 4)) ? *(p + i + x + 4) :
> '.');
> }
>
> or something like that, I think we have ctypes for tcpdump. Also
> the way IP addresses are printed in this is sorta disgusting. There
> is functions for that.
>
>
> dmesg:
> OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
>
> r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
> real mem = 8432852992 (8042MB)
> avail mem = 8139448320 (7762MB)
> random: good seed from bootblocks
> mainbus0 at root: ACPI
> psci0 at mainbus0: PSCI 1.1, SMCCC 1.2
> cpu0 at mainbus0 mpidr 0: ARM Cortex-A72 r0p3
> cpu0: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
> cpu0: 1024KB 64b/line 16-way L2 cache
> cpu0: CRC32,ASID16
> cpu1 at mainbus0 mpidr 1: ARM Cortex-A72 r0p3
> cpu1: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
> cpu1: 1024KB 64b/line 16-way L2 cache
> cpu1: CRC32,ASID16
> cpu2 at mainbus0 mpidr 2: ARM Cortex-A72 r0p3
> cpu2: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
> cpu2: 1024KB 64b/line 16-way L2 cache
> cpu2: CRC32,ASID16
> cpu3 at mainbus0 mpidr 3: ARM Cortex-A72 r0p3
> cpu3: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
> cpu3: 1024KB 64b/line 16-way L2 cache
> cpu3: CRC32,ASID16
> efi0 at mainbus0: UEFI 2.7
> efi0: https://github.com/pftf/RPi4 rev 0x1
> smbios0 at efi0: SMBIOS 3.3.0
> smbios0: vendor https://github.com/pftf/RPi4 version "UEFI Firmware v1.21"
> date 11/13/2020
> smbios0: Raspberry Pi Foundation Raspberry Pi 4 Model B
> apm0 at mainbus0
> ampintc0 at mainbus0 nirq 256, ncpu 4 ipi: 0, 1, 2: "interrupt-controller"
> agtimer0 at mainbus0: 54000 kHz
> acpi0 at mainbus0: ACPI 6.3
> acpi0: sleep states
> acpi0: tables DSDT FACP CSRT DBG2 GTDT IORT APIC PPTT BGRT
> acpi0: wakeup devices
> acpiiort0 at acpi0
> "BCM2849" at acpi0 not configured
> "BCM2835" at acpi0 not configured
> "BCM2854" at acpi0 not configured
> "ACPI0004" at acpi0 not configured
> xhci0 at acpi0 XHC0 addr 0x6/0x1000 irq 175, xHCI 1.0
> usb0 at xhci0: USB revision 3.0
> uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev
> 3.00/1.00 addr 1
> "ACPI0007" at acpi0 not configured
> "ACPI0007" at acpi0 not configured
> "ACPI0007" at acpi0 not configured
> "ACPI0007" at acpi0 not configured
> "ACPI0004" at acpi0 not configured
> "BCM2848" at acpi0 not configured
> "BCM2850" at acpi0 not configured
> "BCM2856" at acpi0 not configured
> "BCM2845" at acpi0 not configured
> "BCM2841" at acpi0 not configured
> "BCM2841" at acpi0 not configured
> "BCM2838" at acpi0 not configured
> "BCM2839" at acpi0 not configured
> "BCM2844" at acpi0 not configured
> pluart0 at acpi0 URT0 addr 0xfe201000/0x1000 irq 153
> "BCM2836" at acpi0 not configured
> "BCM2EA6" at acpi0 not configured
> "MSFT8000" at acpi0 not configured
> sdhc0 at acpi0 SDC1 addr 0xfe30/0x100 irq 158
> sdhc0: base clock frequency unknown
> "BCM2855" at acpi0 not configured
> bse0 at acpi0 ETH0 addr 0xfd58/0x1 irq 189: address dc:a6:32:cc:db:a7
> brgphy0 at bse0 phy 1: BCM54210E 10/100/1000baseT PHY, rev. 2
> "PNP0C06" at acpi0 not configured
> acpitz0 at acpi0: critical temperature is 90 degC
> simplefb0 at mainbus0: 640x480, 32bpp
> wsdisplay0 at simplefb0 mux 1: console (std, vt100 emulation)
> wsdisplay0: screen 1-5 added (std, vt100 emulation)
> uhub1 at uhub0 port 1 configuration 1 interface 0 "VIA Labs USB2.0 Hub" rev
> 2.10/4.21 addr 2
> uhidev0 at uhub1 port 4 configuration 1 interface 0 "APC Back-UPS ES 700G
> FW:871.O4 .I USB FW:O4" rev 1.10/1.06 addr 3
> uhidev0: iclass 3/0, 146 report ids
> upd0 at uhidev0
> uhid0 at uhidev0 reportid 1: input=0, output=0, feature=1
> uhid1 at uhidev0 reportid 2:
Re: sys_pselect assertion "timo || _kernel_lock_held()" failed
It needs to be fixed in the next 8 hours, or it should be backed out.
Re: pf.conf bug
> This creates an ABI change. People have to recompile their pfctl. > I think we never guarantee this level of compatibility. Correct. It is a binary suppled with the kernel. We pay attention if it is inconvenient. That means if you need a new binary before a new kernel. But this is in the regular order.
Re: mpv segfaults on -current
To cross an architecture into xonly [1], there are multiple careful steps, followed by multiple less careful steps which are required to find the remaining problem areas. We have exhausted the careful steps. We are now into the next phase. [1] Actually, this applies to just about any mitigation. Most mitigations are based upon the concept - that there is an artifact which is not required for any normal code operation - but attack methods gain tremendous advantage because that artifact is in place - then we ask if we can remove that artifact - when we are confident enough pieces in the software ecosystem are are fixed or easily fixed - we remove the artifact, carefully, incrementally, testing along the way - at some point we can't fix the knowns anymore, and must face the unknowns - hi user, thank you for finding a bug, your applications will crash while it takes us 1-3 days to find the small issues (usually because some upstream piece of software is using a retrograde practice), then 1-2 days to get a new pkg snapshot out with the fixes, and then things will be better I'm very confident we can make it through this last phase, in which case the next release will ship with xonly. Otherwise, we'll slow the process down. Not going to slow it down yet. Thanks for participating in snapshots and helping us make a better world.
Re: feature request: installation image with xfce installed
Stuart Henderson wrote: > On 2022/12/19 17:41, Peter Nicolai Mathias Hansteen wrote: > > > 17. des. 2022 kl. 13:03 skrev Andrey : > > > > > > > > > I need an installation image that immediately, in addition to OpenBSD, > > > install xfce for me and will automatically launch XFCE when the computer > > > is turned on. For many reasons, it is impossible to download it manually, > > > especially when you are very far from the Internet, and having a separate > > > installation image containing xfce will lower the threshold for logging > > > into OpenBSD for Windows, mac users, etc. > > > > What you describe can be achieved fairly straightforwardly with a > > siteNM.tgz that contains the required files and the script to perform the > > package install at the tail end of the install process. > > > > Take a few moments to read https://www.openbsd.org/faq/faq4.html#site and > > you’re quite a bit of the way there. > > also, "lower the threshold for Windows, mac users, etc" isn't really a > goal of OpenBSD. Right. Peter, please tell me where I can get a _Windows or Apple_ install image that contains various additional tools that launch immediately when I turn it on. For many reasons it is impossible to download those tools manually (for instance, those systems are so insecure I will never connect them to the internet). Where do I get such Windows or MacOS install images?? Oh, wait they don't exist. You were simply using a rhetorical device in an attempt to convince us to do something just for you.
Re: cc claims ISO C99 support, but %n printf format specifier calls abort()
That could almost be an entry for calendars.openbsd Dec 16 Vincent Lefevre arrives and tries to educate the OpenBSD developers about format string vulnerabilities, which they have been fixing since 1996 Vincent Lefevre wrote: > On 2022-12-16 09:03:39 -0700, Theo de Raadt wrote: > > Vincent Lefevre wrote: > > > > > BTW, if developers use an untrusted format string, then sprintf() > > > is unsafe too (possible buffer overflow), and at some point, > > > printf() too. > > > > what are you trying to say? > > According to > > https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2834.htm > > it has been proposed to deprecate %n mainly because: > > If the format argument of a printf-style-function originates from an > unverified source an attacker may be able to write arbitrary values > to the stack. > > But I'm saying that from this point of view, sprintf() is unsafe too, > actually much more unsafe. Something like %n injection in the format > argument can easily be detected (actually any injection of a format > specifier). For instance, if someone writes > > printf (buf); > > assuming that the string buf will be output, where buf has untrusted > contents, then if buf contains %n, the number of arguments will be > incorrect, so that this can be detected at run time (ditto if printf > has arguments that correspond to a trusted part of buf). However, > with > > sprintf (s, buf); > > (rather than using snprintf), even if the number of arguments is > checked to be correct, there could still be a buffer overflow with > an untrusted buf. > > It's a pity that N2834 doesn't give real-world examples of insecure > use of %n, in particular ones that could not be possible to detect > at run time. > > -- > Vincent Lefèvre - Web: <https://www.vinc17.net/> > 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> > Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: cc claims ISO C99 support, but %n printf format specifier calls abort()
Vincent Lefevre wrote: > BTW, if developers use an untrusted format string, then sprintf() > is unsafe too (possible buffer overflow), and at some point, > printf() too. what are you trying to say? are you trying to say everyone including you should review and audit and re-audit all of them? or are you saying the opposite: that we should all _give up_ trying to fix things, because some ISO commitees lack the balls to remove very dangerous features which noone actually needs, and we should just accept the imperfect world we live in? You lost me..
Re: cc claims ISO C99 support, but %n printf format specifier calls abort()
Well they need to respond, or openbsd ports needs a diff. Vincent Lefevre wrote: > On 2022-12-15 18:56:15 -0700, Theo de Raadt wrote: > > There are almost no %n left in the software ecosystem. If we are able > > to make this crossing, everyone else is also capable, and eventually > > will. Just like with gets(). > > FYI, this breaks GMP, whose configure script insists on %n being > available, otherwise GMP uses its own, buggy implementation of > vsnprintf, which triggers an assertion failure when %a/%A is used > (and this bug affects MPFR). AFAIK, the GMP developers haven't > reacted to the bug report sent in October. > > BTW, if developers use an untrusted format string, then sprintf() > is unsafe too (possible buffer overflow), and at some point, > printf() too. > > -- > Vincent Lefèvre - Web: <https://www.vinc17.net/> > 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> > Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: cc claims ISO C99 support, but %n printf format specifier calls abort()
This falls into the catagory of "bummer".
We will continue to break all applications that use %n, because we
haven't found a single use of %n is that is safe. and %n uses are
completely trivial to replace.
There are almost no %n left in the software ecosystem. If we are able
to make this crossing, everyone else is also capable, and eventually
will. Just like with gets().
So we will not follow your proposal, because your proposal will break
thousands of other things, rather than our intented behaviour of being
safe.
The future doesn't get better if you demand backwards compatibility
forever. The Unix landscape is getting old enough to throw bad ideas
out.
vinc...@vinc17.net wrote:
> >Synopsis:cc claims ISO C99 support, but %n printf format specifier calls
> >abort()
> >Category:
> >Environment:
> System : OpenBSD 7.2
> Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:54:39 MST 2022
>
> r...@syspatch-72-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> Architecture: OpenBSD.amd64
> Machine : amd64
> >Description:
>
> The compiler claims ISO C99 support (__STDC__ == 1 && __STDC_VERSION__ >=
> 199901)
> but does not support the %n printf format specifier, which calls abort().
>
> >How-To-Repeat:
>
> Consider the following C program (tst.c):
>
> #include
>
> int main (void)
> {
> int n;
>
> #if __STDC__ == 1 && __STDC_VERSION__ >= 199901
> printf ("%nhello world", &n);
> #endif
> return 0;
> }
>
> gcc220$ cc tst.c -o tst
> tst.c:8:13: warning: '%n' format specifier support is deactivated and will
> call abort(3)
> printf ("%nhello world", &n);
>~^
> 1 warning generated.
> gcc220$ ./tst
> Abort trap (core dumped)
>
> >Fix:
>
> Until %n gets implemented, __STDC__ should not be set to 1.
>
Re: acme-client canary corrupted issue
sysctl kern.nosuidcoredump=3 mkdir /var/crash/acme-client and then try to reproduce, and see if a core file is delivered there. This coredump mechanism was added to capture some hard-to-capture coredumps, you can see more info in core(5) and sysctl(3) Renaud Allard wrote: > Hi Otto, > > > On 12/14/22 12:01, Otto Moerbeek wrote: > > On Tue, Dec 13, 2022 at 10:34:53AM +0100, Renaud Allard wrote: > > > >> Hello, > >> > >> I was force renewing some certs because I removed some domains from > >> the cert, and got this: > >> acme-client(53931) in free(): chunk canary corrupted 0xa06cb09db00 > >> 0xb0@0xb0 > >> > >> I am using vm.malloc_conf=SUR>> > >> > >> Best Regards > > I cannot reproduce with several attempts. Please include details on > > platform and version. > > Can you show a run with -v on? That gives a hint where the problem > > occurs. > > Do you get a core dump? If so, try to get a backtrace. > > > > > It's quite hard to reproduce, I only had it once when I shrank the > alternative names involved in one certificate. There was no core dump. > > This was produced on 7.2-stable amd64 > account and domain keys are ecdsa > > I ran it with -vvF and could get my run log thanks to tmux back buffer. > I will skip all the verification/certs babble > > isildur# acme-client -vvF arnor.org acme-client: > /somewhere/arnor.org.key: loaded domain key acme-client: > /etc/acme/letsencrypt-privkey.pem: loaded account key acme-client: > /somewhere/arnor.org.crt: certificate valid: 74 days left acme-client: > /somewhere/arnor.org.crt: domain list changed, forcing renewal > acme-client: https://acme-v02.api.letsencrypt.org/directory: > directories acme-client: acme-v02.api.letsencrypt.org: DNS: > 172.65.32.248 lots of standard certs/verif dialog * > -END CERTIFICATE- ] (5800 bytes) acme-client(53931) in free(): > chunk canary corrupted 0xa06cb09db00 0xb0@0xb0 > acme-client: /somewhere/arnor.org.crt: created acme-client: > /somewhere/arnor.org.fullchain.pem: created acme-client: signal: > revokeproc(53931): Abort trap > > Best Regards
Re: riscv64 OpenBSD 7.2 packages are not found at expected URL (typo?)
This has been fixed. Miguel Landaeta wrote: > >Synopsis: riscv64 OpenBSD 7.2 packages are not found at expected URL > >Category: riscv64 > >Environment: > System : OpenBSD 7.2 > Details : OpenBSD 7.2 (GENERIC.MP) #188: Wed Sep 28 04:06:11 MDT 2022 > dera...@riscv64.openbsd.org:/usr/src/sys/arch/riscv64/compile/GENERIC.MP > > Architecture: OpenBSD.riscv64 > Machine : riscv64 > >Description: > pkg_add fails with 404 on riscv64 systems running OpenBSD 7.2 > >How-To-Repeat: > Just try to install any package, e.g.: > florence$ doas pkg_add -v -v -v rsync > https://cdn.openbsd.org/pub/OpenBSD/7.2/packages/riscv64/: no such dir > Can't find rsync > Can't load quirk: Can't locate OpenBSD/Quirks.pm in @INC (you may need > to install the OpenBSD::Quirks module) (@INC contains: > /usr/local/libdata/perl5/site_perl > /usr/local/libdata/perl5/site_perl/riscv64-openbsd > /usr/libdata/perl5/riscv64-openbsd /usr/libdata/perl5) at > /usr/libdata/perl5/OpenBSD/AddDelete.pm line 347. > > > >Fix: > I guess the proper fix should be to fix the URL in the mirrors, for > now you have to workaround the issue by indicating the URL that is > currently available in the mirrors > (https://cdn.openbsd.org/pub/OpenBSD/7.2/packages/risvc64/), e.g.: > > florence$ doas pkg_add -v -v -v > https://cdn.openbsd.org/pub/OpenBSD/7.2/packages/risvc64/rsync > https://cdn.openbsd.org/pub/OpenBSD/7.2/packages/riscv64/: no such dir > Ambiguous: choose package for rsync > a 0: > 1: rsync-3.2.5pl0 > 2: rsync-3.2.5pl0-iconv > Your choice: 1 > parsing rsync-3.2.5pl0 > Can't load quirk: Can't locate OpenBSD/Quirks.pm in @INC (you may need > to install the OpenBSD::Quirks module) (@INC contains: > /usr/local/libdata/perl5/site_perl > /usr/local/libdata/perl5/site_perl/riscv64-openbsd > /usr/libdata/perl5/riscv64-openbsd /usr/libdata/perl5) at > /usr/libdata/perl5/OpenBSD/AddDelete.pm line 347. > found libspec c.96.2 in /usr/lib > found libspec crypto.50.0 in /usr/lib > extract bin/rsync -> /usr/local/bin/rsync > extract man/man1/rrsync.1 -> /usr/local/man/man1/rrsync.1 > extract man/man1/rsync-ssl.1 -> /usr/local/man/man1/rsync-ssl.1 > extract man/man1/rsync.1 -> /usr/local/man/man1/rsync.1 > extract man/man5/rsyncd.conf.5 -> /usr/local/man/man5/rsyncd.conf.5 > extract /etc/rc.d/rsyncd -> /etc/rc.d/rsyncd > extract bin/rrsync -> /usr/local/bin/rrsync > extract bin/rsync-ssl -> /usr/local/bin/rsync-ssl > extract share/doc/rsync/tech_report.tex -> > /usr/local/share/doc/rsync/tech_report.tex > adding group _rsync > Running /usr/sbin/groupadd -v -g 669 -- _rsync > adding user _rsync > Running /usr/sbin/useradd -v -u 669 -g _rsync -L daemon -c rsync > Daemon -d /var/empty -s /sbin/nologin -- _rsync > rsync-3.2.5pl0: ok > The following new rcscripts were installed: /etc/rc.d/rsyncd > See rcctl(8) for details. > Running /usr/sbin/makewhatis -d /usr/local/man -- > /usr/local/man/man1/rrsync.1 /usr/local/man/man1/rsync-ssl.1 > /usr/local/man/man1/rsync.1 /usr/local/man/man5/rsyncd.conf.5 > /dev/sd0a on /: 97 bytes > /dev/sd0h on /usr/local: 2513253 bytes > florence$ > > > -- > Miguel Landaeta, miguel at miguel.cc > secure email with PGP 0x6E608B637D8967E9 available at > http://keyserver.pgp.com/ > "Faith means not wanting to know what is true." -- Nietzsche >
Re: After upgrade 7.1 -> 7.2 on octeon, anything from ports/packages segfaults
Your report is innaccurate.
You say 7.1 to 7.2, but you mean 7.2-current
It is a very big difference.
So the problem is that snapshots kernel contains a diff which is ahead the
snapshots build tree, related to the DT_DEBUG change.
I will pull the diff out of snapshots build until the octeon packags catch up.
Sebastian Oswald wrote:
> >Synopsis: After upgrading from 7.1 -> 7.2 on octeon, anything from
> >ports/packages segfaults
> >Environment:
> System : OpenBSD 7.2
> Details : OpenBSD 7.2-current (GENERIC.MP) #1094: Fri Oct
> 28 18:46:47 MDT 2022
> dera...@octeon.openbsd.org:/usr/src/sys/arch/octeon/compile/GENERIC.MP
>
> Architecture: OpenBSD.octeon
> Machine : octeon
> >Description:
> After upgrading via 'sysupgrade -n' from 7.1 to latest 7.2
> snapshot and afterwards running 'sysmerge' and 'pkg_add -u',
> any binary installed via pkg segfaults. (e.g. vnstatd,
> zabbix_agentd, vim, git, curl)
>
> Packages have been successfully updated by 'pkg_add -u' and show
> current versions. E.g. vim-no_x11 was updated to 9.0.0192
>
> When trying to run any binary from /usr/local/[s]bin/ i only get:
> # zabbix_agentd
> Segmentation fault (core dumped)
> # vim
> Segmentation fault (core dumped)
>
>
> example output from gdb for a core file from vim:
>
> # gdb /usr/local/bin/vim vim.core
> GNU gdb 6.3
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and
> you are welcome to change it and/or distribute copies of it under
> certain conditions. Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for
> details. This GDB was configured as "mips64-unknown-openbsd7.2"...(no
> debugging symbols found)
>
> Core was generated by `vim'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x000500489fec in ?? ()
> (gdb) run
> Starting program: /usr/local/bin/vim
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00358e4f9fec in ?? ()
>
>
> Output looks identical (except for the address) for any
> program/corefile ('0x[...]fec in ?? ()'). I've never used gdb, so if I
> can provide any other useful informations with it please let me know.
>
> I remember reading something about a new libc version (but can't find
> it in the changelogs?), so I suspect there's something foul with the
> version on that system vs the one packages are built against?
> These versions can be found on that system:
> # ls /usr/lib | grep ^libc.so
> libc.so.95.1
> libc.so.96.0
> libc.so.96.1
> libc.so.96.3
> libc.so.96.4
>
>
> dmesg output:
> [ using 763256 bytes of bsd ELF symbol table ]
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California. All rights
> reserved. Copyright (c) 1995-2022 OpenBSD. All rights reserved.
> https://www.OpenBSD.org
>
> OpenBSD 7.2-current (GENERIC.MP) #1094: Fri Oct 28 18:46:47 MDT 2022
> dera...@octeon.openbsd.org:/usr/src/sys/arch/octeon/compile/GENERIC.MP
> real mem = 1073741824 (1024MB)
> avail mem = 1035550720 (987MB)
> random: good seed from bootblocks
> mainbus0 at root: board 20300 rev 0.15, model cavium,ubnt_e300
> cpu0 at mainbus0: CN70xx/CN71xx CPU rev 0.2 1000 MHz, CN70xx/CN71xx FPU
> rev 0.0 cpu0: cache L1-I 78KB 39 way D 32KB 32 way, L2 1024KB 8 way
> cpu1 at mainbus0: CN70xx/CN71xx CPU rev 0.2 1000 MHz, CN70xx/CN71xx FPU
> rev 0.0 cpu1: cache L1-I 78KB 39 way D 32KB 32 way, L2 1024KB 8 way
> cpu2 at mainbus0: CN70xx/CN71xx CPU rev 0.2 1000 MHz, CN70xx/CN71xx FPU
> rev 0.0 cpu2: cache L1-I 78KB 39 way D 32KB 32 way, L2 1024KB 8 way
> cpu3 at mainbus0: CN70xx/CN71xx CPU rev 0.2 1000 MHz, CN70xx/CN71xx FPU
> rev 0.0 cpu3: cache L1-I 78KB 39 way D 32KB 32 way, L2 1024KB 8 way
> clock0 at mainbus0: int 5
> octcrypto0 at mainbus0
> iobus0 at mainbus0
> simplebus0 at iobus0: "soc"
> "bootbus" at simplebus0 not configured
> octciu0 at simplebus0
> octcib0 at simplebus0: max-bits 23
> octcib1 at simplebus0: max-bits 12
> octcib2 at simplebus0: max-bits 6
> octcib3 at simplebus0: max-bits 15
> octcib4 at simplebus0: max-bits 4
> octcib5 at simplebus0: max-bits 11
> octcib6 at simplebus0: max-bits 11
> octgpio0 at simplebus0: 20 pins, xbit 16
> octsmi0 at simplebus0
> octsmi1 at simplebus0
> octpip0 at simplebus0
> octgmx0 at octpip0 interface 0
> cnmac0 at octgmx0: port 0 SGMII, address 74:83:c2:10:cd:57
> ukphy0 at cnmac0 phy 4: Generic IEEE 802.3u media interface, rev. 2:
> OUI 0x0001c1, model 0x000c cnmac1 at octgmx0: port 1 SGMII, address
> 74:83:c2:10:cd:58 ukphy1 at cnmac1 phy 5: Generic IEEE 802.3u media
> interface, rev. 2: OUI 0x0001c1, model 0x000c cnmac2 at octgmx0: port 2
> SGMII, address 74:83:c2:10:cd:59 ukphy2 at cnmac2 phy 6: Generic IEEE
> 802.3u media interface, rev. 2: OUI 0x0001c1, model 0x000c cnmac3 at
> octgmx0: port 3 SGMII, address 74:83:c2:10:cd:5a ukphy3 at cnmac3 phy
> 7: Generic IEEE 802.3
