proposed xterm changes

2022-05-18 Thread Theo de Raadt
Based upon the discussion of xterm a couple of days ago, I have been working on a couple changes to reduce the privs of xterm in general, by reducing the scope of the utmp egid by opening utmp early, improving the unveil calls to match, and then tightening the pledge. Additionally, some

Re: start unlocking kbind(2)

2022-05-18 Thread Theo de Raadt
Mark Kettenis wrote: > > I guess there is another question -- should the ps_kbind_* variables > > be stored inside the uvmspace, rather than inside pr? > > I think there are arguments for both. But I don't think moving it > makes things easier. Whatever proc sets the kbind configuration,

Re: start unlocking kbind(2)

2022-05-18 Thread Theo de Raadt
I guess there is another question -- should the ps_kbind_* variables be stored inside the uvmspace, rather than inside pr?

Re: start unlocking kbind(2)

2022-05-18 Thread Theo de Raadt
David Gwynne wrote: > from yet another perspective, broad use of a common lock can end up > hurting in the long run because you may end up where everything is > serialised and you have to go back and do a ton of work again anyway. > > > I think the theory is ps_kbind_addr is fixed to a shared

Re: Picky, but much more efficient arc4random_uniform!

2022-05-17 Thread Theo de Raadt
> However, I don't see a speedup for either of the alternate approaches. Or maybe, just maybe, the underlying function (arc4random, which in the dominant case it is just a small chacha step) is so inexpensive relative to the proposed higher-level logic changes? So this is all tilting at

Re: start unlocking kbind(2)

2022-05-17 Thread Theo de Raadt
Martin Pieuchot wrote: > On 17/05/22(Tue) 10:44, David Gwynne wrote: > > this narrows the scope of the KERNEL_LOCK in kbind(2) so the syscall > > argument checks can be done without the kernel lock. > > > > care is taken to allow the pc/cookie checks to run without any lock by > > being careful

Re: Picky, but much more efficient arc4random_uniform!

2022-05-16 Thread Theo de Raadt
hey luke you know you sound like an asshole right? Luke Small wrote: > If you’re not running a threaded program, my function wouldn’t be “less > safe.” > > I’d imagine that 99% of programs aren’t multithreaded. > > On Mon, May 16, 2022 at 1:01 PM wrote: > > > > There is the specifically

Re: [PATCH] xenocara: change xterm ProcGetCWD to get cwd via sysctl instead of procfs

2022-05-15 Thread Theo de Raadt
i...@b3zdna.net wrote: > > Eventually there will protocol or text side bug in xterm, and someone > > will figure out ways to escalate beyond our other mitigations. Rather > > than forcing them to operate inside an uncomfortable less-than-POSIX > > pledge+unveil environment, they can reuse a

Re: [PATCH] xenocara: change xterm ProcGetCWD to get cwd via sysctl instead of procfs

2022-05-15 Thread Theo de Raadt
i...@b3zdna.net wrote: > For one me; I use it to send highlighted text in the terminal to an > external program. This highlighted text could be a relative path to be > opened by the external program and thus requires a cwd. But your xterm is less secure. Eventually there will protocol or text

Re: [PATCH] xenocara: change xterm ProcGetCWD to get cwd via sysctl instead of procfs

2022-05-15 Thread Theo de Raadt
Having looked into this, I think "exec-formatted" and "exec-selectable". are the kind of mis-designed anti-security features I don't want in xterm The idea of this is very much against the idea of priv-sep or priv-drop. If a command is supposed to be capable of starting another fresh command at

Re: [PATCH] xenocara: change xterm ProcGetCWD to get cwd via sysctl instead of procfs

2022-05-15 Thread Theo de Raadt
There is so much regret in this feature. xterm is supposed to be as secure as possible so why does it need to inspect all the processes in the system (that is what this feature gives xterm, as soon as you pledge "ps"). How about if xterm wasn't capable of doing that? Is it much of a loss? Who

Re: stop using mquery(2) inside realloc(3)

2022-05-14 Thread Theo de Raadt
I worry a little about having libc use an undocumented mmap(2) flag. About as much as using mquery, which is non-standard. Maybe __MAP_NOREPLACE should get documentation? __MAP_NOFAULT is in the same situation. The behaviour of these flags should be documented (set in stone), which may also

Re: Unlock umask(2)

2022-05-11 Thread Theo de Raadt
Vitaliy Makkoveev wrote: > On Wed, May 11, 2022 at 01:22:51PM -0600, Theo de Raadt wrote: > > Vitaliy Makkoveev wrote: > > > > > Index: sys/sys/filedesc.h > > > === > > > RCS file: /cvs

Re: Unlock umask(2)

2022-05-11 Thread Theo de Raadt
Vitaliy Makkoveev wrote: > Index: sys/sys/filedesc.h > === > RCS file: /cvs/src/sys/sys/filedesc.h,v > retrieving revision 1.45 > diff -u -p -r1.45 filedesc.h > --- sys/sys/filedesc.h4 Jul 2020 08:06:08 - 1.45 >

Re: amd64: do CPU identification before TSC sync test

2022-05-11 Thread Theo de Raadt
try next snap clematis wrote: > Hi, > I can't see any recent commits but has any of those changes been added to > recent snapshots? I was running one from 2nd of May and wasn't hitting > those cpu failed to identify errors but I do with the one from the 10th > of May. > > > cpu1 at mainbus0:

Re: Unlock umask(2)

2022-05-11 Thread Theo de Raadt
I see no userland impact from such a change (except libkvm against kernel corefiles, which doesn't matter)

Re: Unlock umask(2)

2022-05-11 Thread Theo de Raadt
Alexander Bluhm wrote: > On Wed, May 11, 2022 at 11:20:15AM +0300, Vitaliy Makkoveev wrote: > > sys_umask() only modifies `fd_cmask', which modification is already > > protected by `fd_lock' rwlock(9). > > I found this in sys/filedesc.h > > u_short fd_cmask; /* [f/w] mask

Re: ssh-add(1): fix NULL in fprintf

2022-05-09 Thread Theo de Raadt
Martin Vahlensieck wrote: > if (!qflag) { > - fprintf(stderr, "Identity removed: %s %s (%s)\n", path, > - sshkey_type(key), comment); > + fprintf(stderr, "Identity removed: %s %s%s%s%s\n", path, > + sshkey_type(key), comment ? " (" :

Re: clang-local.1: document support for source-based code coverage

2022-05-06 Thread Theo de Raadt
Frederic Cambus wrote: > On a more serious note though, building from ports was the only way > to have -stable packages before we started to offer -stable binary > packages with OpenBSD 6.5, and it is still the only way for users of > architectures for which those packages are not provided. It's

Re: allow 240/4 in various network daemons

2022-05-05 Thread Theo de Raadt
It is like you are trying to predict the next 20 years, but I'm sorry I find it too confusing. Jeroen Massar wrote: > > On 5 May 2022, at 15:36, Theo de Raadt wrote: > > > > Jeroen Massar wrote: > > > >> I thus mostly see these odd prefixes (0/8, 127/8, 24

Re: allow 240/4 in various network daemons

2022-05-05 Thread Theo de Raadt
Jeroen Massar wrote: > I thus mostly see these odd prefixes (0/8, 127/8, 240/4) as extra RFC1918 > space > for those who do want to deploy more IPv4 as they can't be arsed after almost > 30 years to finally do this IPv6 thing... But that's the dangerous part. If the operating systems suddenly

Re: allow 240/4 in various network daemons

2022-05-05 Thread Theo de Raadt
This discussion relates to only one step of a number of potential increments. I believe it is a bad idea to conflate all of these potential address space recovery changes as the same singular discussion. Not all the decisions being made on intranets are sane. Not all of these proposals make

Re: clang-local.1: document support for source-based code coverage

2022-05-04 Thread Theo de Raadt
Marc Espie wrote: > On Wed, May 04, 2022 at 07:43:35AM -0400, Bryan Steele wrote: > > On Wed, May 04, 2022 at 01:20:10PM +0200, Frederic Cambus wrote: > > > Hi tech@, > > > > > > The base system includes the compiler-rt profile library for > > > source-based code coverage. > > > > > > So here

Re: install btrace scripts

2022-04-30 Thread Theo de Raadt
>On 2022-04-30, Alexander Bluhm wrote: >> Hi, >> >> Can we install the btrace scripts to /usr/share/btrace/ ? The >> directory already exists, only the Makefile is not linked to the >> build. >> >> And I would like to use #! to make them executable. > >It's weird to have exec files in share?

Re: pf igmp icmp6 multicast router alert

2022-04-22 Thread Theo de Raadt
Florian Obser wrote: > That's my gut feeling as well. But I don't have any hard evidence that > that is actually correct. However, since we learned that router-alert is > an actual problem it is also a good incremental step. How many years did it take to notice this bug? Surely this was

Re: imsg: handle size integer overflows

2022-04-19 Thread Theo de Raadt
- if ((buf->buf = malloc(len)) == NULL) { + if (len == 0) + buf->buf = NULL; + else if ((buf->buf = malloc(len)) == NULL) { This code intentionally permitted malloc(0), because with our malloc/free behaviour that will allocate a non-read/writeable object and a

Re: login_fbtab glob

2022-04-15 Thread Theo de Raadt
Do we need to worry about symbolic links? I guess not, since they would only be owned by root? joshua stein wrote: > On Fri, 15 Apr 2022 at 12:17:12 -0600, Todd C. Miller wrote: > > On Fri, 15 Apr 2022 13:12:03 -0500, joshua stein wrote: > > > > > Thanks, both applied. > > > > Looks good to

Re: rate limit uvn_flush warning

2022-04-14 Thread Theo de Raadt
> If I understand correctly, the problem is that writing to memory > of an mmap(2)ed file has no error handling. If the file system is > full, userland cannot be informed. So someone invented this message > in the kernel. If you cannot return an error to the program, deciding to print a message

Re: kbd -l error message

2022-04-14 Thread Theo de Raadt
I don't see the need for the word "open "in the message. Alexander Bluhm wrote: > Hi, > > When kbd -l is executed as regular user, it fails silently. > > $ kbd -l > $ echo $? > 0 > > Error handling is a bit tricky. We want the first error if no > device is available. > > $ ./kbd -l > kbd:

Re: rate limit uvn_flush warning

2022-04-13 Thread Theo de Raadt
I think we should fix the bug and/or DELETE the message entirely

Re: Kill selrecord()

2022-04-12 Thread Theo de Raadt
I don't think this is the right time to rush and commit big diffs which noone can actively test, not even build on all architectures, because there are no snapshots being built, because the tree is semi-frozen to make a release. visa is right. Visa Hankala wrote: > On Mon, Apr 11, 2022 at

Re: remove unused definition in if_vxlan.c

2022-04-02 Thread Theo de Raadt
Not now. The ABI/API is locked for the upcoming release. Denis Fondras wrote: > VXLANMTU appears nowhere else in the codebase. > > OK to remove it ? > > > Index: if_vxlan.c > === > RCS file: /cvs/src/sys/net/if_vxlan.c,v >

Re: ure(4): add support for RTL8156B

2022-03-31 Thread Theo de Raadt
I ask everyone with a ure -- especially not these newer versions of the chip -- to test this diff, ASAP, and provide ke...@openbsd.org with feedback. With enough feedback to indicate no regression on other chips, this can go in. Reason for this request is the testing period before 7.1 release

Re: Security support status of xnf(4) and xbf(4)

2022-03-28 Thread Theo de Raadt
In follow-up audits, I found that OpenBSD’s xnf(4) > >>>> currently trusts the backend domain. I reported this privately to Theo > >>>> de Raadt, who indicated that OpenBSD does not consider this to be a > >>>> security concern. > >>>> > >

Re: Fix incorrect checksum generation in sr_meta_init

2022-03-28 Thread Theo de Raadt
kqueue uses a userland data structure. The netbsd PR is saying that the userland data structure gets corrupted, so that the event doesn't arrive. Thus the process stops. That PR says their kernel is not buggy, but the kqueue handling. If they are updated on libuv, maybe they are seeing the

Re: __read_mostly

2022-03-24 Thread Theo de Raadt
Ingo Schwarze wrote: > Hi, > > >> A downside of this is that it becomes easier to guess the addresses > >> of the tagged variables. > > > No kidding. It partly undoes the effort of KARL. > > I don't feel qualified to comment on the patch, > but i can't resist mentioning that i still love >

Re: VMM avoid duplication and reduce atack surface with octboot(4)

2022-03-22 Thread Theo de Raadt
Alexis wrote: > That is the beauty of it. > With octboot(4) only 1 would be necessary Don't be stupid.

Re: VMM avoid duplication and reduce atack surface with octboot(4)

2022-03-22 Thread Theo de Raadt
Alexis wrote: > Have vmm/vmd core developers ever thought of using octboot has a way to u > se openbsd has a bootloader to avoid stack duplication, and attached atack > surface reduction. Avoiding to maintain 2 stacks, seabios/uefi and host > vm, could be a simple way to improve vmm for HVM or

Re: riscv64: chatty SIGILL printf

2022-03-22 Thread Theo de Raadt
Yes, it should be silent. Old debugging code obviously. Jeremie Courreges-Anglas wrote: > Just like breakpoints, SIGILL shouldn't print anything. FWIW this seems > to only happen once in a ports bulk build. > > ok? > > > Index: trap.c >

Re: riscv64: adjust VM_MIN_ADDRESS

2022-03-21 Thread Theo de Raadt
Miod Vallat wrote: Absolutely this should be fixed. > Shortly afterwards, in addition to fixing the overtrusting code, it was > decided never to allow mmap(2) to allow address zero to get mapped, by > never making VM_MIN_ADDRESS equal to zero (I actually argued for this > change to only be

Re: __read_mostly

2022-03-20 Thread Theo de Raadt
> A downside of this is that it becomes easier to guess the addresses > of the tagged variables. No kidding. It partly undoes the effort of KARL.

Re: ieee80211_stats userland vs. kernel

2022-03-08 Thread Theo de Raadt
Stefan Sperling wrote: > On Tue, Mar 08, 2022 at 12:58:27PM -0700, Theo de Raadt wrote: > > Claudio Jeker wrote: > > > > > Honestly I think this is overkill. There is no stat struct where we do > > > this dance. It is accepted that netstat needs to keep in syn

Re: ieee80211_stats userland vs. kernel

2022-03-08 Thread Theo de Raadt
Claudio Jeker wrote: > Honestly I think this is overkill. There is no stat struct where we do > this dance. It is accepted that netstat needs to keep in sync for these > structs to work. Why is it necessary to disconnect the kernel and userland > for this? Actually there is a major one: it is

Re: ieee80211_stats userland vs. kernel

2022-03-07 Thread Theo de Raadt
> For now, the structs are identical so the code copying data out is > kept simple. I think this is unwise, and you should write the field-by-field copying function at the same time, otherwise this is just asking for trouble. You really cannot wait until an intentional change.

Re: add -k / --keep for gzip(1)

2022-03-05 Thread Theo de Raadt
Todd C. Miller wrote: > On Sun, 06 Mar 2022 02:58:30 +0100, Jeremie Courreges-Anglas wrote: > > > I'm not sure what you mean here. Solene's diff added -k to both > > compress(1) and gzip(1) (and their uncompressor counterparts). > > Adding -k to gzip/gunzip only would indeed make the usage()

Re: sysupgrade(8): Pick correct firmware directory

2022-02-28 Thread Theo de Raadt
When you run sysupgrade, you want the firmwares matching what you are installing. The system you are running right now is irrelevant. It's drivers have already loaded the firmwares they need, and a reboot into new bsd.rd is about to happen. So why does there continue to be conversation about

Re: sysupgrade(8): Pick correct firmware directory

2022-02-28 Thread Theo de Raadt
Stefan Hagen wrote: > Andrew Hewus Fresh wrote (2022-02-28 15:40 CET): > > On Mon, Feb 28, 2022 at 02:47:24PM +0100, Stefan Hagen wrote: > > > But now I see that NEXT_VERSION is set earlier and this should fix it: > > > > > > -if $RELEASE && [[ ${_KERNV[1]} == '-beta' ]]; then > > > +if

Re: makefs, inodes, the universe and everything

2022-02-25 Thread Theo de Raadt
Miod Vallat wrote: > > So should it be -f 200, or 250, and/or should the minimum default built-in > > be changed? Basically 100% of makefs use is for our install media, is it > > not > > right to change the default? > > Well it would be interesting to hear from people using makefs for other >

Re: makefs, inodes, the universe and everything

2022-02-25 Thread Theo de Raadt
> tl;dr: by removing unneeded MAKEDEV entries, some platforms will end up > with makefs creating a file system with 256 inodes, of which about 250 > are used, and installation will misbehave in interesting ways due to the > lack of free inodes. Should the default for makefs not be changed, rather

Re: A program compiled with '-pg' option always gets SEGV on its execution.

2022-02-21 Thread Theo de Raadt
Stefan Sperling wrote: > Pledge and unveil interfering with profiling is a separate issue which > is more obvious when it occurs and can easily be worked around by the > developer. Basically any privsep method or technology will harm accounting, because accounting file access makes a poor path

Re: Power-up cc --print-file-name for .so names

2022-02-20 Thread Theo de Raadt
Christian Weisgerber wrote: > Mark Kettenis: > > > There is a scenario where this goes wrong. If a shared library lacks > > a DT_SONAME entry, the library filename is used to generate the > > DT_NEEDED entries. But I would consider such a shared library broken > > and we fixed base a lng

Re: Use installboot(8) in armv7 install.md

2022-02-18 Thread Theo de Raadt
Lovely. Visa Hankala wrote: > Use installboot(8) in armv7 install.md. > > OK? > > Index: distrib/armv7/ramdisk/install.md > === > RCS file: src/distrib/armv7/ramdisk/install.md,v > retrieving revision 1.51 > diff -u -p -r1.51

Re: Driver for PolarFire SoC MSS GPIO controller

2022-02-17 Thread Theo de Raadt
Mark Kettenis wrote: > > From: "Theo de Raadt" > > Date: Thu, 17 Feb 2022 09:23:14 -0700 > > > > I am terrified by existance of the userland gpio interface, basically > > the concept that users should be able to change some pin is more than > >

Re: Driver for PolarFire SoC MSS GPIO controller

2022-02-17 Thread Theo de Raadt
I am terrified by existance of the userland gpio interface, basically the concept that users should be able to change some pin is more than suspect, it is crazy. It completely violates the Unix principle of mapping hardware support to narrow device catagories on a functional basis, which only the

Re: Power-up cc --print-file-name for .so names

2022-02-14 Thread Theo de Raadt
Mark Kettenis wrote: > > From: "Theo de Raadt" > > Date: Mon, 14 Feb 2022 00:34:53 -0700 > > > > > The solution would be to add symlinks like all the other OSes do. But > > > Theo doesn't like that. > > > > No, the problem is you a

Re: Power-up cc --print-file-name for .so names

2022-02-14 Thread Theo de Raadt
Mark Kettenis wrote: > > From: Philip Guenther > > Date: Sun, 13 Feb 2022 23:29:06 -0800 > > > > On Sun, Feb 13, 2022 at 11:18 PM Mark Kettenis > > wrote: > > > > > From: Greg Steuck > > > Date: Sun, 13 Feb 2022 22:37:13 -0800 > > > > > > To give a sense of the kind of change required

Re: Power-up cc --print-file-name for .so names

2022-02-13 Thread Theo de Raadt
Philip Guenther wrote: > On Sun, Feb 13, 2022 at 11:18 PM Mark Kettenis > wrote: > > > > From: Greg Steuck > > > Date: Sun, 13 Feb 2022 22:37:13 -0800 > > > > > > To give a sense of the kind of change required to get the feature I > > > want, see the patch at the end. The change in

Re: Power-up cc --print-file-name for .so names

2022-02-13 Thread Theo de Raadt
Philip Guenther wrote: > Those of long memory will recall a hackathon where dependencies on libc > were put in place, the libm vs libc deps were changed as functions were > moved from libm to libc, and base builds completely broke. My recall is > that the diffs had to basically be unrolled to

Re: Power-up cc --print-file-name for .so names

2022-02-13 Thread Theo de Raadt
> The solution would be to add symlinks like all the other OSes do. But > Theo doesn't like that. No, the problem is you add symbolic links, how long before software ecosystems in ports choose the short names in linkage -- "because it also works"? If they do so, all the transition benefits we

Re: stpecpy(): A better string copy and concatenation function

2022-02-13 Thread Theo de Raadt
Alejandro Colomar (man-pages) wrote: > However, considering some systems don't have strl* functions, and > explicitly don't want to add them (glibc rejected strl* functions), > there it might be useful to add this function. So your position is that when a small number of people fight the

Re: stpecpy(): A better string copy and concatenation function

2022-02-13 Thread Theo de Raadt
Your proposal isn't an improvement over the current situation with strl* functions, and I don't think this is helpful. Alejandro Colomar (man-pages) wrote: > Hi, Todd and Theo! > > I wrote this function this week, based on strlcpy(3) and strecopy()[1], > which are the best string copy

Re: Adding POSIX c99 compiler wrapper script

2022-02-11 Thread Theo de Raadt
Joe Nelson wrote: > I noticed that OpenBSD lacks the POSIX "c99" compiler wrapper. > https://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html > > Is it missing because the community feels it's ill conceived, or just > because nobody stepped up to implement it? If the latter, I can >

Re: Increase armv7 ramdisk size

2022-02-08 Thread Theo de Raadt
Fine. Visa Hankala wrote: > On Mon, Feb 07, 2022 at 09:35:21AM -0700, Theo de Raadt wrote: > > Please don't do such a small increase, because it is likely we'll need to > > do it again the near future. > > > > I suggest taking ns#600 to ns#650 or ns#700, an

Re: Increase armv7 ramdisk size

2022-02-07 Thread Theo de Raadt
Please don't do such a small increase, because it is likely we'll need to do it again the near future. I suggest taking ns#600 to ns#650 or ns#700, and adjusting all the numbers. Visa Hankala wrote: > armv7 ramdisk is very low on space. Building the ramdisk succeeds, > but the installer prints

Re: Use installboot(8) in install.md of riscv64

2022-02-03 Thread Theo de Raadt
Visa Hankala wrote: > > I'd prefer to keep the names in the .c file, especially if the result > > is that they're scatter though the Makefile instead of in a single > > block. > > I agree. Putting definitions in a Makefile also sort of hides them. This is already an ugly Makefile, and I

Re: Use installboot(8) in install.md of riscv64

2022-02-02 Thread Theo de Raadt
Miod Vallat wrote: > > Index: usr.sbin/installboot/armv7_installboot.c > > === > > RCS file: src/usr.sbin/installboot/armv7_installboot.c,v > > retrieving revision 1.11 > > diff -u -p -r1.11 armv7_installboot.c > > ---

Re: Use installboot(8) in install.md of riscv64

2022-02-02 Thread Theo de Raadt
That's a good step. Visa Hankala wrote: > On Tue, Feb 01, 2022 at 10:55:03AM -0700, Theo de Raadt wrote: > > Mark Kettenis wrote: > > > > > Maybe we should rename the file to efi_installboot.c and/or rearrange > > > the code slightly such that is b

Re: locale-specific collation sequence?

2022-02-01 Thread Theo de Raadt
I don't understand your point. We should not require shell-script writers to read C manual pages. Imagine the following: DESCRIPTION The cat utility calls open(2) for files sequentially, then read(2)'s the contents into a buffer before using write(2) the standard output. No. I don't

Re: Use installboot(8) in install.md of riscv64

2022-02-01 Thread Theo de Raadt
Mark Kettenis wrote: > So yes, it would be good if visa@ could add the startup.sh creation > code to installboot for arm64, armv7 and riscv64. That would help. The non-efi setups will remain pretty stupid, lots of special cases. The long term idea is to have all that the installboot(8)

Re: Use installboot(8) in install.md of riscv64

2022-02-01 Thread Theo de Raadt
Mark Kettenis wrote: > Maybe we should rename the file to efi_installboot.c and/or rearrange > the code slightly such that is becomes more obvious that the name of > the file is indeed the only difference. And obviously, efi_installboot.c would do this on all efi architectures: echo

Re: Use installboot(8) in install.md of riscv64

2022-02-01 Thread Theo de Raadt
Mark Kettenis wrote: > > From: "Theo de Raadt" > > Date: Tue, 01 Feb 2022 09:28:59 -0700 > > > > A few comments. > > > > I think this approach is increasingly fragile, because a change for one > > architecture will affect others. > >

Re: Use installboot(8) in install.md of riscv64

2022-02-01 Thread Theo de Raadt
A few comments. I think this approach is increasingly fragile, because a change for one architecture will affect others. > -.elif ${MACHINE} == "armv7" || ${MACHINE} == "arm64" > +.elif ${MACHINE} == "armv7" || ${MACHINE} == "arm64" || ${MACHINE} == > "riscv64" > SRCS += armv7_installboot.c

Re: go, pledge, and dns

2022-01-30 Thread Theo de Raadt
This change is OK with me. The mdns.allow stuff should be fixed by go recognizing that it doesn't exist in OpenBSD, and not attempting the open. Ted Unangst wrote: > A go program that uses pledge("dns") mostly works except for two > incompatibilities with the way golang's dns library works.

Re: Add rtable capability to login.conf

2022-01-29 Thread Theo de Raadt
> I believe it would be better to add setrtable to id pledge. That's right.

Re: syslogd(8): Add hostname parsing support

2022-01-26 Thread Theo de Raadt
> However, as things stand interpretation can be broken with the base > tools. I can't fix garbage input. Your proposal builds a mechanism which encourages making decisions based upon parsing garbage input. >From our diff: +.It Fl H +Use the hostname from the received message +.Pq if detected

Re: fw_update: unregister firmware that has moved to base

2022-01-23 Thread Theo de Raadt
Right, I suggested that the problem is "rtwn" shouldn't be in the firmware_patterns file, because we don't have internet-sourced firmware for it. In the same way we don't have "em", or "com" or "pms" listed. Andrew Hewus Fresh wrote: > On Sun, Jan 23, 2022 at 06:01:44PM -0800, Andrew Hewus

Re: [PATCH] Fix ed shell command when stdout isn't line-buffered

2022-01-22 Thread Theo de Raadt
Todd C. Miller wrote: > On Sat, 22 Jan 2022 14:24:17 +0100, =?UTF-8?Q?S=C3=B6ren?= Tempel wrote: > > > The patch below fixes this issue by flushing all open output streams > > before executing the command using system(3). Alternatively, it may also > > be sufficient to only flush stdout and

Re: syslogd(8): Add hostname parsing support

2022-01-22 Thread Theo de Raadt
> Note that this only adds the parsing, the rest of the current behaviour > of stays the same. I have another diff in the pipeline for allowing the > hostname in the message. I object to this process. You want to add parsing code as a fait accompli. With no justification. Then later on, spring

Re: kubsan tcp timer shift

2022-01-20 Thread Theo de Raadt
Alexander Bluhm wrote: > On Thu, Jan 20, 2022 at 07:02:43PM +, Miod Vallat wrote: > > > An unsinged TF_TIMER does not create that problem. > > > > Why don't you simply append an U suffix to TF_TMR_REXMT? > > There are a lot of TF_ flags. Ususally we dont put an U to hex > flags. The only

Re: ix(4): enable TCPv6/UDPv6 cksum offloading

2022-01-13 Thread Theo de Raadt
> - m_getptr() returns the correct mbuf and offset to the header. I > think we can assume that a single IPv6 header, that our stack has > created, is in contiguous memory. The IPv4 case just above makes > the same assumption. And if the assumption is not met due to interations between

Re: ix(4): enable TCPv6/UDPv6 cksum offloading

2022-01-12 Thread Theo de Raadt
Jan Klemkow wrote: > On Wed, Jan 12, 2022 at 05:54:07PM +0100, Mark Kettenis wrote: > > > Date: Wed, 12 Jan 2022 17:45:57 +0100 > > > From: Jan Klemkow > > > > > > On Wed, Jan 12, 2022 at 05:36:01PM +0100, Mark Kettenis wrote: > > > > > Date: Wed, 12 Jan 2022 17:02:03 +0100 > > > > > From: Jan

Re: ix(4): enable TCPv6/UDPv6 cksum offloading

2022-01-12 Thread Theo de Raadt
> Yes, but we don't parse the TCP header here. As bluhm@ figured out: > The access to ip_hl does not generate an alignment problem on sparc64. > Because, the bits of ip_hl are on the other of the byte, as bits of > th_off. I think this is pure luck, and suspect the same problem will happen again

Re: unlock mmap(2) for anonymous mappings

2022-01-11 Thread Theo de Raadt
I am saying I want better study on all architectures, so that I don't hit problems (first) in the snapshots cluster. Theo de Raadt wrote: > I am blocking this. > > I don't see any messaging which suggests this has been run on all > architectures. It might still hit some MD code wh

Re: unlock mmap(2) for anonymous mappings

2022-01-11 Thread Theo de Raadt
I am blocking this. I don't see any messaging which suggests this has been run on all architectures. It might still hit some MD code which is wrong. Klemens Nanni wrote: > On Tue, Jan 11, 2022 at 09:54:44AM -0700, Theo de Raadt wrote: > > > Now this is clearly a "slow"

Re: unlock mmap(2) for anonymous mappings

2022-01-11 Thread Theo de Raadt
> Now this is clearly a "slow" path. I don't think there is any reason > not to put all the code in that if (uvw_wxabort) block under the > kernel lock. For now I think making access to ps_wxcounter atomic is > just too fine grained. Right. Lock the whole block.

Re: scramble printf(9) %p

2022-01-07 Thread Theo de Raadt
> As the kernel currently contains (at least) 1946 pointers leak by using > printf(9) and %p, it might be more efficient to scramble %p with a > static value (randomly assigned at boot time). Oh come on. That proposal has no security property! Over time we need to delete all such printf's, and

Re: patch: add a new ktrace facility for replacing some printf-debug

2022-01-07 Thread Theo de Raadt
> I agree, but the intent is replacing a debugging method with another > debugging method (hoping it is more useful). The messages showed here > are the same that the ones which would be shown on the console before > the diff. the thing about the kernel messages, is you see the pointers and you

Re: patch: add a new ktrace facility for replacing some printf-debug

2022-01-07 Thread Theo de Raadt
> If this gets added, more care is needed with the messages. For example, > kernel memory addresses should not be shown because they are privileged > information. No kidding. We spent a decade cleaning that up, and don't want to go back to exposing.

Re: Fix GNUism in bsd.dep.mk

2022-01-03 Thread Theo de Raadt
I have seen this on occasional also, and couldn't find the cause. I like the diff. Philip Guenther wrote: > On Fri, Dec 31, 2021 at 7:44 AM Christian Ehrhardt > wrote: > > > Here at genua, trying to build libpcap sometimes breaks in > > libpcap with the following error message: > > > > |

Re: unlock mmap(2) for anonymous mappings

2021-12-31 Thread Theo de Raadt
>Now that mpi has unlocked uvm's fault handler, we can unlock the mmap >syscall to handle MAP_ANON without the big lock. ... >So here's a first small step. I've been running with this for months >on a few amd64, arm64 and sparc64 boxes without problems So, 3 architectures have been tested. I

Re: explain priority codepoints and their mapping in vlan.4

2021-12-20 Thread Theo de Raadt
Christopher Zimmermann wrote: > We are not doing it different. But in my mind especially the mapping > of PCP / prio 0 / 1 is not intuitive and may be confusing (but is > correct!). That's why I think this should be documented in detail. Right. > >> The 802.1Q and 802.1ad protocols include a

Re: document patch(1) not supporting binary diffs

2021-12-20 Thread Theo de Raadt
Ingo Schwarze wrote: > The patch(1) manual talks about "lines" throughout, > and for binary files, a concept of "lines" does not even exist. That is a bit strong. Some utilities designed for "text files" have no problem being both 8-bit clean and very-long-line capable. For example, you can

Re: : provide ElfW() macro

2021-12-18 Thread Theo de Raadt
Klemens Nanni wrote: > On Sat, Dec 18, 2021 at 04:37:17PM +0300, Andrew Krasavin wrote: > > On Fri, Dec 17, 2021 at 01:04:35PM +, Klemens Nanni wrote: > > > An upcoming port uses ElfW(). I first patched the port, but looking > > > around shows that both NetBSD and FreeBSD adopted the macro:

Re: fix ping(8) and traceroute(8) source selection

2021-12-17 Thread Theo de Raadt
I am not a fan of solving this in ping and traceroute, because there are other places this alternative-srcaddr mechanism is not working, and it feels like all of the solutions need to be in the kernel. Also, there is no urgency to fix it immediately. So a kernel option can be invested in a

Re: Raw socket should comply with selected source address

2021-12-16 Thread Theo de Raadt
'route sourceaddr' support is incomplete. In particular it does not work in ping or traceroute. The original idea of this option is to replace the default src address allocation algorithm, with a static default, particularily on routers. It is only working for non-bound sockets, but it should

Re: fix ldapd unveil

2021-12-14 Thread Theo de Raadt
I agree. Jonathan Matthew wrote: > ldapd currently can't reopen its database files, because it always passes > O_CREAT to open() when reopening (see ldapd_open_request()), which means it > needs the unveil 'c' flag. This may have been missed when ldapd was unveiled > because 'ldapctl compact'

Re: cat(1): always use a 64K buffer

2021-12-13 Thread Theo de Raadt
I think Todd is right, and this doesn't need to change. Todd C. Miller wrote: > On Sun, 12 Dec 2021 19:15:51 -0600, Scott Cheloha wrote: > > > cat(1) sizes its I/O buffer according to the st_blksize of the first > > file it processes. We don't do this very often in the tree. I'm not > > sure

Re: sndiod: -F does not switch back to preferred device

2021-12-10 Thread Theo de Raadt
Alexandre Ratchov wrote: > On Thu, Dec 09, 2021 at 09:02:07PM -0700, Theo de Raadt wrote: > > > > I think drivers, or maybe this can be done in higher-level subsystems, need > > to be modified such that events get sent when a device is *actually ready*, > > and

Re: sndiod: -F does not switch back to preferred device

2021-12-09 Thread Theo de Raadt
Theo de Raadt wrote: > I think drivers, or maybe this can be done in higher-level subsystems, need > to be modified such that events get sent when a device is *actually ready*, > and the call from config_attach() should be deleted. Worth mentioning the numbers below are devclass DV

Re: sndiod: -F does not switch back to preferred device

2021-12-09 Thread Theo de Raadt
wrote: > On Thu, 09 Dec 2021 at 16:46:24 -0700, Theo de Raadt wrote: > > Please do not recommend people use hotplugd, for any purpose. > > > > It is on my queue for deletion, because noone has stepped up and > > fixed it. > > > > hotplug is COMPLETEL

  1   2   3   4   5   6   7   8   9   10   >