Re: Some bwfm(4) diffs

[Peter J. Philipp]

On Tue, Oct 10, 2023 at 06:25:44AM +0200, Peter J. Philipp wrote:
> > > Thanks, I actually have one of these myself.  So I'm going to
> > > investigate (and probably drop one of the diffs).
> > 
> > I don't see any problems on my machine.  Firmware loads and WiFi works
> > just fine on my MacBookPro12,1.
> > 
> 
> Hmm odd.  I'll have to check again.  Thanks Mark!

Hi,

Just to confirm it works now.  I updated to a latest snapshot and the
installer may have done something as it attached late in the install but
first complained about no firmware.

Thanks for all the help Mark!

-peter

-- 
Over thirty years experience on Unix-like Operating Systems starting with QNX.

Re: Some bwfm(4) diffs

[Peter J. Philipp]

On Mon, Oct 09, 2023 at 10:07:36PM +0200, Mark Kettenis wrote:
> > Date: Mon, 09 Oct 2023 20:31:04 +0200
> > From: Mark Kettenis 
> > 
> > > Date: Mon, 9 Oct 2023 06:09:57 +0200
> > > From: "Peter J. Philipp" 
> > > 
> > > On Sun, Oct 08, 2023 at 07:42:54PM +0200, Mark Kettenis wrote:
> > > > Hector Martin has added support for the BCM4388 that is found on the
> > > > last generation of Apple Macs.  Based on his commits I've managed to
> > > > get it working on my M2 Pro mini.  I still have to clean up some of
> > > > that stuff, but here is a forst batch of two diffs.
> > > > 
> > > > The changes to dev/ic/bwfm.c correspond to:
> > > > 
> > > > https://github.com/AsahiLinux/linux/commit/81e3cc7bec8b9d9c436f63662d8fcfda4f637807
> > > > 
> > > > The changes to dev/pci/if_bwfm_pci.c corrspond to:
> > > > 
> > > > https://github.com/AsahiLinux/linux/commit/8190add8671fc49c12d04b5ac8fced70f835e69f
> > > > 
> > > > Both changes seem to be a good idea and potentially affect other chips
> > > > as well.  So if you have a machine with bwfm(4), please test.
> > > > 
> > > > ok?
> > > 
> > > Hi,
> > > 
> > > I have an early 2015 MacBookPro that doesn't like this.  It fails to load
> > > the firmware even after I deleted it with fw_update -d and readded it.
> > > 
> > > What results is probably an interrupt storm as the system becomes 
> > > unresponsive.  Sorry I can't give very much more details.
> > 
> > Thanks, I actually have one of these myself.  So I'm going to
> > investigate (and probably drop one of the diffs).
> 
> I don't see any problems on my machine.  Firmware loads and WiFi works
> just fine on my MacBookPro12,1.
> 

Hmm odd.  I'll have to check again.  Thanks Mark!

-peter

-- 
Over thirty years experience on Unix-like Operating Systems starting with QNX.

Re: Some bwfm(4) diffs

[Peter J. Philipp]

On Sun, Oct 08, 2023 at 07:42:54PM +0200, Mark Kettenis wrote:
> Hector Martin has added support for the BCM4388 that is found on the
> last generation of Apple Macs.  Based on his commits I've managed to
> get it working on my M2 Pro mini.  I still have to clean up some of
> that stuff, but here is a forst batch of two diffs.
> 
> The changes to dev/ic/bwfm.c correspond to:
> 
> https://github.com/AsahiLinux/linux/commit/81e3cc7bec8b9d9c436f63662d8fcfda4f637807
> 
> The changes to dev/pci/if_bwfm_pci.c corrspond to:
> 
> https://github.com/AsahiLinux/linux/commit/8190add8671fc49c12d04b5ac8fced70f835e69f
> 
> Both changes seem to be a good idea and potentially affect other chips
> as well.  So if you have a machine with bwfm(4), please test.
> 
> ok?

Hi,

I have an early 2015 MacBookPro that doesn't like this.  It fails to load
the firmware even after I deleted it with fw_update -d and readded it.

What results is probably an interrupt storm as the system becomes 
unresponsive.  Sorry I can't give very much more details.

dmesg follows:


OpenBSD 7.4 (GENERIC.MP) #1396: Sun Oct  8 09:20:40 MDT 2023
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17059287040 (16269MB)
avail mem = 16522534912 (15757MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x8afac000 (32 entries)
bios0: vendor Apple Inc. version "186.0.0.0.0" date 06/14/2019
bios0: Apple Inc. MacBookPro12,1
efi0 at bios0: UEFI 1.1
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC SBST ECDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT 
SSDT DMAR MCFG
acpi0: wakeup devices PEG0(S3) EC__(S3) HDEF(S3) RP01(S3) RP02(S3) RP03(S4) 
ARPT(S4) RP05(S3) RP06(S3) SPIT(S3) XHC1(S3) ADP1(S3) LID0(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-5287U CPU @ 2.90GHz, 2800.02 MHz, 06-3d-04, 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,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,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, 3MB 64b/line 12-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.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-5287U CPU @ 2.90GHz, 2800.05 MHz, 06-3d-04, 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,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,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, 3MB 64b/line 12-way L3 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i5-5287U CPU @ 2.90GHz, 2800.07 MHz, 06-3d-04, patch 
002f
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 
8-way L2 cache, 3MB 64b/line 12-way L3 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-5287U CPU @ 2.90GHz, 2800.07 MHz, 06-3d-04, patch 
002f
cpu3: 

Re: riscv64 possible alignment issue?

[Peter J. Philipp]

On Tue, Sep 05, 2023 at 11:40:42PM +0200, Peter J. Philipp wrote:
> Hi,
> 
> I'm porting OpenBSD to the Mango Pi D1.  Most of the work is done but now
> is the time to try to get a RAMDISK kernel to boot.
> 
> I'm having an issue with atomic_store_64() as shown here (line 1192):
> 
>1184 for (; va < DMAP_MAX_ADDRESS && pa < max_pa;
>1185 pa += L1_SIZE, va += L1_SIZE, l1_slot++) {
>1186 KASSERT(l1_slot < Ln_ENTRIES);
>1187
>1188 /* gigapages */
>1189 pn = (pa / PAGE_SIZE);
>1190 entry = PTE_KERN;
>1191 entry |= (pn << PTE_PPN0_S);
>1192 atomic_store_64([l1_slot], entry);
>1193 }
> 
> The D1 seems to hang on this call.  To me that seems like the store hangs that
> I did on powerpc64 when memory was not aligned.  When I replaced the 
> AMO instruction with a simple C replacement it worked.  So I wonder if the 
> following is correct or not:
> 
>   entry = _ALIGN(PTE_KERN);
> 
> I looked at riscv-privileged-202111203.pdf (page 79) which is for Sv32 and
> a few pages down is the Sv39 (page 84).  But I can't make sense of it.  And
> my Mona Lisa book that I have from Waterman mentions on page 101:
> 
> ''Misaligned address exceptions occur when the effective address isn't 
> divisible
> by the access size - for example, amoadd.w with an address of 0x12.''
> 
> I don't think in the bootstrapping of pmap that traps are turned on yet,
> but I could be mistaken, hence the hang.

There is something weird which I can't figure out, this document is golden
to find the truth:  

https://github.com/riscv/riscv-isa-manual/releases/download/Priv-v1.12/riscv-privileged-20211203.pdf

OK on page 79 is the Sv32 (32-bit specification), it is kinda irrelevant
for us but there is something bothering me, and we must see into this so that
we can talk about Sv39 (64-bit) which is on page 84, and Sv48 which is on
page 86. 

Sv32:

on page 80, figure 4.17 is the 32-bit physical address translation (based on
satp register's MODE) and PPN0 is 10 bits here.  PPN1 is 12 bits.  PPN is
the physical page number.  And the 0 and 1 is the levels of what sort of
pages these are.  4096 byte size is level 0, and level 1 is 4MB (megapages)
size. PTESIZE=4

Sv39:

on page 85, figure 4.20, is the 64-bit (Sv39) physical address translation
based on the satp register which is 64 bits.  PPN0 is 9 bits here, PPN1 is
9 bits and PPN2 is 26 bits.  These three levels represent 4096 byte physical
page numbers (level 0), 2 MB megapages PPN's (level 1) and 1 GB gigapages
PPN's.  "each of which must be virtually and physically aligned to a
boundary equal to its size.  A page-fault exception is raised if the physical
address is insufficently aligned". PTESIZE=8

Sv48:

on page 86, figure 4.23, is a 64-bit (Sv48) physical address translation
based on the satp register again which is 64 bits.  They have 4 levels of
PPN numbers; level 0 pages (9 bits), level 1 megapages (9 bits), 
level 2 gigapages (9 bits) and also introduce 512 GB terapages on level 3
(17 bits).  PTESIZE=8

OK now that I have repeated the document I have 3 questions:

1. AFAIK, we ONLY support Sv39 right now, is this true?
2. From /usr/src/sys/arch/riscv64/include/pte.h:

#define PTE_PPN0_S  10

This is the PPN shift value...why is it 10 and not 9?  We're using Sv39.
If this is wrong then PTE_PPN[123] also have to be adjusted.

3. Why are we talking about 4 levels of PPN's when there is only 3 levels in
the Sv39 definition?

I put some debugging into my kernel this morning and added a printf in
pmap's pmap_bootstrap_dmap() and had it just before the atomic function:

>> OpenBSD/riscv64 BOOTRISCV64 1.5
boot> boot
cannot open sd0a:/etc/random.seed: No such file or directory
booting sd0a:/bsd: 2152904+693716+8907000+538152 
[181604+122+283464+186377]=0xfa1420
bootargs: 
aligned_entry=10001000,pn=4,ae%pn=1000,[l1s]=ffc00100ba00

This is what it showed me.  In my tests instead of _ALIGN()'ing PTE_KERN I
round_page() the entry value to make it 4096 page aligned (10001000),
I also show the physmem in page numbers 0x4 which is 262144 pages for
1 GB RAM.  aligned_entry % pn == 0x1000, which didn't fit exactly into this.
and finally [l1_slot] which gave this odd looking number:  

0xffc00100ba00

This is not a page aligned offset, on any physical page number.  L1_slot I
think was 320 from earlier debugs and I left it alone in my tests.  Let's see,
here it is:

before atomic store l1=ffc00100a000 l1_slot=320,[ffc00100aa00], entry = 
10c7

So I'm wondering about these misalignments and the questions above.


> If you have another idea why I get these let me know, I'm going to bed now
> and won't be up until 6AM or later tomorrow.  I'm let

riscv64 possible alignment issue?

[Peter J. Philipp]

Hi,

I'm porting OpenBSD to the Mango Pi D1.  Most of the work is done but now
is the time to try to get a RAMDISK kernel to boot.

I'm having an issue with atomic_store_64() as shown here (line 1192):

   1184 for (; va < DMAP_MAX_ADDRESS && pa < max_pa;
   1185 pa += L1_SIZE, va += L1_SIZE, l1_slot++) {
   1186 KASSERT(l1_slot < Ln_ENTRIES);
   1187
   1188 /* gigapages */
   1189 pn = (pa / PAGE_SIZE);
   1190 entry = PTE_KERN;
   1191 entry |= (pn << PTE_PPN0_S);
   1192 atomic_store_64([l1_slot], entry);
   1193 }

The D1 seems to hang on this call.  To me that seems like the store hangs that
I did on powerpc64 when memory was not aligned.  When I replaced the 
AMO instruction with a simple C replacement it worked.  So I wonder if the 
following is correct or not:

entry = _ALIGN(PTE_KERN);

I looked at riscv-privileged-202111203.pdf (page 79) which is for Sv32 and
a few pages down is the Sv39 (page 84).  But I can't make sense of it.  And
my Mona Lisa book that I have from Waterman mentions on page 101:

''Misaligned address exceptions occur when the effective address isn't divisible
by the access size - for example, amoadd.w with an address of 0x12.''

I don't think in the bootstrapping of pmap that traps are turned on yet,
but I could be mistaken, hence the hang.

If you have another idea why I get these let me know, I'm going to bed now
and won't be up until 6AM or later tomorrow.  I'm letting my kernel compile
on the slow QEMU host overnight.

Best Regards,
-peter

-- 
Over thirty years experience on Unix-like Operating Systems starting with QNX.

Re: ping.c modifications proof of concept

[Peter J. Philipp]

On Thu, Aug 24, 2023 at 09:22:07AM -0400, A Tammy wrote:
> I don't think having a daemon for ping (or other trivial network
> operations) might be the best design. There's nothing about the service
> that demands a continuously running process in the background.
> 
> Aisha

Ok Aisha, thanks.  Well if there is want for this you guys have a skeleton
anyhow to work with.

Good day! :-)

-peter

-- 
Over thirty years experience on Unix-like Operating Systems starting with QNX.

ping.c modifications proof of concept

[Peter J. Philipp]

Hi,

I have modified ping(8) to grab a raw descriptor from a daemon over AF_UNIX
sockets.  This seems to work.  While what I call the sun daemon needs to be
tightened a lot more it should work to make people understand my concept.

benefits:
we lose inet pledge
we lose the setuid to root bit
root can bypass this entirely so it works in single user mode
it can be broadened to other programs such as traceroute

drawbacks:
not fully tested
sund needs more tightening or there is a security problem
if sund dies ping doesn't work for regular users

Here is a demonstration:
pjp@polarstern$ ls -l /tmp/ping
-rwxr-xr-x  2 root  wheel  1442864 Aug 24 11:38 /tmp/ping
pjp@polarstern$ /tmp/ping -D -c 1 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.073 ms

--- 127.0.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.073/0.073/0.073/0.000 ms
pjp@polarstern$ /tmp/ping6 -D -c 1 centroid.eu
PING centroid.eu (2a03:6000:6f68:631::170): 56 data bytes
64 bytes from 2a03:6000:6f68:631::170: icmp_seq=0 hlim=54 time=31.059 ms

--- centroid.eu ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 31.059/31.059/31.059/0.000 ms

Here is the sund.c code (needs improving):


#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 

#include 
#include 
#include 
#include 


#define EFFECTIVE_PINGUSER  1000
#define EFFECTIVE_PINGGROUP 1000

#define SUND_PATH   "/var/run/sund.sock"

void desc_write(int, int);

int
main(void)
{
int so, new, sel;
int raw, error;

struct addrinfo hints, *res;
struct sockaddr_un sun;
fd_set rset;

uid_t euid;
gid_t egid;

char buf[INET6_ADDRSTRLEN + 1];
socklen_t sunsz = sizeof(struct sockaddr_un);
size_t l;

unveil(SUND_PATH, "rwc");
unveil(NULL, NULL);

unlink(SUND_PATH);


so = socket(AF_UNIX, SOCK_STREAM, 0);
if (so < 0) {
perror("socket");
exit(1);
}

memset(, 0, sizeof(sun));
sun.sun_family = AF_UNIX;   
sun.sun_len = sizeof(struct sockaddr_un);

strlcpy(sun.sun_path, "/var/run/sund.sock", sizeof(sun.sun_path));

if (bind(so, (struct sockaddr *), sizeof(sun)) == -1) {
perror("bind");
exit(1);
}
chmod(SUND_PATH, 0666);

listen(so, 5);
daemon(0, 0);

if (pledge("stdio inet sendfd", NULL) == -1) {
perror("pledge");
exit(1);
}

for (;;) {
FD_ZERO();
FD_SET(so, );

sel = select(so + 1, , NULL, NULL, NULL);
switch (sel) {
case -1:
perror("select");
continue;
default:
break;
}

if (FD_ISSET(so, )) {
new = accept(so, (struct sockaddr *), );
if (new == -1) {
perror("accept");
continue;
}

if (getpeereid(new, , ) == -1) {
perror("getpeereid");
close(new);
continue;
}


if ((euid != EFFECTIVE_PINGUSER) &&
(egid != EFFECTIVE_PINGGROUP)) {
close(new);
continue;
}

if ((l = recv(new, buf, sizeof(buf), 0)) == -1) {
close(new);
continue;
}

buf[l] = '\0';

memset(, 0, sizeof(hints));
if (strchr(buf, '.') != NULL) {
hints.ai_family = AF_INET;
} else {
hints.ai_family = AF_INET6;
}

hints.ai_flags = AI_NUMERICHOST;

if ((error = getaddrinfo(buf,"53",,)) != 0) {
fprintf(stderr, "getaddrinfo: %s\n",
gai_strerror(error));
close(new);
continue;
}

if ((raw = socket(res->ai_family, SOCK_RAW, 
res->ai_family == AF_INET ? IPPROTO_ICMP :
IPPROTO_ICMPV6)) == -1) {

Re: __predict_{true,false} is this right?

[Peter J. Philipp]

On Tue, Aug 22, 2023 at 02:33:39PM +0200, Peter J. Philipp wrote:
> Hi,
> 
> I have an outstanding bug report that I send to deraadt and claudio, in
> reading the code I came across these macros:
> 
> https://github.com/openbsd/src/blame/master/sys/sys/cdefs.h
> 
> lines 195 and 196.  Now my question, does this not sorta look wrong?
> 
> Shouldn't these values be a little more unique?  As in not the same?
> 
> Best Regards,

Oops no they are right.  Hmm.  Sorry.

-peter

-- 
Over thirty years experience on Unix-like Operating Systems starting with QNX.

__predict_{true,false} is this right?

[Peter J. Philipp]

Hi,

I have an outstanding bug report that I send to deraadt and claudio, in
reading the code I came across these macros:

https://github.com/openbsd/src/blame/master/sys/sys/cdefs.h

lines 195 and 196.  Now my question, does this not sorta look wrong?

Shouldn't these values be a little more unique?  As in not the same?

Best Regards,
-peter

-- 
Over thirty years experience on Unix-like Operating Systems starting with QNX.

Re: Diff for evaluation (WACOM tablet driver)

[Peter J. Philipp]

On Sat, Aug 12, 2023 at 02:27:13PM +, Miod Vallat wrote:
> Third time's (hopefully) the charm. How about that diff? Too much things
> have been removed in uwacom.

partial success!  The wacom driver is recognized, no panics this time.  But
the input is all over the place when I try to draw anything in gimp.  It opens
windows and stuff that I didn't open.

spica$ dmesg | grep uwacom
uwacom0 at uhidev0 reportid 16: 3 buttons
wsmouse0 at uwacom0 mux 0
uwacom1 at uhidev0 reportid 192: 3 buttons
wsmouse1 at uwacom1 mux 0
spica$ usbdevs 
Controller /dev/usb0:
addr 01: 8086: Intel, xHCI root hub
addr 02: 056a:033b Wacom Co.,Ltd., Intuos PS
addr 03: 05ac:8290 Broadcom Corp., Bluetooth USB Host Controller
addr 04: 05ac:0273 Apple Inc., Apple Internal Keyboard / Trackpad
addr 05: 05ac:8406 Apple, Card Reader

Oh I see, it attached uwacom0 and uwacom1, odd!  I'll attach the full dmesg
on this one:

syncing disks... done
bwfm0: flowring not closing
bwfm0: flowring not closing
rebooting...
OpenBSD 7.3-current (GENERIC.MP) #4: Sat Aug 12 17:08:58 CEST 2023
p...@spica.delphinusdns.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17059287040 (16269MB)
avail mem = 16522543104 (15757MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x8afac000 (32 entries)
bios0: vendor Apple Inc. version "186.0.0.0.0" date 06/14/2019
bios0: Apple Inc. MacBookPro12,1
efi0 at bios0: UEFI 1.1
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC SBST ECDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT 
SSDT DMAR MCFG
acpi0: wakeup devices PEG0(S3) EC__(S3) HDEF(S3) RP01(S3) RP02(S3) RP03(S4) 
ARPT(S4) RP05(S3) RP06(S3) SPIT(S3) XHC1(S3) ADP1(S3) LID0(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-5287U CPU @ 2.90GHz, 2800.02 MHz, 06-3d-04, 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,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,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, 3MB 64b/line 12-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.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-5287U CPU @ 2.90GHz, 2800.06 MHz, 06-3d-04, 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,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,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, 3MB 64b/line 12-way L3 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i5-5287U CPU @ 2.90GHz, 2800.06 MHz, 06-3d-04, patch 
002f
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 
8-way L2 cache, 3MB 64b/line 12-way L3 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-5287U CPU @ 2.90GHz, 2800.08 MHz, 06-3d-04, patch 
002f
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu3: 32KB 64b/line 8-way D-cache, 32KB 

Re: Diff for evaluation (WACOM tablet driver)

[Peter J. Philipp]

On Sat, Aug 12, 2023 at 01:12:26PM +, Miod Vallat wrote:
> > On Sat, Aug 12, 2023 at 08:00:48AM +, Miod Vallat wrote:
> > > I have had a look at your diff and I think it's decent enough to go in
> > > after some polishing.
> > > 
> > > Can Wacom tablet users try this cleaned up diff?
> > 
> > Hi,
> > 
> > My WACOM tablet stopped working with this, here is a dmesg with the patch 
> > and
> > usbdevs -v output.  Let me know if there is any new patches I can test.
> > 
> > As you can see it doesn't even attach like it should (from the dmesg).
> 
> Thanks for reporting this. The changes in uhidev have been a bit too
> aggressive indeed.
> 
> Does this new version of the diff help? Only uhidev.c differs.

Hi!

I got an instant panic after attach of uwacom0.  Since I don't have a camera
nor do I have panic console access on this macbook pro because the keyboard is
USB, I wrote it down on 2 post-it notes.  Let me see if this helps you any:

uvm_fault(,,,)->e
pagefault trap code 0
stopped at config_search 0x100 cmpq %rax, 0x18(%r14)
...
config_search +0x100
config_found_sm +0x36
hidms_attach +0xe3
uwacom_attach +0x15c
config_attach +0x1f4

Now I believe there is offsets that only work on my compilation so I'll try to
get you some object dumps (objdump -D):

uwacom_attach:

00e0 :
  e0:   f3 0f 1e fa endbr64 
  e4:   4c 8b 1d 00 00 00 00mov0(%rip),%r11# eb 

  eb:   4c 33 1c 24 xor(%rsp),%r11
  ef:   55  push   %rbp
  f0:   48 89 e5mov%rsp,%rbp
  f3:   57  push   %rdi
  f4:   56  push   %rsi
  f5:   52  push   %rdx
  f6:   57  push   %rdi
  f7:   41 53   push   %r11
  f9:   41 57   push   %r15
  fb:   41 56   push   %r14
  fd:   41 55   push   %r13
  ff:   41 54   push   %r12
 101:   48 83 ec 18 sub$0x18,%rsp
 105:   49 89 d4mov%rdx,%r12
 108:   49 89 f7mov%rsi,%r15
 10b:   4c 8d 76 78 lea0x78(%rsi),%r14
 10f:   48 8b 02mov(%rdx),%rax
 112:   48 c7 46 60 00 00 00movq   $0x0,0x60(%rsi)
 119:   00 
 11a:   48 8b 4a 08 mov0x8(%rdx),%rcx
 11e:   48 89 4e 50 mov%rcx,0x50(%rsi)
 122:   48 8b 40 18 mov0x18(%rax),%rax
 126:   48 89 46 48 mov%rax,0x48(%rsi)
 12a:   8a 42 10mov0x10(%rdx),%al
 12d:   88 46 58mov%al,0x58(%rsi)
 130:   48 8b 42 08 mov0x8(%rdx),%rax
 134:   48 8b 78 48 mov0x48(%rax),%rdi
 138:   8b 70 58mov0x58(%rax),%esi
 13b:   31 d2   xor%edx,%edx
 13d:   31 c9   xor%ecx,%ecx
 13f:   e8 00 00 00 00  callq  144 
 144:   49 8b 7c 24 08  mov0x8(%r12),%rdi
 149:   48 8d 75 a8 lea0xffa8(%rbp),%rsi
 14d:   48 8d 55 b4 lea0xffb4(%rbp),%rdx
 151:   e8 00 00 00 00  callq  156 
 156:   45 0f b6 6c 24 10   movzbl 0x10(%r12),%r13d
 15c:   48 8b 7d a8 mov0xffa8(%rbp),%rdi
 160:   8b 75 b4mov0xffb4(%rbp),%esi
 163:   31 d2   xor%edx,%edx
...


hidms_attach:

0ca0 :
 ca0:   f3 0f 1e fa endbr64 
 ca4:   4c 8b 1d 00 00 00 00mov0(%rip),%r11# cab 

 cab:   4c 33 1c 24 xor(%rsp),%r11
 caf:   55  push   %rbp
 cb0:   48 89 e5mov%rsp,%rbp
 cb3:   57  push   %rdi
 cb4:   56  push   %rsi
 cb5:   41 53   push   %r11
 cb7:   41 57   push   %r15
 cb9:   41 56   push   %r14
 cbb:   48 83 ec 18 sub$0x18,%rsp
 cbf:   49 89 f7mov%rsi,%r15
 cc2:   49 89 femov%rdi,%r14
 cc5:   8b 77 18mov0x18(%rdi),%esi
 cc8:   83 fe 01cmp$0x1,%esi
 ccb:   48 c7 c0 00 00 00 00mov$0x0,%rax
 cd2:   48 87 d0xchg   %rdx,%rax
 cd5:   48 c7 c0 00 00 00 00mov$0x0,%rax
 cdc:   48 87 d0xchg   %rdx,%rax
 cdf:   48 0f 44 d0 cmove  %rax,%rdx
 ce3:   48 c7 c7 00 00 00 00mov$0x0,%rdi
 cea:   31 c0   xor%eax,%eax
 cec:   e8 00 00 00 00  callq  cf1 
 cf1:   41 8b 46 14 mov0x14(%r14),%eax
 cf5:   83 e0 0aand$0xa,%eax
 cf8:   83 f8 02cmp$0x2,%eax
 cfb:   74 13   je d10 
 cfd:   83 f8 0a

Re: Diff for evaluation (WACOM tablet driver)

[Peter J. Philipp]

On Sat, Aug 12, 2023 at 08:00:48AM +, Miod Vallat wrote:
> I have had a look at your diff and I think it's decent enough to go in
> after some polishing.
> 
> Can Wacom tablet users try this cleaned up diff?

Hi,

My WACOM tablet stopped working with this, here is a dmesg with the patch and
usbdevs -v output.  Let me know if there is any new patches I can test.

As you can see it doesn't even attach like it should (from the dmesg).

Best Regards,
-peter


rebooting...
OpenBSD 7.3-current (GENERIC.MP) #1: Sat Aug 12 12:34:12 CEST 2023
p...@spica.delphinusdns.org:/sys/arch/amd64/compile/GENERIC.MP
real mem = 17059287040 (16269MB)
avail mem = 16522567680 (15757MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x8afac000 (32 entries)
bios0: vendor Apple Inc. version "186.0.0.0.0" date 06/14/2019
bios0: Apple Inc. MacBookPro12,1
efi0 at bios0: UEFI 1.1
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC SBST ECDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT 
SSDT DMAR MCFG
acpi0: wakeup devices PEG0(S3) EC__(S3) HDEF(S3) RP01(S3) RP02(S3) RP03(S4) 
ARPT(S4) RP05(S3) RP06(S3) SPIT(S3) XHC1(S3) ADP1(S3) LID0(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-5287U CPU @ 2.90GHz, 2800.02 MHz, 06-3d-04, 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,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,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, 3MB 64b/line 12-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.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-5287U CPU @ 2.90GHz, 2800.05 MHz, 06-3d-04, 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,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,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, 3MB 64b/line 12-way L3 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i5-5287U CPU @ 2.90GHz, 2800.06 MHz, 06-3d-04, patch 
002f
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 
8-way L2 cache, 3MB 64b/line 12-way L3 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-5287U CPU @ 2.90GHz, 2800.05 MHz, 06-3d-04, patch 
002f
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 
8-way L2 cache, 3MB 64b/line 12-way L3 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
acpiec0 at acpi0
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-155
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG0)
acpiprt2 at acpi0: bus 1 (RP01)
acpiprt3 at acpi0: bus 2 (RP02)
acpiprt4 at acpi0: bus 3 (RP03)
acpiprt5 at acpi0: bus 5 (RP05)
acpiprt6 at acpi0: bus 4 (RP06)
acpisbs0 at acpi0: SBS0 model "bq20z451" serial 24593 

Re: buffer overprint in riscv64/cpu.c

[Peter J. Philipp]

On Tue, Aug 01, 2023 at 01:43:36PM +0200, p...@delphinusdns.org wrote:
> >Synopsis:non-terminated strings buffer in riscv64/cpu.c
> >Category:kernel
> >Environment:
>   System  : OpenBSD 7.3
>   Details : OpenBSD 7.3-current (GENERIC.MP) #376: Thu Jul 13 
> 03:59:40 MDT 2023
>
> dera...@riscv64.openbsd.org:/usr/src/sys/arch/riscv64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.riscv64
>   Machine : riscv64
> >Description:
>   The cpu detect output is not NUL terminated, this causes *puke* to be
> displayed on serial terminals.
> >How-To-Repeat:
>   Using Qemu for riscv64 arch.
> 
>   from a eeprom -p | grep isa output:
> 
> riscv,isa: 
> 'rv64imafdch_zicsr_zifencei_zihintpause_zba_zbb_zbc_zbs_sstc'
> riscv,isa: 
> 'rv64imafdch_zicsr_zifencei_zihintpause_zba_zbb_zbc_zbs_sstc'
> 
>   I counted this as 60 bytes long.
> >Fix:
> 
> There is two approaches.  One is to explicitly NUL terminate the 32 byte
> buffer or make it bigger.  I give an untested patch of the latter.
> 
> Index: cpu.c
> ===
> RCS file: /cvs/src/sys/arch/riscv64/riscv64/cpu.c,v
> retrieving revision 1.14
> diff -u -p -u -r1.14 cpu.c
> --- cpu.c 15 Jun 2023 22:18:08 -  1.14
> +++ cpu.c 1 Aug 2023 11:35:28 -
> @@ -87,7 +87,7 @@ int cpu_errata_sifive_cip_1200;
>  void
>  cpu_identify(struct cpu_info *ci)
>  {
> - char isa[32];
> + char isa[64];
>   uint64_t marchid, mimpid;
>   uint32_t mvendorid;
>   const char *vendor_name = NULL;
> 
> 

[tying in tech@]

This wasn't effective I just saw.  On another QEMU host the cpu ISA string is
larger than 80 characters.  So I've made another patch.

With this patch it looks like so:

oceans$ dmesg|grep cpu
cpu0 at mainbus0: vendor 0 arch 0 imp 0 rv64imafdch Zicbom Zicboz Zicsr 
Zifencei Zihintpause Zawrs Zfa Zca Zcd Zba Zbb Zbc Zbs Sstc Svadu
intc0 at cpu0
cpu1 at mainbus0: vendor 0 arch 0 imp 0 rv64imafdch Zicbom Zicboz Zicsr 
Zifencei Zihintpause Zawrs Zfa Zca Zcd Zba Zbb Zbc Zbs Sstc Svadu
oceans# grep zicboz /root/eeprom-p.out 
riscv,isa: 
'rv64imafdch_zicbom_zicboz_zicsr_zifencei_zihintpause_zawrs_zfa_zca_zcd_zba_zbb_zbc_zbs_sstc_svadu'
riscv,isa: 
'rv64imafdch_zicbom_zicboz_zicsr_zifencei_zihintpause_zawrs_zfa_zca_zcd_zba_zbb_zbc_zbs_sstc_svadu'

This is in convention with the cpu.c found in qemu:

https://gitlab.com/qemu-project/qemu/-/blob/master/target/riscv/cpu.c

lines 64 through 84 is the description of it.

While I have no OpenBSD/riscv64 on true hardware it works on QEMU, and I
googled for a dmesg online and the Hifive Unmatched should work as well.

patch follows:

Index: cpu.c
===
RCS file: /cvs/src/sys/arch/riscv64/riscv64/cpu.c,v
retrieving revision 1.14
diff -u -p -u -r1.14 cpu.c
--- cpu.c   15 Jun 2023 22:18:08 -  1.14
+++ cpu.c   4 Aug 2023 11:15:16 -
@@ -84,15 +84,19 @@ struct cfdriver cpu_cd = {
 
 int cpu_errata_sifive_cip_1200;
 
+
 void
 cpu_identify(struct cpu_info *ci)
 {
-   char isa[32];
+   char isa[255];
+   char szx_ext[255];  /* S, Z and X extension buffer */
+   char *extensions = "imafdqlcbkjtpvh";
uint64_t marchid, mimpid;
uint32_t mvendorid;
const char *vendor_name = NULL;
const char *arch_name = NULL;
struct arch *archlist = cpu_arch_none;
+   char *p, *pe, *end;
int i, len;
 
mvendorid = sbi_get_mvendorid();
@@ -126,8 +130,70 @@ cpu_identify(struct cpu_info *ci)
 
len = OF_getprop(ci->ci_node, "riscv,isa", isa, sizeof(isa));
if (len != -1) {
+   /* terminate it, it could be non-terminated */
+   isa[sizeof(isa) - 1] = '\0';
+   
+   /* PARSE the IMAFDQ... extensions */
+   pe = extensions;
+   if ((p = strchr(isa, 'i')) != NULL ||
+   (p = strchr(isa, 'I')) != NULL) {
+   for (; *pe != '\0'; pe++) {
+   if (((*p)|0x20) == *pe) {
+   if (p[1]) {
+   p++;
+   i++;
+   } else
+   break;
+   } 
+   /*
+* we've hit an underscore what follows 
+* may be an S or Z extension 
+*/
+   if (*p == '_')
+   break;
+   }
+
+   szx_ext[0] = '\0';
+   if (*p == '_') {
+   *p++ = '\0';
+  

Re: sigcontext in signal.h

[Peter J. Philipp]

On Thu, Aug 03, 2023 at 08:11:40PM +0200, Robert Palm wrote:
> I am looking at following code from arm64 and riscv64.
> 
> ARM64: 
> https://github.com/openbsd/src/blob/master/sys/arch/arm64/include/signal.h#L51
> 
> --
> struct sigcontext {
>  int __sc_unused;
>  int sc_mask; /* signal mask to restore */
> 
>  unsigned long sc_sp;
>  unsigned long sc_lr;
>  unsigned long sc_elr;
>  unsigned long sc_spsr;
>  unsigned long sc_x[30];
> 
>  long sc_cookie;
> };
> --
> 
> RISCV64: 
> https://github.com/openbsd/src/blob/master/sys/arch/riscv64/include/signal.h#L48
> 
> --
> struct sigcontext {
>  int __sc_unused;
>  int sc_mask;
> 
>  __register_t sc_ra;
>  __register_t sc_sp;
>  __register_t sc_gp;
>  __register_t sc_tp;
>  __register_t sc_t[7];
>  __register_t sc_s[12];
>  __register_t sc_a[8];
>  __register_t sc_sepc;
> 
>  /* 64 bit floats as well as integer registers */
>  __register_t sc_f[32]; /* floating-point registers */
>  __register_t sc_fcsr; /* floating-point control register */
> 
>  long sc_cookie;
> };
> 
> --
> 
> I would like to know what these registers "mean".
> 
> Maybe someone knows and can tell me ?
> 
> Thank you.
> 

Hi!

On my riscv64 qemu instance I looked in /usr/include/machine/_types.h
(probably the same as /sys/arch/riscv64/include/_types.h)

and this is what it said:

/* Register size */
typedef long__register_t;


A long in OpenBSD/riscv64 is 8 bytes so 64 bits.

riscv64# cat > sizetest.c
#include 

int
main(void)
{
return (sizeof(long));
}
riscv64# cc -g -o sizetest sizetest.c
riscv64# ./sizetest
riscv64# echo $?
8

I noticed in /sys/arch/riscv64/include/reg.h there is a register which is not
listed in the riscv64 register list in my literature really there is registers
x0 through x31 so 32 long registers, there also is 32 floating point registers
if your implementation has that mostly it does when the riscv cpu reports
IMAFDQ or similar which is (integer ISA, multiply/divide set, atomic set,
floating points set, double floats set, and quad precision floating points).

Is this what you want to hear?  The number of registers is not wrong but
it doesn't have x0 which is a constant value of 0.  Perhaps the
/sys/arch/riscv64/riscv64/db_interface.c has more about the registers to your
liking, near struct db_variable db_regs[]...

I got some help from my (by now pre-pandemic era books) written by David
Patterson which cover riscv in some detail.  Otherwise I just looked at
the https://en.wikipedia.org/wiki/RISC-V near Register sets which seems
to be an excellent reference.

Best Regards,
-peter

-- 
Over thirty years experience on Unix-like Operating Systems starting with QNX.

Re: add extract example to tar(1) man page

[Peter J. Philipp]

On Thu, Aug 03, 2023 at 08:29:31AM +0200, Peter J. Philipp wrote:
> On Thu, Aug 03, 2023 at 07:23:45AM +0100, Jason McIntyre wrote:
> > On Wed, Aug 02, 2023 at 05:52:02PM -0400, aisha wrote:
> > > Hi,
> > >   Someone - https://www.youtube.com/watch?v=NQ5uD5x8vzg - mentioned that 
> > > our man page for tar(1) doesn't have an extract example, so I thought it 
> > > would be good to add a simple one which highlights a common use case.
> > > 
> > > OK?
> > > 
> > 
> > hi.
> > 
> > the examples section is small enough that i suppose it wouldn;t be a
> > problem to add another one.
> > 
> > it does add another example with a similar set of options though, all in
> > a different order. i wonder whether we should try and push the action as
> > the first option, so people can see what we're doing. so "cXXX" when the
> > example is to create, "tXXX" when listing? then keep the "vzf" options
> > that are so common in the same order?
> 
> I wouldn't restore a .tgz without the -p flag.  Particularily on backups.
> Perhaps the OP forgot to add it.
> 
> Best Regards,
> -peter

Someone privately strongly disagreed on this.  So I retract this.

Best,
-peter

Re: add extract example to tar(1) man page

[Peter J. Philipp]

On Thu, Aug 03, 2023 at 07:23:45AM +0100, Jason McIntyre wrote:
> On Wed, Aug 02, 2023 at 05:52:02PM -0400, aisha wrote:
> > Hi,
> >   Someone - https://www.youtube.com/watch?v=NQ5uD5x8vzg - mentioned that 
> > our man page for tar(1) doesn't have an extract example, so I thought it 
> > would be good to add a simple one which highlights a common use case.
> > 
> > OK?
> > 
> 
> hi.
> 
> the examples section is small enough that i suppose it wouldn;t be a
> problem to add another one.
> 
> it does add another example with a similar set of options though, all in
> a different order. i wonder whether we should try and push the action as
> the first option, so people can see what we're doing. so "cXXX" when the
> example is to create, "tXXX" when listing? then keep the "vzf" options
> that are so common in the same order?

I wouldn't restore a .tgz without the -p flag.  Particularily on backups.
Perhaps the OP forgot to add it.

Best Regards,
-peter


> then the second example is probably more helpful as "Create a gzip(1)
> compressed archive blah.tgz".
> 
> i know this isn;t what you're posting about, so feel free to leave alone
> if you don;t want to tackle that.
> 
> one more thing. you could as easily remove the text "the folder", but
> i'd be tempted to use "directory", as that's more standard for our docs,
> and how -C itself describes it.
> 
> jmc
> 
> > Index: tar.1
> > ===
> > RCS file: /cvs/src/bin/pax/tar.1,v
> > retrieving revision 1.64
> > diff -u -p -r1.64 tar.1
> > --- tar.1   31 Mar 2022 17:27:14 -  1.64
> > +++ tar.1   2 Aug 2023 21:47:12 -
> > @@ -359,6 +359,13 @@ Note that the glob pattern has been quot
> >  .Pp
> >  .Dl $ tar tvzf backup.tar.gz '*.jpeg'
> >  .Pp
> > +Verbosely extract an archive, called
> > +.Pa foo-backup.tar.gz ,
> > +to the folder
> > +.Pa /var/foo :
> > +.Pp
> > +.Dl $ tar xzvf foo-backup.tar.gz -C /var/foo
> > +.Pp
> >  For more detailed examples, see
> >  .Xr pax 1 .
> >  .Sh DIAGNOSTICS
> > 
> 

-- 
Over thirty years experience on Unix-like Operating Systems starting with QNX.

Re: VisionFive 2

[Peter J. Philipp]

On Tue, Aug 01, 2023 at 11:11:43PM +0200, Robert Palm wrote:
> I own a VF 2 version 1.2a and can successfully install / boot the machine.
> 
> The inner network port (dwqe1) works at 100 full duplex and receives ipv4
> via DHCP.
> 
> The outer port currently doesn't seem to get an ip, but gets active and in
> full-duplex 100.
> 
> It seems a lot depends on proper .dtb files (which kind users shared with me).
> 
> How did you create the .dtb files ?

I don't know about the rest of the questions, but you can update a .dtb
with a program from the ports in devel/dtc.

-
pjp@polarstern$ more pkg/DESCR
The Device Tree Compiler (DTC) compiles device-tree descriptions for
booting PowerPC kernels on embedded systems without OpenFirmware.

Optional dependency: install the bash package if you wish to use dtdiff.
-

There is something similar in Linux.  Basically you would convert the .dtb
to a .dts, edit it and convert the .dts back to .dtb.

I hope that answers one question.

Best Regards,
-peter

> Do you plan to update them ?
> 
> They seem to be quite different to the "official" starfive releases (which
> don't work for me with OpenBSD).
> 
> Do you plan more work on the VF2 ?
> 
> Thanks!
> 

-- 
Over thirty years experience on Unix-like Operating Systems starting with QNX.

Re: patch for httpd implementing clickjacking protection

[Peter J. Philipp]

On Tue, Feb 07, 2023 at 10:41:34AM +, Stuart Henderson wrote:
> On 2023/02/07 10:20, Peter J. Philipp wrote:
> > Hi,
> > 
> > Arslan Kabeer (on the Internet) made me aware of clickjacking being done on
> > my site using OpenBSD httpd.  This following patch implements a RFC 7034
> > protection called "noiframe" which disallows other sites (but not the same
> > site) to add an iframe to my site.
> > 
> > The config change is like this:
> > 
> > ->
> > location "/" {
> > directory index index.html
> > noiframe
> 
> Using a specific keyword for every site protection header that
> somebody might want seems a bit much. (There are other settings for
> x-frame-options, other headers like content-security-policy and
> x-content-type-options, and various deprecated ones).
> 
> Wouldn't a general-purpose "set header X with the value Y" make
> more sense?

Yes this makes more sense.  Ignore my patch then, it was whipped up this
morning when I got the vulnerability report from Arslan.  I'm unable to
look deeper and general purposely into this, though, I have other TODO's.

It seems a mystery to me however how to add this header into httpd based 
off the manual page if that is the hint.  Perhaps the maintainer of this 
program now has an idea what we need and can schedule programming for it.

Best Regards,
-peter

patch for httpd implementing clickjacking protection

[Peter J. Philipp]

Hi,

Arslan Kabeer (on the Internet) made me aware of clickjacking being done on
my site using OpenBSD httpd.  This following patch implements a RFC 7034
protection called "noiframe" which disallows other sites (but not the same
site) to add an iframe to my site.

The config change is like this:

->
location "/" {
directory index index.html
noiframe
}
<-

The header that is added is the same that google.com adds and it is:

X-Frame-Options: SAMEORIGIN

but only if noiframe is set.

The small patch is against 7.2 openhttpd.

Best Regards,
-peter


Index: httpd.h
===
RCS file: /cvs/src/usr.sbin/httpd/httpd.h,v
retrieving revision 1.161
diff -u -p -u -r1.161 httpd.h
--- httpd.h 15 Aug 2022 12:29:17 -  1.161
+++ httpd.h 7 Feb 2023 08:57:40 -
@@ -544,6 +544,8 @@ struct server_config {
int  fcgistrip;
char errdocroot[HTTPD_ERRDOCROOT_MAX];
 
+   int noiframe;
+
TAILQ_ENTRY(server_config) entry;
 };
 TAILQ_HEAD(serverhosts, server_config);
Index: parse.y
===
RCS file: /cvs/src/usr.sbin/httpd/parse.y,v
retrieving revision 1.128
diff -u -p -u -r1.128 parse.y
--- parse.y 27 Feb 2022 20:30:30 -  1.128
+++ parse.y 7 Feb 2023 08:57:40 -
@@ -140,7 +140,7 @@ typedef struct {
 %token PROTOCOLS REQUESTS ROOT SACK SERVER SOCKET STRIP STYLE SYSLOG TCP TICKET
 %token TIMEOUT TLS TYPE TYPES HSTS MAXAGE SUBDOMAINS DEFAULT PRELOAD REQUEST
 %token ERROR INCLUDE AUTHENTICATE WITH BLOCK DROP RETURN PASS REWRITE
-%token CA CLIENT CRL OPTIONAL PARAM FORWARDED FOUND NOT
+%token CA CLIENT CRL OPTIONAL PARAM FORWARDED FOUND NOT NOIFRAME
 %token ERRDOCS GZIPSTATIC
 %token   STRING
 %token   NUMBER
@@ -685,6 +685,7 @@ serveroptsl : LISTEN ON STRING opttls po
}
srv->srv_conf.flags |= SRVFLAG_SERVER_HSTS;
}
+   | noiframe
;
 
 optfound   : /* empty */   { $$ = 0; }
@@ -697,6 +698,7 @@ hsts: HSTS '{' optnl hstsflags_l '}'
| HSTS
;
 
+
 hstsflags_l: hstsflags optcommanl hstsflags_l
| hstsflags optnl
;
@@ -716,6 +718,11 @@ hstsflags  : MAXAGE NUMBER {
}
;
 
+noiframe   : NOIFRAME  {
+   srv_conf->noiframe = 1;
+   }
+   ;
+
 fastcgi: NO FCGI   {
srv_conf->flags &= ~SRVFLAG_FCGI;
srv_conf->flags |= SRVFLAG_NO_FCGI;
@@ -1466,6 +1473,7 @@ lookup(char *s)
{ "max-age",MAXAGE },
{ "no", NO },
{ "nodelay",NODELAY },
+   { "noiframe",   NOIFRAME },
{ "not",NOT },
{ "ocsp",   OCSP },
{ "on", ON },
Index: server_http.c
===
RCS file: /cvs/src/usr.sbin/httpd/server_http.c,v
retrieving revision 1.153
diff -u -p -u -r1.153 server_http.c
--- server_http.c   21 Sep 2022 05:55:18 -  1.153
+++ server_http.c   7 Feb 2023 08:57:40 -
@@ -1557,6 +1557,17 @@ server_response_http(struct client *clt,
if (kv_add(>http_headers, "Server", HTTPD_SERVERNAME) == NULL)
return (-1);
 
+   /*
+* X-Frame-Options header to prevent iframes/clickjacking
+* As per RFC 7034 (Informational)
+*/
+
+   if (srv_conf->noiframe) {
+   if (kv_add(>http_headers, "X-Frame-Options", 
+   "SAMEORIGIN") == NULL)
+   return (-1);
+   }
+
/* Is it a persistent connection? */
if (clt->clt_persist) {
if (kv_add(>http_headers,

Re: define arm system register names

[Peter J. Philipp]

On Thu, Dec 29, 2022 at 02:38:18PM +0100, Janne Johansson wrote:
> > +#defineSCTLR_EOE   0x0100  /* endianness of 
> > explcit data */
> 
> Misspelled "explicit" there.
> 
> -- 
> May the most significant bit of your life be positive.

Some had to be cut short in order to stay on a 80 character line, for neatness.
It's not some help call attempt in steganography or anything *laugh*.  Feel
free to take it or leave it.

Best Regards,
-peter

define arm system register names

[Peter J. Philipp]

from:

https://developer.arm.com/documentation/den0024/a/ARMv8-Registers/System-registers/The-system-control-register?lang=en

The following patch tries to describe the system register in the source code to
the best of my ability.  Source comment change only, no binary change.

Excuse that this is against a patched 7.2 system, please.  If you would like
to ask me a question regarding this patch reply to me directly as I'm not on
the tech@ list.

-peter


Index: armreg.h
===
RCS file: /cvs/src/sys/arch/arm64/include/armreg.h,v
retrieving revision 1.21
diff -u -p -u -r1.21 armreg.h
--- armreg.h29 Aug 2022 02:01:18 -  1.21
+++ armreg.h29 Dec 2022 12:48:23 -
@@ -560,26 +560,26 @@
 #defineSCTLR_RES0  0xc8222400  /* Reserved, write 0 */
 #defineSCTLR_RES1  0x30d00800  /* Reserved, write 1 */
 
-#defineSCTLR_M 0x0001
-#defineSCTLR_A 0x0002
-#defineSCTLR_C 0x0004
-#defineSCTLR_SA0x0008
-#defineSCTLR_SA0   0x0010
-#defineSCTLR_CP15BEN   0x0020
-#defineSCTLR_THEE  0x0040
-#defineSCTLR_ITD   0x0080
-#defineSCTLR_SED   0x0100
-#defineSCTLR_UMA   0x0200
-#defineSCTLR_I 0x1000
-#defineSCTLR_DZE   0x4000
-#defineSCTLR_UCT   0x8000
-#defineSCTLR_nTWI  0x0001
-#defineSCTLR_nTWE  0x0004
-#defineSCTLR_WXN   0x0008
-#defineSCTLR_SPAN  0x0080
-#defineSCTLR_EOE   0x0100
-#defineSCTLR_EE0x0200
-#defineSCTLR_UCI   0x0400
+#defineSCTLR_M 0x0001  /* enable MMU */
+#defineSCTLR_A 0x0002  /* alignment check 
enable bit */
+#defineSCTLR_C 0x0004  /* data cache enable */
+#defineSCTLR_SA0x0008  /* stack alignment 
check enbl */
+#defineSCTLR_SA0   0x0010  /* stack align check 
for sa0 */
+#defineSCTLR_CP15BEN   0x0020  /* CP15 barrier enable 
*/
+#defineSCTLR_THEE  0x0040  
+#defineSCTLR_ITD   0x0080  /* IT disable */
+#defineSCTLR_SED   0x0100  /* SET END disable */
+#defineSCTLR_UMA   0x0200  /* User Mask access */
+#defineSCTLR_I 0x1000  /* Instruction cache 
enable */
+#defineSCTLR_DZE   0x4000  /* access to DC ZVA 
Instr. */
+#defineSCTLR_UCT   0x8000  /* Enable El0 access */
+#defineSCTLR_nTWI  0x0001  /* Not trap WFI */
+#defineSCTLR_nTWE  0x0004  /* Not trap WFE */
+#defineSCTLR_WXN   0x0008  /* write perm implies 
XN */
+#defineSCTLR_SPAN  0x0080  
+#defineSCTLR_EOE   0x0100  /* endianness of 
explcit data */
+#defineSCTLR_EE0x0200  /* exception endianness 
*/
+#defineSCTLR_UCI   0x0400  /* enable 64-bit ELO 
access */
 
 /* SPSR_EL1 */
 /*

match driver rkanxdp(4) with netbsd further...

[Peter J. Philipp]

Hi,

I don't know if we're locked but I'd like to point out that in NetBSD's

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/arm/rockchip/rk_anxdp.c.diff?r1=1.3=1.4_with_tag=MAIN

There is this change from 0x3 to 0x2.  I don't know if it'll help me, as I have
a pinephone pro and this driver had to be disabled to boot, to boot the phone.
The phone is at home but i'm doing research without it (I'M currently away 
from home).

If anyone has a rockchip (preferably a pinebook pro or even a pinephone pro)
that uses this driver can you test this for me?  I will get to it next week 
perhaps with the phinephone pro.  Due to thermal issues with the phone I'll 
compile on a rpi 4b before testing this.

In any case:

Index: rkanxdp.c
===
RCS file: /cvs/src/sys/dev/fdt/rkanxdp.c,v
retrieving revision 1.5
diff -u -p -u -r1.5 rkanxdp.c
--- rkanxdp.c   6 Apr 2022 18:59:28 -   1.5
+++ rkanxdp.c   16 Apr 2022 18:53:16 -
@@ -199,7 +199,7 @@ rkanxdp_ep_activate(void *cookie, struct
if (crtc == NULL)
return EINVAL;
 
-   sc->sc_encoder.possible_crtcs = 0x3; /* XXX */
+   sc->sc_encoder.possible_crtcs = 0x2; /* VOPB only */
drm_encoder_init(crtc->dev, >sc_encoder, _encoder_funcs,
DRM_MODE_ENCODER_TMDS, NULL);
drm_encoder_helper_add(>sc_encoder, _encoder_helper_funcs);

Best Regards,
-peter

Re: DANE in libressl?

[Peter J. Philipp]

On Sun, Aug 29, 2021 at 07:16:20AM -0600, Theo de Raadt wrote:
> Is there a strong reason why this has to be in that specific library?

Not really.  I did see gnutls has dane functions and openssl has them too.
I can stick to just rolling the needed functionality in the syslogd.

Noone out there is doing this already right?

Best Regards,
-peter


> Peter J. Philipp  wrote:
> 
> > Hi,
> > 
> > I was wondering if anyone has wanted to implement DANE functions into 
> > OpenBSD?
> > And LibreSSL perhaps?  I want this for syslogd with TLS, but not sure if I'd
> > be on someones toes here, if I start implementing...
> > 
> > With unwind we can make use of things such as DANE due to validation of 
> > DNSSEC.
> > 
> > Best Regards,
> > -peter
> > 

DANE in libressl?

[Peter J. Philipp]

Hi,

I was wondering if anyone has wanted to implement DANE functions into OpenBSD?
And LibreSSL perhaps?  I want this for syslogd with TLS, but not sure if I'd
be on someones toes here, if I start implementing...

With unwind we can make use of things such as DANE due to validation of DNSSEC.

Best Regards,
-peter

Re: list hyperv features in dmesg

[Peter J. Philipp]

On Mon, Jun 14, 2021 at 01:19:21PM -0700, Chris Cappuccio wrote:
[..]
> If you're going to print flags for some unsupported features, why
> not print them all? 
> 
> The 'features3' line doesn't look clean
> 
> Typically uppercase flags like this are formatted like 

OK in this next patch (below) the flags are cleaned up and print as much info
as they can (as much as FreeBSD).  I don't have Microsoft docs so this relies
on the open sources from there.  It now looks like this:

pvbus0 at mainbus0: Hyper-V 10.0
hyperv0 at pvbus0: protocol 4.0, features 0x2e7f 
hyperv0: pm features 0x2 <>
hyperv0: features3 0xbed7b2 
hyperv0: heartbeat, kvp, shutdown, timesync
hvs0 at hyperv0 channel 2: ide, protocol 6.2

In regards to features3 not looking "clean" do you mean the 3's that I had
initially put behind them to indicate that they are feature3?  Or do you mean
the register value?  For the former I cleaned that up.

> In any event, I'm not sure what benefit this brings. Doesn't 
> "hyperv0: heartbeat, kvp, shutdown, timesync" already show what features
> are in use?

This line is constructed in hv_guid_sprint() in hyperv.c, I haven't read into
them too much but I think they are general drivers that are enabled.  I don't
really know.

> I imagine it might be interesting to know what features are available but
> not in use. Is there a command-line utility that could be extended to show
> this info?

You mean in the Windows Host system or in the guest?  Either way I don't have
too much windows documentation.  I don't know any command-line utility to show 
this.

> 
> Chris

In the updated patch below I made one more change in that I moved the original
DPRINTF() into the print_hv_features() function.  Also interesting is that
hyperv0 features3 are showing "DEBUG", I wonder if it's just my machine with
this patch, and if I can turn that off somehow to gain speed.

Best Regards,
-peter

Index: hyperv.c
===
RCS file: /cvs/src/sys/dev/pv/hyperv.c,v
retrieving revision 1.48
diff -u -p -u -r1.48 hyperv.c
--- hyperv.c23 Feb 2021 04:44:31 -  1.48
+++ hyperv.c15 Jun 2021 05:08:06 -
@@ -108,6 +108,7 @@ uinthv_channel_unpause(struct hv_channe
 uint   hv_channel_ready(struct hv_channel *);
 extern void hv_attach_icdevs(struct hv_softc *);
 inthv_attach_devices(struct hv_softc *);
+void   print_hv_features(struct hv_softc *, struct pvbus_hv *);
 
 struct {
int   hmd_response;
@@ -194,6 +195,42 @@ const struct hv_guid hv_guid_kvp = {
  0xb8, 0x27, 0x8a, 0x84, 0x1e, 0x8c, 0x03, 0xe6 }
 };
 
+const struct {
+   uint32_t bit;
+   char str[16];
+} hv_cpu_features[] = {
+   { CPUID_HV_MSR_VP_RUNTIME,  "VPRUNTIME" },
+   { CPUID_HV_MSR_TIME_REFCNT, "TIME_REFCNT" },
+   { CPUID_HV_MSR_SYNIC,   "SYNIC" },
+   { CPUID_HV_MSR_SYNTIMER,"SYNTIMER" },
+   { CPUID_HV_MSR_APIC,"APIC" },
+   { CPUID_HV_MSR_HYPERCALL,   "HYPERCALL" },
+   { CPUID_HV_MSR_VP_INDEX,"VP_INDEX" },
+   { CPUID_HV_MSR_RESET,   "RESET" },
+   { CPUID_HV_MSR_STATS,   "STATS" },
+   { CPUID_HV_MSR_REF_TSC, "REF_TSC" },
+   { CPUID_HV_MSR_GUEST_IDLE,  "GUEST_IDLE" },
+   { CPUID_HV_MSR_TM_FREQ, "TM_FREQ" },
+   { CPUID_HV_MSR_DEBUG,   "DEBUG" }
+}, hv_cpu_pm_features[] = {
+   { CPUPM_HV_C3_HPET, "C3_HPET" }
+}, hv_cpu_features3[] = {
+   { CPUID3_HV_MWAIT,  "MWAIT" },
+   { CPUID3_HV_DEBUG,  "DEBUG" },
+   { CPUID3_HV_PERFMON,"PERFMON" },
+   { CPUID3_HV_PCPUDPE,"PCPUDPE" },
+   { CPUID3_HV_XMM_HYPERCALL,  "XMM_HYPERCALL" },
+   { CPUID3_HV_GUEST_IDLE, "GUEST_IDLE" },
+   { CPUID3_HV_SLEEP,  "SLEEP" },
+   { CPUID3_HV_NUMA,   "NUMA" },
+   { CPUID3_HV_TIME_FREQ,  "TIME_FREQ" },
+   { CPUID3_HV_SYNCMC, "SYNCMC" },
+   { CPUID3_HV_MSR_CRASH,  "CRASH" },
+   { CPUID3_HV_DEBUGMSR,   "DEBUGMSR" },
+   { CPUID3_HV_NPIEP,  "NPIEP" },
+   { CPUID3_HV_HVDIS,  "HVDIS" }
+};
+
 #ifdef HYPERV_DEBUG
 const struct hv_guid hv_guid_vss = {
{ 0x29, 0x2e, 0xfa, 0x35, 0x23, 0xea, 0x36, 0x42,
@@ -314,11 +351,8 @@ hv_attach(struct device *parent, struct 
if (hv_vmbus_connect(sc))
return;
 
-   DPRINTF("%s", sc->sc_dev.dv_xname);
-   printf(": protocol %d.%d, features %#x\n",
-   VMBUS_VERSION_MAJOR(sc->sc_proto),
-   VMBUS_VERSION_MINOR(sc->sc_proto),
-   hv->hv_features);
+
+   print_hv_features(sc, hv);
 
if (hv_channel_scan(sc))
return;
@@ -1830,4 +1864,32 @@ hv_evcount_attach(struct hv_channel *ch,
struct hv_softc *sc = ch->ch_sc;
 
evcount_attach(>ch_evcnt, name, >sc_idtvec);
+}
+
+void

list hyperv features in dmesg

[Peter J. Philipp]

Hi,

I may be interested in looking into hyperv since I have a MS Windows Server 2019
machine that has a hyper-v running OpenBSD (half the resources).  I have two
things that would need my attention 1. the time doesn't jump when I patch the
host OS and reboot, hyperv guest gets snapshotted at boot and sleeps while it's
off, when the system is back the time is usually off by a manner of 5 minutes
per reboot.  This I'd like to look into and I have asked Mike B. what I need
to do, his answer was that I should look at how FreeBSD do it.  2. The machine
is really slow on disk and the overlying OS uses an SSD.  I don't know the
reason but I'm wondering if it's an FS boundary issue.  Anyhow this is over
my head I think.

To start investigating the system I have added a flag for features much like
identcpu.c on amd64.  The FreeBSD equivalent is in 
sys/dev/hyperv/vmbus/hyperv.c in function hyperv_identify().

They have a lot more flags, but we don't need all until there is drivers is
what I gather, nontheless in my patch (below) I have commented out the flags
that FreeBSD has listed in their features list.  So here is how OpenBSD's
feature list looks like:

Before:
pvbus0 at mainbus0: Hyper-V 10.0
hyperv0 at pvbus0: protocol 4.0, features 0x2e7f
hyperv0: heartbeat, kvp, shutdown, timesync
hvs0 at hyperv0 channel 2: ide, protocol 6.2

After:

pvbus0 at mainbus0: Hyper-V 10.0
hyperv0 at pvbus0: protocol 4.0, features 0x2e7f TIME_REFCNT,SYNIC,SYNTIMER,APIC
,HYPERCALL,VP_INDEX,GUEST_IDLE
hyperv0: pm features 0x2 
hyperv0: features3 0xbed7b2 ,XMM_HYPERCALL3,GUEST_IDLE3,NUMA3,TIME_FREQ3
hyperv0: heartbeat, kvp, shutdown, timesync
hvs0 at hyperv0 channel 2: ide, protocol 6.2

Below is patch, what do you think?  Is it worthy?

Best Regards,
-peter

Index: hyperv.c
===
RCS file: /cvs/src/sys/dev/pv/hyperv.c,v
retrieving revision 1.48
diff -u -p -u -r1.48 hyperv.c
--- hyperv.c23 Feb 2021 04:44:31 -  1.48
+++ hyperv.c14 Jun 2021 17:17:31 -
@@ -108,6 +108,7 @@ uinthv_channel_unpause(struct hv_channe
 uint   hv_channel_ready(struct hv_channel *);
 extern void hv_attach_icdevs(struct hv_softc *);
 inthv_attach_devices(struct hv_softc *);
+void   print_hv_features(struct hv_softc *, struct pvbus_hv *);
 
 struct {
int   hmd_response;
@@ -194,6 +195,42 @@ const struct hv_guid hv_guid_kvp = {
  0xb8, 0x27, 0x8a, 0x84, 0x1e, 0x8c, 0x03, 0xe6 }
 };
 
+const struct {
+   uint32_t bit;
+   char str[16];
+} hv_cpu_features[] = {
+   /* { CPUID_HV_MSR_VP_RUNTIME,   "VPRUNTIME" }, */
+   { CPUID_HV_MSR_TIME_REFCNT, "TIME_REFCNT" },
+   { CPUID_HV_MSR_SYNIC,   "SYNIC" },
+   { CPUID_HV_MSR_SYNTIMER,"SYNTIMER" },
+   { CPUID_HV_MSR_APIC,"APIC" },
+   { CPUID_HV_MSR_HYPERCALL,   "HYPERCALL" },
+   { CPUID_HV_MSR_VP_INDEX,"VP_INDEX" },
+   /* { CPUID_HV_MSR_RESET,"RESET" }, */
+   /* { CPUID_HV_MSR_STATS,"STATS" }, */
+   /* { CPUID_HV_MSR_REFTSC,   "REFTSC" }, */
+   { CPUID_HV_MSR_GUEST_IDLE,  "GUEST_IDLE" },
+   /* { CPUID_HV_MSR_TMFREQ,   "TMFREQ" }, */
+   /* { CPUID_HV_MSR_DEBUG,"DEBUG" } */
+}, hv_cpu_pm_features[] = {
+   { CPUPM_HV_C3_HPET, "C3_HPET" }
+}, hv_cpu_features3[] = {
+   { CPUID3_HV_MWAIT,  "MWAIT3" },
+   /* { CPUID3_HV_DEBUG,   "DEBUG3" },*/
+   /* { CPUID3_HV_PERFMON, "PERFMON" }, */
+   /* { CPUID3_HV_PCPUDPE, "PCPUDPE" }, */
+   { CPUID3_HV_XMM_HYPERCALL, "XMM_HYPERCALL3" },
+   { CPUID3_HV_GUEST_IDLE, "GUEST_IDLE3" },
+   /* { CPUID3_HV_SLEEP,   "SLEEP" }, */
+   { CPUID3_HV_NUMA,   "NUMA3" },
+   { CPUID3_HV_TIME_FREQ,  "TIME_FREQ3" },
+   /* { CPUID3_HV__SYNCMC, "SYNCMC" }, */
+   /* { CPUID3_HV__CRASH,  "CRASH" }, */
+   /* { CPUID3_HV__DEBUGMSR,   "DEBUGMSR" }, */
+   /* { CPUID3_HV__NPIEP,  "NPIEP" }, */
+   /* { CPUID3_HV__HVDIS,  "HVDIS" } */
+};
+
 #ifdef HYPERV_DEBUG
 const struct hv_guid hv_guid_vss = {
{ 0x29, 0x2e, 0xfa, 0x35, 0x23, 0xea, 0x36, 0x42,
@@ -315,11 +352,13 @@ hv_attach(struct device *parent, struct 
return;
 
DPRINTF("%s", sc->sc_dev.dv_xname);
-   printf(": protocol %d.%d, features %#x\n",
+   printf(": protocol %d.%d, features %#x ",
VMBUS_VERSION_MAJOR(sc->sc_proto),
VMBUS_VERSION_MINOR(sc->sc_proto),
hv->hv_features);
 
+   print_hv_features(sc, hv);
+
if (hv_channel_scan(sc))
return;
 
@@ -1830,4 +1869,26 @@ hv_evcount_attach(struct hv_channel *ch,
struct hv_softc *sc = ch->ch_sc;
 
evcount_attach(>ch_evcnt, name, >sc_idtvec);
+}
+
+void
+print_hv_features(struct hv_softc *sc, struct pvbus_hv *hv)
+{
+   int i;
+
+   for (i = 0; i < nitems(hv_cpu_features); i++)
+   if (hv->hv_features & 

Re: uwacom: reduce tip pressure for click activation

[Peter J. Philipp]

On Thu, Jun 03, 2021 at 09:23:16PM +0200, Stefan Hagen wrote:
> Peter J. Philipp wrote:
> > On Thu, Jun 03, 2021 at 08:06:06PM +0200, Stefan Hagen wrote:
> >> Which one?
> >
> > It didn't say in the dmesg if I recall correctly, luckily I found the
> > packaging.  CTL-490 DW-S.
> 
> Same model here. I just wanted to make sure that the driver is actually 
> used in your case. It only supports this one.

I haven't drawn anything in months.  So don't let me be your stopper.  It's
good to get a third opinion, otherwise perhaps we're the only two souls using
a wacom in openbsd?  Now if people have a different idea around what pressure
setting they need perhaps there should be a wsconsctl setting for that, some
initial ioctl code is already in the driver.

> > I found it very hard to just write "This is a test" seemed harder
> > to do with your patch. The lack of pressure on the pen caused it to
> > miswrite.
> 
> Feel exactly the opposite way here.
> 
> > Maybe I'm just used to the press Hmm, well don't let me stop your
> > patch, I just wanted to give feedback on how I perceived it.
> 
> Thanks. Maybe more feedback will come.

I hope so.

> Best Regards,
> Stefan

Best Regards,
-peter

Re: uwacom: reduce tip pressure for click activation

[Peter J. Philipp]

On Thu, Jun 03, 2021 at 08:06:06PM +0200, Stefan Hagen wrote:
> Peter J. Philipp wrote:
> 
> > I have a Wacom Intuos.
> 
> Which one?

It didn't say in the dmesg if I recall correctly, luckily I found the
packaging.  CTL-490 DW-S.

> > I found that I could not write anything as good as with the pressure
> > having a higher threshold ie. the original driver.
> 
> Can you be more specific? Did you have false activations without 
> touching the tablet?

I found it very hard to just write "This is a test" seemed harder to do with
your patch.  The lack of pressure on the pen caused it to miswrite.  Maybe
I'm just used to the pressure for the pad as it is.  To make sure there was
a difference I booted the laptop with the Pad back with the original code and
did find it much easier writing.

> The pressure sensor is used because the button activation is flaky. 
> See comment in the code.
> 
> To verify this, I've taken out the pressure code and checked when button
> 0 usually activates. This correlates with pressure 1. That was another
> indicator that my patch would make the tablet behave more as it should.
> 
> > I used gimp to write with the wacom which is the utility I use to draw
> > when I do draw with the Intuos.
> 
> I'm using xournal. I tried gimp as well. Works very well for me with the
> patched setting.
> 
> I can, however, understand that when you're used to having to push hard,
> a lighter setting might feel off.
> 
> Best Regards,
> Stefan

Hmm, well don't let me stop your patch, I just wanted to give feedback on
how I perceived it.  I'm not one to recommend quirks as I know the less of
these the better, I don't know if there is a real difference between your
CTL-490 and mine, on my packaging there is one other marking it says:
CTL-490/W1-BX.

Best Regards,
-peter

Re: uwacom: reduce tip pressure for click activation

[Peter J. Philipp]

On Thu, Jun 03, 2021 at 05:10:57PM +0200, Stefan Hagen wrote:
> Hi,
> 
> I'm using a Wacom CTL-490 to draw on virtual whiteboards in online
> meetings.

Hi,

I tried your patch and got rejections, though I was able to fix it.  I have
a Wacom Intuos.  I found that I could not write anything as good as with
the pressure having a higher threshold ie. the original driver.

That said I'm on 6.9, not on -current maybe there is differences with other
drivers that have an impact.

I used gimp to write with the wacom which is the utility I use to draw
when I do draw with the Intuos.


> Compared to linux/windows, it needs a lot of pressure to draw something
> on OpenBSD. This makes writing pretty hard.
> 
> In OpenBSD, a tip-pressure of >10 is required to activate button 0.
> 
> I'm not sure why this number was chosen. I assumed that it might be 
> because pressure reporting could be jittering.
> 
> I've set it to >0 for testing and I couldn't be happier. I tested it 
> with two pens and didn't experience any false-activation.
> 
> Would this patch okay with you?
> 
> uwacom author on cc.
> 
> Best Regards,
> Stefan

Best Regards,
-peter

> 
> Index: sys/dev/usb/uwacom.c
> ===
> RCS file: /cvs/src/sys/dev/usb/uwacom.c,v
> retrieving revision 1.2
> diff -u -p -u -p -r1.2 uwacom.c
> --- sys/dev/usb/uwacom.c  23 Aug 2020 11:08:02 -  1.2
> +++ sys/dev/usb/uwacom.c  3 Jun 2021 14:40:37 -
> @@ -172,7 +172,7 @@ uwacom_intr(struct uhidev *addr, void *b
>   buttons |= (1 << i);
>  
>   /* button 0 reporting is flaky, use tip pressure for it */
> - if (pressure >10)
> + if (pressure)
>   buttons |= 1;
>   else
>   buttons &= ~1;
> 

Re: macppc bsd.mp pmap's hash lock

[Peter J. Philipp]

[cross posting this to ppc@]

On Wed, May 19, 2021 at 12:27:51AM -0400, George Koehler wrote:
> On Thu, 13 May 2021 02:20:45 -0400
> George Koehler  wrote:
> 
> > My last diff (11 May 2021) still has a potential problem with memory
> > barriers.  I will mail a new diff if I think of a fix.
> 
> Here's my new diff.  It is a copy of what I sent to ppc@ a moment ago.
> I would ask, "Is it ok to commit?", but while writing this mail, I
> found a 2nd potential problem with memory barriers, so I will need to
> edit this diff yet again.

Hi George,

I tested this patch on sources from April 27th.  The patch applied fine and
the kernel booted fine on this hardware which I'll describe to you:

hw.machine=macppc
hw.model=970FX (Revision 0x300)
hw.ncpu=2
hw.byteorder=4321
...
hw.cpuspeed=1800
hw.vendor=Apple Computer, Inc.
hw.product=PowerMac7,3
hw.physmem=2147483648
hw.usermem=2147467264
hw.ncpufound=2
hw.allowpowerdown=1
hw.ncpuonline=2

I realise I'm a little out of sync between kernel and userland now.  I'll
try everything to better this once I figure out git to bring my tree up to
-current:  https://github.com/pbug44/openbsd , without affecting what I have
for my macppc64 personal effort to bring this hardware to 64-bit OS.

Best Regards,
-peter

> I add a 2nd membar_enter() to __ppc_lock() to avoid my 1st "potential
> problem".  I also simplify the code by changing __ppc_lock_spin to
> check the owning cpu, not the count.
> 
> A moment ago, I sent a copy of this diff to ppc@, in reply to another
> report of bsd.mp hanging at "using parent ..." on a G5.  My own hang
> happened when the function __ppc_lock(), in a randomly reordered
> bsd.mp, crossed a page boundary and caused a page fault with a
> recursive call to __ppc_lock().  The goal of my diff is to prevent
> such hangs, by allowing such recursive calls to work.
> 
> I acquire the lock with an atomic 32-bit write, so the lock is always
> in a valid state before or after the write.  The old code did spin
> until mpl_count == 0.  In my earlier diffs, I acquired the lock by
> setting both the owning cpu and a nonzero count in one write, so I
> needed to pack both owner and count in a 32-bit integer.
> 
> This diff spins until mpl_cpu == NULL.  I acquire the lock by setting
> only mpl_cpu and leaving mpl_count at 0.  So mpl_cpu is the spinlock,
> and mpl_count is a variable protected by the lock.  I no longer need
> to pack both fields in a 32-bit integer, so I get rid of my BOLT*
> macros for packing and unpacking the fields.
> 
> I need 2 memory barriers:
>   1. after acquiring the lock, before accessing the locked data.
>   2. after accessing the locked data, before releasing the lock.
> 
> I added the 2nd membar_enter(), because I feared that a cpu would
> acquire the lock, but get a page fault (and recursive call) before
> it would reach the memory barrier.  I didn't think of the opposite
> case, where a cpu would do membar_exit(), but gets a page fault
> before it would release the lock.  This is the 2nd potential problem
> that I didn't fix.  I didn't observe an actual problem after running
> this diff for more than 24 hours.
> 
> --George
[..]

Re: httpd with rdomain

[Peter J. Philipp]

On Mon, May 17, 2021 at 05:55:00PM +0200, Claudio Jeker wrote:
[..]
> > Granted I did not test it with a difficult config.  And I advise any 
> > committer
> > to test this fully before trusting my code.  For me it's better than using
> > route and starting httpd twice, though.
> > 
> 
> I don't think httpd should handle rdomain in its config but instead you
> should run multiple httpd processes one for each rdomain.
> Not every daemon needs to support running in multiple rdomains at once.

OK, no worries, I did some work on this and did a simple search for someone
having done a patch like this, and there was no hits.  So the next person
at least finds this and knows. :-) And if in future you guys change your
mind you at least know one way of how it was handled by someone.

Thanks Claudio.

Cheers!
-peter

httpd with rdomain

[Peter J. Philipp]

Hi,

I found myself wanting this, this morning.  I made a patch but then I put it
in the wrong spot, and noticed it needed rewriting of SERVER in parse.y.
Later in the day I found myself looking into this, and a better patch came out
of it.  It works on a simple setup for me (mind the censored IPv6 address):

simple config>

prefork 2

server "default" {
log style combined
listen on 159.69.32.73 port 80
listen on 2a01:4f8:1c1c:89f1::1 port 80

root "/htdocs"
location "/" {
directory index index.html
}
location "/.well-known/acme-challenge/*" {
   root "/acme"
   request strip 2
}
}

server "default" rdomain 4 {
log style combined
listen on Censored port 80

root "/htdocs"
location "/" {
directory index index.html
}

location "/.well-known/acme-challenge/*" {
   root "/acme"
   request strip 2
}
}
<--

Granted I did not test it with a difficult config.  And I advise any committer
to test this fully before trusting my code.  For me it's better than using
route and starting httpd twice, though.

Patch after my signature.

Best Regards,
-peter

Index: httpd.c
===
RCS file: /cvs/src/usr.sbin/httpd/httpd.c,v
retrieving revision 1.71
diff -u -p -r1.71 httpd.c
--- httpd.c 27 Jan 2021 07:21:52 -  1.71
+++ httpd.c 17 May 2021 14:56:54 -
@@ -226,7 +226,7 @@ main(int argc, char *argv[])
if (ps->ps_noaction == 0)
log_info("startup");
 
-   if (pledge("stdio rpath wpath cpath inet dns sendfd", NULL) == -1)
+   if (pledge("stdio rpath wpath cpath inet dns sendfd wroute", NULL) == 
-1)
fatal("pledge");
 
event_init();
Index: httpd.conf.5
===
RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v
retrieving revision 1.115
diff -u -p -r1.115 httpd.conf.5
--- httpd.conf.56 Apr 2021 06:28:38 -   1.115
+++ httpd.conf.517 May 2021 14:56:54 -
@@ -143,13 +143,13 @@ Each
 section starts with a declaration of the server
 .Ar name :
 .Bl -tag -width Ds
-.It Ic server Ar name Brq ...
+.It Ic server Ar name [ Ic rdomain Ar num ] Brq ...
 Match the server name using shell globbing rules.
 This can be an explicit name,
 .Ar www.example.com ,
 or a name including wildcards,
 .Ar *.example.com .
-.It Ic server match Ar name Brq ...
+.It Ic server match Ar name  [ Ic rdomain Ar num ] Brq ...
 Match the server name using pattern matching,
 see
 .Xr patterns 7 .
Index: httpd.h
===
RCS file: /cvs/src/usr.sbin/httpd/httpd.h,v
retrieving revision 1.155
diff -u -p -r1.155 httpd.h
--- httpd.h 10 Apr 2021 10:10:07 -  1.155
+++ httpd.h 17 May 2021 14:56:54 -
@@ -487,6 +487,7 @@ struct server_config {
 
in_port_tport;
struct sockaddr_storage  ss;
+   u_intrdomain;
int  prefixlen;
struct timeval   timeout;
struct timeval   requesttimeout;
Index: parse.y
===
RCS file: /cvs/src/usr.sbin/httpd/parse.y,v
retrieving revision 1.125
diff -u -p -r1.125 parse.y
--- parse.y 10 Apr 2021 10:10:07 -  1.125
+++ parse.y 17 May 2021 14:56:54 -
@@ -120,6 +120,8 @@ int  getservice(char *);
 int is_if_in_group(const char *, const char *);
 int get_fastcgi_dest(struct server_config *, const char *, char *);
 voidremove_locations(struct server_config *);
+struct server  *serverfill(int, char *, u_int);
+int serveropts_fill(struct server *, int);
 
 typedef struct {
union {
@@ -139,7 +141,7 @@ typedef struct {
 %token LISTEN LOCATION LOG LOGDIR MATCH MAXIMUM NO NODELAY OCSP ON PORT PREFORK
 %token PROTOCOLS REQUESTS ROOT SACK SERVER SOCKET STRIP STYLE SYSLOG TCP TICKET
 %token TIMEOUT TLS TYPE TYPES HSTS MAXAGE SUBDOMAINS DEFAULT PRELOAD REQUEST
-%token ERROR INCLUDE AUTHENTICATE WITH BLOCK DROP RETURN PASS REWRITE
+%token ERROR INCLUDE AUTHENTICATE WITH BLOCK DROP RETURN PASS REWRITE RDOMAIN
 %token CA CLIENT CRL OPTIONAL PARAM FORWARDED FOUND NOT
 %token   STRING
 %token   NUMBER
@@ -222,217 +224,42 @@ main : PREFORK NUMBER{
;
 
 server : SERVER optmatch STRING{
-   struct server   *s;
-   struct sockaddr_un  *sun;
-
if (!loadcfg) {
free($3);
YYACCEPT;
}
-
-   if ((s = calloc(1, sizeof (*s))) == NULL)
-  

explicit_bzero csalt

[Peter J. Philipp]

Hi,

On IRC, someone and I were arbitrarily going through bcrypt.c and I noticed
the following resulting from bcrypt_newhash():

int
bcrypt_newhash(const char *pass, int log_rounds, char *hash, size_t hashlen)
{
char salt[BCRYPT_SALTSPACE];

if (bcrypt_initsalt(log_rounds, salt, sizeof(salt)) != 0)
return -1;
...

Here at the end salt is later explicit_bzero'd.  but inside the 
bcrypt_initsalt() function there is also an internal csalt array.

It's on the stack so it's likely overwritten, so I'm wondering if this is even
right to explicity_bzero csalt? 

I haven't tested this patch before I get someone to judge whether it's right
or wrong?

Patch follows after my sig,

Best Regards,
-peter


Index: bcrypt.c
===
RCS file: /cvs/src/lib/libc/crypt/bcrypt.c,v
retrieving revision 1.58
diff -u -p -u -r1.58 bcrypt.c
--- bcrypt.c6 Jul 2020 13:33:05 -   1.58
+++ bcrypt.c21 Jan 2021 14:26:10 -
@@ -82,6 +82,8 @@ bcrypt_initsalt(int log_rounds, uint8_t 
snprintf(salt, saltbuflen, "$2b$%2.2u$", log_rounds);
encode_base64(salt + 7, csalt, sizeof(csalt));
 
+   explicit_bzero(csalt, sizeof(csalt));
+
return 0;
 }
 

Re: acme-client(1): backup certs

[Peter J. Philipp]

On Sat, Jan 02, 2021 at 05:10:01PM -0600, Chris Bennett wrote:
> On Sat, Jan 02, 2021 at 05:23:11PM +0100, Florian Obser wrote:
> > 
> > Create .1 backup files when acme-client is going to overwrite a
> > certificate file.
> > 
> > This files are not terribly big and it's convenient to keep one
> > previous file around for example if one adds or removes domains to the
> > certificate and then wants to revoke the previous one.
> > 
> > (Note that it's kinda difficult to revoke the old certificate with
> > acme-client currently. The whole revoke machinery needs to be
> > overhauled. I have ideas...)
> > 
> > Comments, OKs?
> > 
> 
> Wait, I can have multiple, active certificates? One's that are in fact
> different, such as domain.xxx and then add www.domain.xxx in another
> certificate?
> 
> If that's the case, then couldn't someone steal the old or new one and
> use that to cause problems?
> Especially since DNS servers can take up to 48 hours to propagate changes
> So getting rid of www.domain.xxx might not show up quickly enough.
> And if I change IP addresses and they don't get propagated soon enough,
> wouldn't someone be able to briefly spoof my site?
> DNS servers in some places I have been to, do in fact have failures.
> 
> If I understand this correctly (perhaps not), this seems like a major
> security problem with DNS. Especially if my spoofed site sends people to
> another site that they then bookmark.

Hi,

Yes you can have multiple certs, I have a few.

The spoofing couldn't happen if you used DNSSEC.  However if you used DNSSEC
that means you have to keep your keys on the DNS Server, in order to sign the
domain with acme-client info, which you have to be comfortable with.  If they 
get stolen, then you have to change the keys and your domains will be 
temporarely insecure and subject to spoofing again.

Regarding to the "propagation time" you should keep your TTL's low in that case,
I think.  That is not always wanted.  Luckily you have the choice to use the
DNS vs. the HTTP method.  I think it's good you went into a deep thought about
this, as it makes everyone think how to refine the process of getting let's
encrypt certs.

> Chris Bennett

Best Regards,
-peter

Re: AUDIORECDEVICE environment variable in sndio lib

[Peter J. Philipp]

Sorry I apologize, I had my kern.audio.record set to 0.  It works for me.

*red faced*

-peter

On Wed, Nov 18, 2020 at 04:12:25PM +0100, Peter J. Philipp wrote:
> On Wed, Nov 18, 2020 at 11:00:17AM +0100, Alexandre Ratchov wrote:
> > Thanks; semarie suggested a similar diff, so below is an attempt to
> > take into account all the suggestions:
> > 
> > - add AUDIOPLAYDEVICE, to handle play-only devices as well. We've the
> >   very same problem for them.
> > 
> > - use AUDIODEVICE if play-only (rec-only) mode is used but the
> >   corresponding AUDIOPLAYDEVICE (AUDIORECDEVICE) var is not defined
> > 
> > - minimal update for AUDIO{PLAY,REC}DEVICE in the man page
> > 
> > OK?
> 
> This stopped working for me today when I tested it.  My box saw a reboot
> though.
> 
> :-(
> 
> I used AUDIOPLAYDEVICE=snd/0 AUDIORECDEVICE=snd/1 audacity
> 
> also
>   AUDIODEVICE=snd/0 AUDIORECDEVICE=snd/1 audacity
> 
> I'm looking over the code a little, but I can't guarantee I'll find what's
> wrong.
> 
> Best Regards,
> 
> -peter
> 
> 
> 
> > Index: sio.c
> > ===
> > RCS file: /cvs/src/lib/libsndio/sio.c,v
> > retrieving revision 1.24
> > diff -u -p -r1.24 sio.c
> > --- sio.c   29 Jun 2019 06:05:26 -  1.24
> > +++ sio.c   18 Nov 2020 09:49:24 -
> > @@ -52,7 +52,12 @@ sio_open(const char *str, unsigned int m
> > if (str == NULL) /* backward compat */
> > str = devany;
> > if (strcmp(str, devany) == 0 && !issetugid()) {
> > -   str = getenv("AUDIODEVICE");
> > +   if ((mode & SIO_PLAY) == 0)
> > +   str = getenv("AUDIORECDEVICE");
> > +   if ((mode & SIO_REC) == 0)
> > +   str = getenv("AUDIOPLAYDEVICE");
> > +   if (mode == (SIO_PLAY | SIO_REC) || str == NULL)
> > +   str = getenv("AUDIODEVICE");
> > if (str == NULL)
> > str = devany;
> > }
> > Index: sndio.7
> > ===
> > RCS file: /cvs/src/lib/libsndio/sndio.7,v
> > retrieving revision 1.24
> > diff -u -p -r1.24 sndio.7
> > --- sndio.7 18 Jul 2020 05:01:14 -  1.24
> > +++ sndio.7 18 Nov 2020 09:49:24 -
> > @@ -151,9 +151,11 @@ If
> >  .Cm default
> >  is used as the audio device, the program will use the
> >  one specified in the
> > -.Ev AUDIODEVICE
> > -environment variable.
> > -If it is not set, the program first tries to connect to
> > +.Ev AUDIODEVICE , AUDIOPLAYDEVICE
> > +and/or
> > +.Ev AUDIORECDEVICE
> > +environment variables.
> > +If they are not set, the program first tries to connect to
> >  .Li snd/0 .
> >  If that fails, it then tries to use
> >  .Li rsnd/0 .
> > @@ -190,10 +192,20 @@ and contains 128 bits of raw random data
> >  If a session needs to be shared between multiple users, they
> >  can connect to the server using the same cookie.
> >  .Sh ENVIRONMENT
> > -.Bl -tag -width "AUDIODEVICEXXX" -compact
> > +.Bl -tag -width "AUDIOPLAYDEVICE" -compact
> >  .It Ev AUDIODEVICE
> >  Audio device descriptor to use
> >  when no descriptor is explicitly specified to a program.
> > +.It Ev AUDIOPLAYDEVICE
> > +Audio device descriptor to use for play-only mode
> > +when no descriptor is explicitly specified to a program.
> > +Overrides
> > +.Ev AUDIODEVICE .
> > +.It Ev AUDIORECDEVICE
> > +Audio device descriptor to use for record-only mode
> > +when no descriptor is explicitly specified to a program.
> > +Overrides
> > +.Ev AUDIODEVICE .
> >  .It Ev MIDIDEVICE
> >  MIDI port descriptor to use
> >  when no descriptor is explicitly specified to a program.
> 

Re: AUDIORECDEVICE environment variable in sndio lib

[Peter J. Philipp]

On Wed, Nov 18, 2020 at 11:00:17AM +0100, Alexandre Ratchov wrote:
> Thanks; semarie suggested a similar diff, so below is an attempt to
> take into account all the suggestions:
> 
> - add AUDIOPLAYDEVICE, to handle play-only devices as well. We've the
>   very same problem for them.
> 
> - use AUDIODEVICE if play-only (rec-only) mode is used but the
>   corresponding AUDIOPLAYDEVICE (AUDIORECDEVICE) var is not defined
> 
> - minimal update for AUDIO{PLAY,REC}DEVICE in the man page
> 
> OK?

This stopped working for me today when I tested it.  My box saw a reboot
though.

:-(

I used AUDIOPLAYDEVICE=snd/0 AUDIORECDEVICE=snd/1 audacity

also
AUDIODEVICE=snd/0 AUDIORECDEVICE=snd/1 audacity

I'm looking over the code a little, but I can't guarantee I'll find what's
wrong.

Best Regards,

-peter



> Index: sio.c
> ===
> RCS file: /cvs/src/lib/libsndio/sio.c,v
> retrieving revision 1.24
> diff -u -p -r1.24 sio.c
> --- sio.c 29 Jun 2019 06:05:26 -  1.24
> +++ sio.c 18 Nov 2020 09:49:24 -
> @@ -52,7 +52,12 @@ sio_open(const char *str, unsigned int m
>   if (str == NULL) /* backward compat */
>   str = devany;
>   if (strcmp(str, devany) == 0 && !issetugid()) {
> - str = getenv("AUDIODEVICE");
> + if ((mode & SIO_PLAY) == 0)
> + str = getenv("AUDIORECDEVICE");
> + if ((mode & SIO_REC) == 0)
> + str = getenv("AUDIOPLAYDEVICE");
> + if (mode == (SIO_PLAY | SIO_REC) || str == NULL)
> + str = getenv("AUDIODEVICE");
>   if (str == NULL)
>   str = devany;
>   }
> Index: sndio.7
> ===
> RCS file: /cvs/src/lib/libsndio/sndio.7,v
> retrieving revision 1.24
> diff -u -p -r1.24 sndio.7
> --- sndio.7   18 Jul 2020 05:01:14 -  1.24
> +++ sndio.7   18 Nov 2020 09:49:24 -
> @@ -151,9 +151,11 @@ If
>  .Cm default
>  is used as the audio device, the program will use the
>  one specified in the
> -.Ev AUDIODEVICE
> -environment variable.
> -If it is not set, the program first tries to connect to
> +.Ev AUDIODEVICE , AUDIOPLAYDEVICE
> +and/or
> +.Ev AUDIORECDEVICE
> +environment variables.
> +If they are not set, the program first tries to connect to
>  .Li snd/0 .
>  If that fails, it then tries to use
>  .Li rsnd/0 .
> @@ -190,10 +192,20 @@ and contains 128 bits of raw random data
>  If a session needs to be shared between multiple users, they
>  can connect to the server using the same cookie.
>  .Sh ENVIRONMENT
> -.Bl -tag -width "AUDIODEVICEXXX" -compact
> +.Bl -tag -width "AUDIOPLAYDEVICE" -compact
>  .It Ev AUDIODEVICE
>  Audio device descriptor to use
>  when no descriptor is explicitly specified to a program.
> +.It Ev AUDIOPLAYDEVICE
> +Audio device descriptor to use for play-only mode
> +when no descriptor is explicitly specified to a program.
> +Overrides
> +.Ev AUDIODEVICE .
> +.It Ev AUDIORECDEVICE
> +Audio device descriptor to use for record-only mode
> +when no descriptor is explicitly specified to a program.
> +Overrides
> +.Ev AUDIODEVICE .
>  .It Ev MIDIDEVICE
>  MIDI port descriptor to use
>  when no descriptor is explicitly specified to a program.

Re: AUDIORECDEVICE environment variable in sndio lib

[Peter J. Philipp]

On Tue, Nov 17, 2020 at 05:09:28PM +, Stuart Henderson wrote:
> On 2020/11/17 17:13, Peter J. Philipp wrote:
> > Hi,
> > 
> > I have a mic on snd/1 and speakers on snd/0.  I had tried a lot of different
> > settings with audacity port but couldn't get this to work, so I chose the
> > method of last resort.  Below is a patch to allow an AUDIORECDEVICE 
> > environment
> > variable specifying the wanted microphone.
> 
> This seems a worthwhile addition.
> 
> > Index: sio.c
> > ===
> > RCS file: /cvs/src/lib/libsndio/sio.c,v
> > retrieving revision 1.24
> > diff -u -p -u -r1.24 sio.c
> > --- sio.c   29 Jun 2019 06:05:26 -  1.24
> > +++ sio.c   17 Nov 2020 16:13:04 -
> > @@ -43,6 +43,7 @@ sio_open(const char *str, unsigned int m
> >  {
> > static char devany[] = SIO_DEVANY;
> > struct sio_hdl *hdl;
> > +   char *rec = NULL;
> >  
> >  #ifdef DEBUG
> > _sndio_debug_init();
> > @@ -55,6 +56,12 @@ sio_open(const char *str, unsigned int m
> > str = getenv("AUDIODEVICE");
> > if (str == NULL)
> > str = devany;
> > +   rec = getenv("AUDIORECDEVICE");
> > +   if (rec == NULL)
> > +   rec = devany;
> > +
> > +   if (rec && mode == SIO_REC)
> > +   str = rec;
> 
> If AUDIORECDEVICE is unset, it would be better to fallback to
> AUDIODEVICE rather than directly to devany.

This is a good suggestion!  Thanks!  I have updated the patch.  I also
appreciate Solene's offer for manpage addition, thanks!

New diff follows... let me know if it can be done better, I won't be able
to update it until tomorrow.

-peter

Index: sio.c
===
RCS file: /cvs/src/lib/libsndio/sio.c,v
retrieving revision 1.24
diff -u -p -u -r1.24 sio.c
--- sio.c   29 Jun 2019 06:05:26 -  1.24
+++ sio.c   17 Nov 2020 17:18:57 -
@@ -43,6 +43,7 @@ sio_open(const char *str, unsigned int m
 {
static char devany[] = SIO_DEVANY;
struct sio_hdl *hdl;
+   char *rec = NULL;
 
 #ifdef DEBUG
_sndio_debug_init();
@@ -55,6 +56,12 @@ sio_open(const char *str, unsigned int m
str = getenv("AUDIODEVICE");
if (str == NULL)
str = devany;
+   rec = getenv("AUDIORECDEVICE");
+   if (rec == NULL)
+   rec = str;
+
+   if (rec && mode == SIO_REC)
+   str = rec;
}
if (strcmp(str, devany) == 0) {
hdl = _sio_aucat_open("snd/0", mode, nbio);
Index: sioctl.c
===
RCS file: /cvs/src/lib/libsndio/sioctl.c,v
retrieving revision 1.1
diff -u -p -u -r1.1 sioctl.c
--- sioctl.c26 Feb 2020 13:53:58 -  1.1
+++ sioctl.c17 Nov 2020 17:18:57 -
@@ -28,6 +28,7 @@ sioctl_open(const char *str, unsigned in
 {
static char devany[] = SIO_DEVANY;
struct sioctl_hdl *hdl;
+   char *rec = NULL;
 
 #ifdef DEBUG
_sndio_debug_init();
@@ -38,6 +39,14 @@ sioctl_open(const char *str, unsigned in
str = getenv("AUDIODEVICE");
if (str == NULL)
str = devany;
+   
+   rec = getenv("AUDIORECDEVICE");
+   if (rec == NULL)
+   rec = str;
+   
+   if (rec && mode == SIO_REC)
+   str = rec;
+   
}
if (strcmp(str, devany) == 0) {
hdl = _sioctl_aucat_open("snd/0", mode, nbio);

AUDIORECDEVICE environment variable in sndio lib

[Peter J. Philipp]

Hi,

I have a mic on snd/1 and speakers on snd/0.  I had tried a lot of different
settings with audacity port but couldn't get this to work, so I chose the
method of last resort.  Below is a patch to allow an AUDIORECDEVICE environment
variable specifying the wanted microphone.

-peter


Index: sio.c
===
RCS file: /cvs/src/lib/libsndio/sio.c,v
retrieving revision 1.24
diff -u -p -u -r1.24 sio.c
--- sio.c   29 Jun 2019 06:05:26 -  1.24
+++ sio.c   17 Nov 2020 16:13:04 -
@@ -43,6 +43,7 @@ sio_open(const char *str, unsigned int m
 {
static char devany[] = SIO_DEVANY;
struct sio_hdl *hdl;
+   char *rec = NULL;
 
 #ifdef DEBUG
_sndio_debug_init();
@@ -55,6 +56,12 @@ sio_open(const char *str, unsigned int m
str = getenv("AUDIODEVICE");
if (str == NULL)
str = devany;
+   rec = getenv("AUDIORECDEVICE");
+   if (rec == NULL)
+   rec = devany;
+
+   if (rec && mode == SIO_REC)
+   str = rec;
}
if (strcmp(str, devany) == 0) {
hdl = _sio_aucat_open("snd/0", mode, nbio);
Index: sioctl.c
===
RCS file: /cvs/src/lib/libsndio/sioctl.c,v
retrieving revision 1.1
diff -u -p -u -r1.1 sioctl.c
--- sioctl.c26 Feb 2020 13:53:58 -  1.1
+++ sioctl.c17 Nov 2020 16:13:04 -
@@ -28,6 +28,7 @@ sioctl_open(const char *str, unsigned in
 {
static char devany[] = SIO_DEVANY;
struct sioctl_hdl *hdl;
+   char *rec = NULL;
 
 #ifdef DEBUG
_sndio_debug_init();
@@ -38,6 +39,14 @@ sioctl_open(const char *str, unsigned in
str = getenv("AUDIODEVICE");
if (str == NULL)
str = devany;
+   
+   rec = getenv("AUDIORECDEVICE");
+   if (rec == NULL)
+   rec = devany;
+   
+   if (rec && mode == SIO_REC)
+   str = rec;
+   
}
if (strcmp(str, devany) == 0) {
hdl = _sioctl_aucat_open("snd/0", mode, nbio);

Re: ssh(1), getrrsetbyname(3), SSHFP and DNSSEC

[Peter J. Philipp]

On Wed, Jul 29, 2020 at 05:42:16PM +0200, Florian Obser wrote:
> > First you mention fallback to DHCP-learned resolvers.  Those you should
> > probably not trust indeed, but it looks like unwind(8) attempts to use
> > them to perform its own validation.  So the value of the AD flag in
> > unwind(8)'s response should be trustworthy.  At least that's what I see
> > when I test unwind with "preference { dhcp }".
> >
> 
> unwind always does its own validation or decides it can't do
> validation. In both cases you can trust the AD flag.
> The AD flag is set if and only if unwind did a successful validation.
> 
> You cannot trust the RCODE (and answer) when AD is *NOT* set. That
> seems like a strange and obvious statement but it is the main
> difference to validating unbound. When you enable validation in
> unbound and someone messes with your packets you will get a SERVFAIL.

Hi all,

I just put unwind on my own forwarding dns server and you can see what it does
in the following logs (I like it!):

--- here I restarted unwind, it looks up the root zone ---
Jul 29 18:06:19 eta delphinusdnsd[56662]: request on descriptor 16 interface \
"cnmac1" from 192.168.177.2 (ttl=64, region=255, tta=1.291ms) for "." \
type=NS(2) class=1, edns0, dnssecok, answering "FORWARD" (28/83)
 
Jul 29 18:06:19 eta delphinusdnsd[56662]: request on descriptor 16 interface \
"cnmac1" from 192.168.177.2 (ttl=64, region=255, tta=1.486ms) for "." \
type=DNSKEY(48) class=1, edns0, dnssecok, answering "FORWARD" (28/83)

Jul 29 18:06:19 eta delphinusdnsd[56662]: request on descriptor 16 interface \
"cnmac1" from 192.168.177.2 (ttl=64, region=255, tta=1.286ms) for "." \
type=DNSKEY(48) class=1, edns0, dnssecok, answering "FORWARD" (28/83)

 it now has the anchor keys to check that these dnskeys are right 

 at this point I did a ping of centroid.eu -

Jul 29 18:07:00 eta delphinusdnsd[56662]: request on descriptor 16 interface \
"cnmac1" from 192.168.177.2 (ttl=64, region=255, tta=1.347ms) for \
"centroid.eu." type=A(1) class=1, edns0, dnssecok, answering "FORWARD" (40/83)

--- it then proceeds to check the eu. DS and DNSKEY to do DNSSEC validation ---

Jul 29 18:07:00 eta delphinusdnsd[56662]: request on descriptor 16 interface \
"cnmac1" from 192.168.177.2 (ttl=64, region=255, tta=1.358ms) for "eu." \
type=DS(43) class=1, edns0, dnssecok, answering "FORWARD" (31/83)

Jul 29 18:07:00 eta delphinusdnsd[56662]: request on descriptor 16 interface \
"cnmac1" from 192.168.177.2 (ttl=64, region=255, tta=1.289ms) for "eu." \
type=DNSKEY(48) class=1, edns0, dnssecok, answering "FORWARD" (31/83)

Jul 29 18:07:00 eta delphinusdnsd[56662]: request on descriptor 16 interface \
"cnmac1" from 192.168.177.2 (ttl=64, region=255, tta=1.292ms) for \
"centroid.eu." type=DS(43) class=1, edns0, dnssecok, answering "FORWARD" (40/83)

Jul 29 18:07:00 eta delphinusdnsd[56662]: request on descriptor 16 interface \
"cnmac1" from 192.168.177.2 (ttl=64, region=255, tta=1.346ms) for \
"centroid.eu." type=DNSKEY(48) class=1, edns0, dnssecok, answering "FORWARD" \
(40/83)

--- at this point the DNSSEC validation reverse walk is complete 

Here is the unwind .conf file I used on my network:

forwarder 192.168.177.1
preference forwarder

And here is some attempt at explaining the delphinusdnsd log format:
https://delphinusdns.org/blog/c?article=1568367256

The log FORWARD is new, it just means that delphinusdnsd gives off the
question to its own forwarding engine that forwards the request.  My setup
is as follows (in terms of dns servers):

unwind[1]->delphinusdnsd forwarder[2]->delphinusdnsd forwarder[3]->unbound[4]

The path between [2] and [3] is a secure TSIG channel on another port than 53.
[2] has a cache, [3] does not.

I assume unwind also has a cache?

Unbound does give the AD bit back here, though that's not in my logs.  I know
this though because of dnssecok and edns0 bits on the question in delphinusdnsd 
it is passed forwards.  I know also that unwind would get the AD flag here,

It is just like Florian describes it.  unwind does validation despite the AD
flag.  This is awesome!

I think I'll keep this setup for a while it can't hurt.  Ultimately I'd love
to get rid of [3] and [4] in this setup and have [2] use the ISP's powerdns
nameservers.  But [2] sits at my gateway (a little octeon USG) and can't get
the nameservers from the pppoe0 without a patch.  Because maintaining patches
that don't come with OpenBSD get discarded and overrun eventually I can only
point to the patch I sent about a month ago to tech@ that brings Gerhard
Roth's patch up to the times (but I broke it in some way, so it would need to
be fixed up a little).  I would really like to see this functionality in
OpenBSD for modifying this little setup above, *pretty please?* :)

Thanks guys for the great work and interesting discussion!

-peter

Re: ssh(1), getrrsetbyname(3), SSHFP and DNSSEC

[Peter J. Philipp]

On Fri, Jul 17, 2020 at 11:45:22PM +0200, Jesper Wallin wrote:
> Thoughts?
> 
> 
> Yours,
> Jesper Wallin

I found this very interesting.  Too bad you didn't quote any RFC's that
support this behaviour because RFC 4033 says you shouldn't set the AD bit
in a query, RFC 4035 says something similar, but then digging some further
in RFC 6840 (internet standard) it says in section 5.7:

5.7.  Setting the AD Bit on Queries

   The semantics of the Authentic Data (AD) bit in the query were
   previously undefined.  Section 4.6 of [RFC4035] instructed resolvers
   to always clear the AD bit when composing queries.

   This document defines setting the AD bit in a query as a signal
   indicating that the requester understands and is interested in the
   value of the AD bit in the response.  This allows a requester to
   indicate that it understands the AD bit without also requesting
   DNSSEC data via the DO bit.

I just wanted to add this as a thought supporting your patch.

Best Regards,
-peter

DNS options for sppp(4)

[Peter J. Philipp]

Hello,

This is an old patch from Gerhard Roth, and mpf@ dating back to 2007.  Please
see:  https://marc.info/?l=openbsd-tech=134943767022961=2

I contacted Gerhard who said instead of begging for this I should make it
IPv6 capable.  So I tried and nearly flooded my ISP off the net (sorry),
it seems that there is no IPV6CP capabilities for this yet.  I googled and
found a few drafts but all said the protocol number is TBD.  Also I looked
on IANA.org https://www.iana.org/assignments/ppp-numbers/ppp-numbers.xhtml
and found no official IPV6CP specification.

I'm submitting this patch because I have a need for DNS servers as my ISP
does not give these out via official support channels.  So I'm relying on
either using a public resolver (such as 8.8.8.8) or unwind.  No offence to 
unwind but I'd rather use these ISP nameservers if I knew where to get them.
I have also made a forwarding feature on my authoritative nameserver (with
caching) and would write the code to automatically configure on startup to
automatically determined pppoe(4) nameservers.  So this is the self pitch.

Patch is below with lots of #if 0, that I'd clean up if it passes the
political hurdles.  Also I have no -current on me currently so this is all
against 6.7.  I understand there is wireguard code in ifconfig and I'd have
to bite the bullet and sysupgrade a machine here to make new new patch
fit.  I just need an OK from someone and I'll clean it up otherwise I 
won't do anymore work on this subject.  Patch after my signature:

Best Regards,
-peter


Index: ifconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.421
diff -u -p -u -r1.421 ifconfig.c
--- ifconfig.c  27 Feb 2020 08:28:35 -  1.421
+++ ifconfig.c  6 Jul 2020 17:09:49 -
@@ -690,6 +690,7 @@ u_int   getwpacipher(const char *);
 void   print_cipherset(u_int32_t);
 
 void   spppauthinfo(struct sauthreq *, int);
+void   spppdnsinfo(struct sdnsreq *);
 
 /* Known address families */
 const struct afswtch {
@@ -5401,6 +5402,17 @@ spppauthinfo(struct sauthreq *spa, int d
 }
 
 void
+spppdnsinfo(struct sdnsreq *spd)
+{
+   bzero(spd, sizeof(struct sdnsreq));
+   
+   ifr.ifr_data = (caddr_t)spd;
+   spd->cmd = SPPPIOGDNS;
+   if (ioctl(sock, SIOCGSARAMS, ) == -1)
+   err(1, "SIOCGSARAMS(SPPPIOGDNS)");
+}
+
+void
 setsroto(const char *val, int d)
 {
struct sauthreq spa;
@@ -5534,6 +5546,11 @@ sppp_status(void)
 {
struct spppreq spr;
struct sauthreq spa;
+   struct sdnsreq spd;
+   struct sockaddr_storage *ss = NULL;
+
+   char buf[INET6_ADDRSTRLEN];
+   int i;
 
bzero(, sizeof(spr));
 
@@ -5573,6 +5590,39 @@ sppp_status(void)
if (spa.flags & AUTHFLAG_NORECHALLENGE)
printf("norechallenge ");
putchar('\n');
+
+   spppdnsinfo();
+   for (i = 0; i < 2; i++) {
+   ss = (struct sockaddr_storage *)_dns[i];
+   if (ss->ss_family == AF_UNSPEC)
+   continue;
+
+   switch (i) {
+   case 0:
+   inet_ntop(AF_INET, &((struct sockaddr_in 
*)ss)->sin_addr.s_addr,
+   buf, sizeof(buf));
+   printf("\tipcp pri_dns: %s\n", buf);
+   break;
+   case 1:
+   inet_ntop(AF_INET, &((struct sockaddr_in 
*)ss)->sin_addr.s_addr,
+   buf, sizeof(buf));
+   printf("\tipcp sec_dns: %s\n", buf);
+   break;
+#if notyet
+   case 2:
+   inet_ntop(AF_INET6, &((struct sockaddr_in6 
*)ss)->sin6_addr,
+   buf, sizeof(buf));
+   printf("\tpri_dns6: %s\n", buf);
+   break;
+   case 3:
+   inet_ntop(AF_INET6, &((struct sockaddr_in6 
*)ss)->sin6_addr,
+   buf, sizeof(buf));
+   printf("\tsec_dns6: %s\n", buf);
+   break;
+#endif
+   }
+   }
+
 }
 
 void
Index: if_sppp.h
===
RCS file: /cvs/src/sys/net/if_sppp.h,v
retrieving revision 1.27
diff -u -p -u -r1.27 if_sppp.h
--- if_sppp.h   24 Jun 2019 21:36:53 -  1.27
+++ if_sppp.h   6 Jul 2020 17:12:27 -
@@ -82,12 +82,18 @@ struct spppreq {
enum ppp_phase phase;   /* phase we're currently in */
 };
 
+struct sdnsreq {
+   int cmd;
+   struct sockaddr_storage ss_dns[4];
+};
+
 #define SPPPIOGDEFS  ((int)(('S' << 24) + (1 << 16) + sizeof(struct spppreq)))
 #define SPPPIOSDEFS  ((int)(('S' << 24) + (2 << 16) + sizeof(struct spppreq)))
 #define SPPPIOGMAUTH ((int)(('S' << 24) + (3 << 16) + sizeof(struct sauthreq)))
 #define SPPPIOSMAUTH ((int)(('S' << 24) + (4 << 16) + sizeof(struct sauthreq)))
 

Re: powerpc: mplock & WITNESS

[Peter J. Philipp]

On Thu, Apr 09, 2020 at 10:58:29PM -0400, George Koehler wrote:



> In the trace, #0 and #1 are wrong, but the rest of the trace looks
> good enough for WITNESS.  I added an artificial lock order reversal to
> ums(4) for WITNESS to catch.  I got this trace,
> 
> #0  0xe4d764   
> #1  witness_checkorder+0x308
> #2  mtx_enter+0x50  
> #3  ums_attach+0x68 
> #4  config_attach+0x270
> ...
> 
> "#0  0xe4d764" is stack garbage: a function saves its lr in its
> caller's frame, but stacktrace_save_at() first reads the lr slot in
> its own frame.

I wonder if this is the stack to stacktrace_save()?  Would sprinkling
__inline's at the function declaration help that any?


> "#1  witness_checkorder+0x308" is a dead value.  In the disassembly
> (objdump -dlr db_trace.o), clang optimized stacktrace_save_at() to
> skip saving its lr on the stack, because it is a leaf function (that
> never calls other functions).  The lr from the stack isn't the return
> address for stacktrace_save_at(), but might be a leftover return
> address from some other function (that needed to save lr).

I'm gonna boot my G5 in a sec (which I'm considering renaming tractor or 
jetengine) so that I can see that too.  I also haven't had a witness event
yet hoping on that in a second.

> #2 and after seem to be correct; "#3  ums_attach+0x68" points exactly
> to where I am grabbing the second lock.  This is enough for WITNESS,
> so we might want to use your diff now, and fix #0 and #1 later.
> 
> Also know that a compiler may optimize stacktrace_save_at() to have
> no stack frame.  Our clang 8.0.1 never does this (because it always
> sets r31 = stack pointer r1, so it always needs a stack frame to save
> the caller's r31), but gcc and newer clang might.  I don't know how
> __builtin_frame_address(0) works if the stack frame is gone.

Oh then __inline perhaps wouldn't work?


> --George
> 

Great debug George!  Thanks!

Best Regards,
-peter

Re: powerpc: mplock & WITNESS

[Peter J. Philipp]

On Thu, Apr 09, 2020 at 01:08:12PM +0200, Martin Pieuchot wrote:
> On 09/04/20(Thu) 12:20, Peter J. Philipp wrote:
> > It's April 9th for me, so no chance for April 1st things.  Both patches 
> > didn't
> > boot (they loaded on ofwboot though) for me.  I assume you wanted me to 
> > enable
> > WITNESS option which I did.  The kernel did not print anything so it must 
> > have
> > done something before openfirmware...
> 
> Do they boot without WITNESS?  They might be other issues to address.

Just an update to list.

GENERIC.MP without WITNESS - did not boot
GENERIC without WITNESS - did boot
GENERIC with WITNESS - panic'ed on boot.

It took some time determining if GENERIC.MP was compiled right.  After newfs
of /usr/{obj,src}, cvs update and patching the info above was gathered.

I have provided Martin a screenshot jpg of the panic on boot.  If you want
it let me know.

Best Regards,
-peter

Re: powerpc: mplock & WITNESS

[Peter J. Philipp]

It's April 9th for me, so no chance for April 1st things.  Both patches didn't
boot (they loaded on ofwboot though) for me.  I assume you wanted me to enable
WITNESS option which I did.  The kernel did not print anything so it must have
done something before openfirmware...

I'm going to check out my sources anew perhaps there was a something amiss,
compiling takes a while on a G5.

Best Regards,
-peter

On Thu, Apr 09, 2020 at 11:09:02AM +0200, Martin Pieuchot wrote:
> On 09/04/20(Thu) 10:53, Mark Kettenis wrote:
> > > Date: Thu, 9 Apr 2020 10:01:09 +0200
> > > From: Martin Pieuchot 
> > > [...]
> > > + lastsp = sp;
> > > + sp = *(vaddr_t *)sp;
> > > +
> > > + if ((sp == 0) || (sp <= lastsp))
> > > + break;
> > 
> > I think checking the alignment of sp here like you do for lr would be
> > a good idea.  Otherwise an unaligned access might happen.  Since
> > powerpc uses separate interrupt stacks, the (sp <= lastsp) check might
> > truncate the stack trace.
> 
> Something like in the diff below?
> 
> Index: arch/powerpc/conf/files.powerpc
> ===
> RCS file: /cvs/src/sys/arch/powerpc/conf/files.powerpc,v
> retrieving revision 1.55
> diff -u -p -r1.55 files.powerpc
> --- arch/powerpc/conf/files.powerpc   25 Jan 2018 15:06:29 -  1.55
> +++ arch/powerpc/conf/files.powerpc   9 Apr 2020 07:38:37 -
> @@ -13,7 +13,6 @@ filearch/powerpc/powerpc/process_machde
>  file arch/powerpc/powerpc/sys_machdep.c
>  file arch/powerpc/powerpc/trap.c
>  file arch/powerpc/powerpc/vm_machdep.c
> -file arch/powerpc/powerpc/lock_machdep.c multiprocessor
>  file arch/powerpc/powerpc/intr.c
>  file arch/powerpc/powerpc/softintr.c
>  
> Index: arch/powerpc/ddb/db_trace.c
> ===
> RCS file: /cvs/src/sys/arch/powerpc/ddb/db_trace.c,v
> retrieving revision 1.14
> diff -u -p -r1.14 db_trace.c
> --- arch/powerpc/ddb/db_trace.c   7 Nov 2019 16:08:08 -   1.14
> +++ arch/powerpc/ddb/db_trace.c   9 Apr 2020 09:07:17 -
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> @@ -221,4 +222,39 @@ db_stack_trace_print(db_expr_t addr, int
>   --count;
>   }
>   (*pr)("end trace frame: 0x%lx, count: %d\n", sp, count);
> +}
> +
> +void
> +stacktrace_save_at(struct stacktrace *st, unsigned int skip)
> +{
> + vaddr_t  lr, sp, lastsp;
> +
> + sp = (vaddr_t)__builtin_frame_address(0);
> + KASSERT(INKERNEL(sp) || ININTSTK(sp));
> +
> + st->st_count = 0;
> + while (st->st_count < STACKTRACE_MAX) {
> + lr = *(vaddr_t *)(sp + 4) - 4;
> + if (lr & 3)
> + break;
> +
> + if (skip == 0)
> + st->st_pc[st->st_count++] = lr;
> + else
> + skip--;
> +
> + lastsp = sp;
> + sp = *(vaddr_t *)sp;
> +
> + if ((sp == 0) || (sp & 3) || (sp <= lastsp))
> + break;
> + if (!INKERNEL(sp) && !ININTSTK(sp))
> + break;
> + }
> +}
> +
> +void
> +stacktrace_save(struct stacktrace *st)
> +{
> + return stacktrace_save_at(st, 0);
>  }
> Index: arch/powerpc/include/mplock.h
> ===
> RCS file: /cvs/src/sys/arch/powerpc/include/mplock.h,v
> retrieving revision 1.3
> diff -u -p -r1.3 mplock.h
> --- arch/powerpc/include/mplock.h 4 Dec 2017 09:51:03 -   1.3
> +++ arch/powerpc/include/mplock.h 9 Apr 2020 07:37:25 -
> @@ -1,52 +1,10 @@
>  /*   $OpenBSD: mplock.h,v 1.3 2017/12/04 09:51:03 mpi Exp $  */
>  
> -/*
> - * Copyright (c) 2004 Niklas Hallqvist.  All rights reserved.
> - *
> - * Redistribution and use in source and binary forms, with or without
> - * modification, are permitted provided that the following conditions
> - * are met:
> - * 1. Redistributions of source code must retain the above copyright
> - *notice, this list of conditions and the following disclaimer.
> - * 2. Redistributions in binary form must reproduce the above copyright
> - *notice, this list of conditions and the following disclaimer in the
> - *documentation and/or other materials provided with the distribution.
> - *
> - * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
> - * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
> - * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
> - * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
> - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> - * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> - * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> - * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> 

arm64 mainbus.c patch

[Peter J. Philipp]

Hi,

While code-reading the riscv64 port (which leans on some arm64 code), I have
found a small gotcha in /sys/arch/arm64/dev/mainbus.c.  The patch is self
explanatory and leans on the fix from simplebus.c line 210.


Index: mainbus.c
===
RCS file: /cvs/src/sys/arch/arm64/dev/mainbus.c,v
retrieving revision 1.15
diff -u -p -u -r1.15 mainbus.c
--- mainbus.c   23 Oct 2019 09:27:43 -  1.15
+++ mainbus.c   9 Apr 2020 07:02:13 -
@@ -220,7 +220,7 @@ mainbus_attach_node(struct device *self,
 
len = OF_getproplen(node, "reg");
line = (sc->sc_acells + sc->sc_scells) * sizeof(uint32_t);
-   if (len > 0 && (len % line) == 0) {
+   if (len > 0 && line > 0 && (len % line) == 0) {
reg = malloc(len, M_TEMP, M_WAITOK);
OF_getpropintarray(node, "reg", reg, len);
 


Basically it avoids a divide by zero if acells or scells happen to be 0.
Probably not possible but this check is also in simplebus.c so thought I'd
get it reported.

Best Regards,
-peter

patch for dump for high percentages

[Peter J. Philipp]

Hi,

I have a patch for dump(8) if it is generally considered bad if percentage
done is over 100.0%.  I checked the archives on marc.info for this and didn't
see any discussion whether this was a topic before.

Here is the odd DUMP message I got on a host:

DUMP: 102.41% done, finished in 0:00

And here is the patch:

Index: optr.c
===
RCS file: /cvs/src/sbin/dump/optr.c,v
retrieving revision 1.40
diff -u -p -u -r1.40 optr.c
--- optr.c  22 Jan 2019 16:16:26 -  1.40
+++ optr.c  29 Feb 2020 16:19:25 -
@@ -202,6 +202,7 @@ void
 timeest(void)
 {
time_t  tnow, deltat;
+   float percent;
 
(void) time();
if (tnow >= tschedule) {
@@ -211,8 +212,9 @@ timeest(void)
deltat = tstart_writing - tnow +
(1.0 * (tnow - tstart_writing))
/ blockswritten * tapesize;
+   percent = (blockswritten * 100.0) / tapesize;
msg("%3.2f%% done, finished in %lld:%02lld\n",
-   (blockswritten * 100.0) / tapesize,
+   (percent > 100.0) ? 100.0 : percent,
(long long)deltat / 3600,
((long long)deltat % 3600) / 60);
}


I tested this and it seems to report like before, only when it hits 100.0 it
will not go higher, that particular codepath I didn't hit though.

beta# dump -0uaf - /var | gzip -c > /dev/null
  DUMP: Date of this level 0 dump: Sat Feb 29 17:20:26 2020
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/rsd2e (/var) to standard output
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 23891439 tape blocks.
  DUMP: Volume 1 started at: Sat Feb 29 17:20:37 2020
  DUMP: dumping (Pass III) [directories]
  DUMP: dumping (Pass IV) [regular files]
  DUMP: 25.98% done, finished in 0:14

Let me know what you think,

Regards,
-peter

Re: add DIOCRADDADDRS ioctl to kern_pledge pf

[Peter J. Philipp]

On Tue, Jan 14, 2020 at 11:05:38AM -0700, Theo de Raadt wrote:
> Some of the pledges (such as "pf") exist to support a cluster of
> programs -- not just 1 program -- and improve their security by limiting
> what they can do.  So that when the program gets subverted due something
> on it's input, the damage it can do is limited.


> Additionally, the list of operations permitted is kept very small, so that
> the switch() case in the kernel don't turn into a bloated fiasco.

OK.

> Your proposal supports 1 program.  Which isn't even in base.  There is
> no way I'm going accept this change.

OK, I see.  Yes it was selfish of me.

> Beyond that I need to once again point out a major missed step:
> 
> Your proposal is to permit DIOCRADDADDRS in all the current programs
> using "pf".  But you did not assessment to determine if there is a
> downside to giving them such access.  You simply wanted to barrel along
> forward, to support your one little program.
> 
> Ignoring the impact of your changes on the rest of the ecosystem is
> totally nuts.

Thanks for pointing that out.  I did take a look at one program in base
though and noticed it wasn't pledged.  But yes I barrelled along.  Sorry.

Regards,
-peter 

add DIOCRADDADDRS ioctl to kern_pledge pf

[Peter J. Philipp]

Hi,

I'm in the process of building a program that adds IP addresses to a table, 
from the network,  It is HMAC'ed.

I was stopped by a pledge, it seems it was not configured.  Here is the
ktrace snippet:

 40051 table-server CALL  open(0xbb705fb11f6,0x2)
 40051 table-server NAMI  "/dev/pf"
 40051 table-server RET   open 4
 40051 table-server CALL  kbind(0x7f7a2b08,24,0x2de4af929c6b5090)
 40051 table-server RET   kbind 0
 40051 table-server CALL  ioctl(4,DIOCRADDTABLES,0x7f7a32a8)
 40051 table-server RET   ioctl 0
 40051 table-server CALL  kbind(0x7f7a2b08,24,0x2de4af929c6b5090)
 40051 table-server RET   kbind 0
 40051 table-server CALL  ioctl(4,DIOCRADDADDRS,0x7f7a32a8)
 40051 table-server PLDG  ioctl, "tty", errno 1 Operation not permitted
 40051 table-server PSIG  SIGABRT SIG_DFL
 40051 table-server NAMI  "table-server.core"

Here is a patch to consider, it compiles but I haven't tested it yet because
I'm unsure if there is a reason why this DIOCR* was left out.

I'm guessing, if the patch is OK,  I'll have to leave the pledge out for 6.6 
which is what this is intended for.  Sad, but OK, at least there is unveil.


Index: kern_pledge.c
===
RCS file: /cvs/src/sys/kern/kern_pledge.c,v
retrieving revision 1.256
diff -u -p -u -r1.256 kern_pledge.c
--- kern_pledge.c   8 Dec 2019 23:08:59 -   1.256
+++ kern_pledge.c   14 Jan 2020 17:51:19 -
@@ -1205,6 +1205,7 @@ pledge_ioctl(struct proc *p, long com, s
case DIOCADDRULE:
case DIOCGETSTATUS:
case DIOCNATLOOK:
+   case DIOCRADDADDRS:
case DIOCRADDTABLES:
case DIOCRCLRADDRS:
case DIOCRCLRTABLES:




Cheers,
-peter

Re: ntpd is too noisy about 'DNS lookup tempfail' on IPv6 only hosts

[Peter J. Philipp]

On Wed, Nov 06, 2019 at 11:30:32AM +0100, Florian Obser wrote:
> > @@ -94,7 +95,7 @@ host_dns1(const char *s, struct ntp_addr
> > struct ntp_addr *h, *hh = NULL;
> >  
> > memset(, 0, sizeof(hints));
> > -   hints.ai_family = AF_UNSPEC;
> > +   hints.ai_family = (test_v4_gw() == 0) ? AF_UNSPEC : AF_INET6;
> > hints.ai_socktype = SOCK_DGRAM; /* DUMMY */
> > hints.ai_flags = AI_ADDRCONFIG;
> 
> you just implemented a variation of AI_ADDRCONFIG

Oh you're right!  Good you're looking over me Florian! So here is the
right patch then that I want OpenBSD to consider, with it I don't see 
the timeouts messages (are they needed?):

Best Regards,

-peter


Index: ntp_dns.c
===
RCS file: /cvs/src/usr.sbin/ntpd/ntp_dns.c,v
retrieving revision 1.24
diff -u -p -u -r1.24 ntp_dns.c
--- ntp_dns.c   27 Jun 2019 15:18:42 -  1.24
+++ ntp_dns.c   6 Nov 2019 10:39:36 -
@@ -170,7 +170,7 @@ dns_dispatch_imsg(struct ntpd_conf *ncon
strlen(name) != len)
fatalx("invalid %s received", str);
if ((cnt = host_dns(name, nconf->status.synced,
-   )) == -1)
+   )) <= 0)
break;
buf = imsg_create(ibuf_dns, imsg.hdr.type,
imsg.hdr.peerid, 0,

ntpd is too noisy about 'DNS lookup tempfail' on IPv6 only hosts

[Peter J. Philipp]

Hi,

I have an IPv6 only host arrowhead.ip6.centroid.eu, that has very noisy:
 
Oct 29 09:12:48 arrowhead ntpd[18744]: DNS lookup tempfail
Oct 29 09:21:45 arrowhead last message repeated 2 times

in fact:

arrowhead# grep 'DNS lookup tempfail' /var/log/daemon | wc -l
1354

This is because the pool.ntp.org servers as configured don't give back 
answers.  I'm trying to streamline this a little and only ask for  queries
if there is no v4 connectivity.  With change of the 'stdio dns' pledge to
'stdio inet dns' this is possible, when using another constraint from google.
There is no network traffic, just a route lookup if IPv4 is possible at all.

Here is my patch, under my sig.

-peter

Index: config.c
===
RCS file: /cvs/src/usr.sbin/ntpd/config.c,v
retrieving revision 1.32
diff -u -p -u -r1.32 config.c
--- config.c7 Jul 2019 07:14:57 -   1.32
+++ config.c6 Nov 2019 07:36:07 -
@@ -30,8 +30,9 @@
 
 #include "ntpd.h"
 
-struct ntp_addr*host_ip(const char *);
-int host_dns1(const char *, struct ntp_addr **, int);
+struct ntp_addr*host_ip(const char *);
+inthost_dns1(const char *, struct ntp_addr **, int);
+static int test_v4_gw(void);
 
 static u_int32_tmaxid = 0;
 static u_int32_tconstraint_maxid = 0;
@@ -59,7 +60,7 @@ host_ip(const char *s)
struct ntp_addr *h = NULL;
 
memset(, 0, sizeof(hints));
-   hints.ai_family = AF_UNSPEC;
+   hints.ai_family = (test_v4_gw() == 0) ? AF_UNSPEC : AF_INET6;
hints.ai_socktype = SOCK_DGRAM; /*dummy*/
hints.ai_flags = AI_NUMERICHOST;
if (getaddrinfo(s, "0", , ) == 0) {
@@ -94,7 +95,7 @@ host_dns1(const char *s, struct ntp_addr
struct ntp_addr *h, *hh = NULL;
 
memset(, 0, sizeof(hints));
-   hints.ai_family = AF_UNSPEC;
+   hints.ai_family = (test_v4_gw() == 0) ? AF_UNSPEC : AF_INET6;
hints.ai_socktype = SOCK_DGRAM; /* DUMMY */
hints.ai_flags = AI_ADDRCONFIG;
error = getaddrinfo(s, NULL, , );
@@ -181,3 +182,28 @@ new_constraint(void)
return (p);
 }
 
+static int
+test_v4_gw(void)
+{
+   struct sockaddr_in sin;
+   socklen_t st = sizeof(struct sockaddr_in);
+   int so;
+
+   so = socket(AF_INET, SOCK_DGRAM, 0);
+   if (so < 0) {
+   return 0;
+   }
+
+   memset(, 0, sizeof(sin));
+   sin.sin_family = AF_INET;
+   sin.sin_addr.s_addr = inet_addr(CONN_CONSTRAINT);
+   sin.sin_port = htons(53);
+   
+   if (connect(so, (struct sockaddr *), st) < 0) {
+   close(so);
+   return 0;
+   }
+
+   close(so);
+   return 1;
+}
Index: ntp_dns.c
===
RCS file: /cvs/src/usr.sbin/ntpd/ntp_dns.c,v
retrieving revision 1.24
diff -u -p -u -r1.24 ntp_dns.c
--- ntp_dns.c   27 Jun 2019 15:18:42 -  1.24
+++ ntp_dns.c   6 Nov 2019 07:36:07 -
@@ -98,7 +98,7 @@ ntp_dns(struct ntpd_conf *nconf, struct 
fatal(NULL);
imsg_init(ibuf_dns, PARENT_SOCK_FILENO);
 
-   if (pledge("stdio dns", NULL) == -1)
+   if (pledge("stdio inet dns", NULL) == -1)
err(1, "pledge");
 
probe_root();
@@ -170,7 +170,7 @@ dns_dispatch_imsg(struct ntpd_conf *ncon
strlen(name) != len)
fatalx("invalid %s received", str);
if ((cnt = host_dns(name, nconf->status.synced,
-   )) == -1)
+   )) <= 0)
break;
buf = imsg_create(ibuf_dns, imsg.hdr.type,
imsg.hdr.peerid, 0,
Index: ntpd.h
===
RCS file: /cvs/src/usr.sbin/ntpd/ntpd.h,v
retrieving revision 1.146
diff -u -p -u -r1.146 ntpd.h
--- ntpd.h  16 Jul 2019 14:15:40 -  1.146
+++ ntpd.h  6 Nov 2019 07:36:07 -
@@ -40,6 +40,7 @@
 #defineCONFFILE"/etc/ntpd.conf"
 #define DRIFTFILE  "/var/db/ntpd.drift"
 #defineCTLSOCKET   "/var/run/ntpd.sock"
+#define CONN_CONSTRAINT"8.8.8.8"   /* to test connectivity */
 
 #defineINTERVAL_QUERY_NORMAL   30  /* sync to peers every 
n secs */
 #defineINTERVAL_QUERY_PATHETIC 60

Re: ppppoe octeon kernel panic .6.6

[Peter J. Philipp]

Hi Miod,

Thanks for helping.  With this patch unfortunatly I still get a trap 2 on
my small unifi security gateway which I pulled out again to test your patch.

--->
cnmac0: 192.168.177.35 lease accepted from 192.168.177.1 (24:a4:3c:06:9f:16)
pppoe0: received unexpected PADO
pppoe0: host unique tag found, but it belongs to a connection in state 3

Trap cause = 2 Frame 0x98000ffdb860
Trap PC 0x811ac34c RA 0x813a09bc fault 0x0
smallcpy+0x8 (1,980001e1e476,1,2)  ra 0x813a09bc sp 0x98000ffdb9
b8, sz 0
sppp_auth_send+0x10c (1,980001e1e476,1,2)  ra 0x8139c844 sp 0x98
000ffdb9b8, sz 144
sppp_lcp_tlu+0x274 (1,980001e1e476,1,2)  ra 0x81396514 sp 0x9800
0ffdba48, sz 128
sppp_cp_input+0x141c (1,980001e1e476,1,2)  ra 0x81394a08 sp 0x98
000ffdbac8, sz 112
sppp_input+0x1d0 (1,980001e1e476,1,2)  ra 0x8148d2e4 sp 
0x98000ffdbb38, sz 80
pppoeintr+0xf9c (1,980001e1e476,1,2)  ra 0x814a44d8 sp 0x98000ff
dbb88, sz 400
User-level: pid 68736
stopped on non ddb fault
Stopped at  smallcpy+0x8:   lbu v1,0(a0)
ddb{0}> 
<---

Sorry that it does this.  My patch still stands I'm amazed!

Best Regards,

-peter



On Wed, Oct 23, 2019 at 05:15:41PM -, Miod Vallat wrote:
> 
> > Try changing all the final 0 in sppp_auth_send() to 0UL and this ought
> > to work. This function needs __attribute__((__sentinel__)) as well to
> > prevent such mistakes from occurring again.
> 
> The sentinel attribute wants a pointer, not a zero size_t,
> unfortunately.
> 
> Please try this diff.
> 
> Index: if_spppsubr.c
> ===
> RCS file: /OpenBSD/src/sys/net/if_spppsubr.c,v
> retrieving revision 1.179
> diff -u -p -r1.179 if_spppsubr.c
> --- if_spppsubr.c 24 Jun 2019 21:36:53 -  1.179
> +++ if_spppsubr.c 23 Oct 2019 17:12:53 -
> @@ -3340,7 +3340,7 @@ sppp_chap_input(struct sppp *sp, struct 
>  sizeof digest, digest,
>  strlen(sp->myauth.name),
>  sp->myauth.name,
> -0);
> +0UL);
>   break;
>  
>   case CHAP_SUCCESS:
> @@ -3460,7 +3460,7 @@ sppp_chap_input(struct sppp *sp, struct 
>   /* action scn, tld */
>   sppp_auth_send(, sp, CHAP_FAILURE, h->ident,
>  sizeof(FAILMSG) - 1, (u_char *)FAILMSG,
> -0);
> +0UL);
>   chap.tld(sp);
>   break;
>   }
> @@ -3469,7 +3469,7 @@ sppp_chap_input(struct sppp *sp, struct 
>   sp->state[IDX_CHAP] == STATE_OPENED)
>   sppp_auth_send(, sp, CHAP_SUCCESS, h->ident,
>  sizeof(SUCCMSG) - 1, (u_char *)SUCCMSG,
> -0);
> +0UL);
>   if (sp->state[IDX_CHAP] == STATE_REQ_SENT) {
>   sppp_cp_change_state(, sp, STATE_OPENED);
>   chap.tlu(sp);
> @@ -3647,7 +3647,7 @@ sppp_chap_scr(struct sppp *sp)
>  (size_t)AUTHCHALEN, sp->chap_challenge,
>  strlen(sp->myauth.name),
>  sp->myauth.name,
> -0);
> +0UL);
>  }
>  /*
>   *--*
> @@ -3726,7 +3726,7 @@ sppp_pap_input(struct sppp *sp, struct m
>   sppp_auth_send(, sp, PAP_NAK, h->ident,
>  sizeof mlen, (const char *),
>  sizeof(FAILMSG) - 1, (u_char *)FAILMSG,
> -0);
> +0UL);
>   pap.tld(sp);
>   break;
>   }
> @@ -3737,7 +3737,7 @@ sppp_pap_input(struct sppp *sp, struct m
>   sppp_auth_send(, sp, PAP_ACK, h->ident,
>  sizeof mlen, (const char *),
>  sizeof(SUCCMSG) - 1, (u_char *)SUCCMSG,
> -0);
> +0UL);
>   }
>   if (sp->state[IDX_PAP] == STATE_REQ_SENT) {
>   sppp_cp_change_state(, sp, STATE_OPENED);
> @@ -3952,7 +3952,7 @@ sppp_pap_scr(struct sppp *sp)
>  (size_t)idlen, sp->myauth.name,
>  sizeof pwdlen, (const char *),
>  (size_t)pwdlen, sp->myauth.secret,
> -0);
> +0UL);
>  }
>  /*
>   * Random miscellaneous functions.

Re: ppppoe octeon kernel panic .6.6

[Peter J. Philipp]

Hi Janne,

I think the way this patch is, it's ghetto, I don't even know if OpenBSD
wants to take it on, hence I sent it as a hint.  What really would be cool is
to find out why exactly the trap 2 happens, because the pppoe code works on
a lot of other archs.

My effort is selfish because I want my octeon router doing gateway and not
an old i386 router :-), I was in a race with myself to get this going again.

But if OpenBSD for whatever reason feels the code is almost acceptable, then
the magic number 0x5, 1 can be replaced with a couple of defines perhaps:

#define SPPP_AUTH_SEND_FIRST_ROW0x1
#define SPPP_AUTH_SEND_SECOND_ROW   0x2
#define SPPP_AUTH_SEND_THIRD_ROW0x4

and then the 0x5 would become 
(SPPP_AUTH_SEND_FIRST_ROW|SPPP_AUTH_SEND_THIRD_ROW) and the one 1 would become 
SPPP_AUTH_SEND_FIRST_ROW.

We can also rename the seq to row, to make it ever more obvious that the
varargs are in pairs and one pair is a row.  

Looking at this I agree it's ugly.  Perhaps it needs to be refactored again or
downright fixed (ie. like the other archs, or are they somehow broken too but
behave differently?).

Best Regards,
-peter


On Wed, Oct 23, 2019 at 11:47:03AM +0200, Janne Johansson wrote:
> Den ons 23 okt. 2019 kl 09:15 skrev Peter J. Philipp :
> 
> > Hi Holger & Tech,
> >
> > I have made my octeon router work again and I have a patch.
> >
> >
> Truncated it a lot, leaving the things I reacted on:
> 
> 
> > -   sppp_auth_send(, sp, CHAP_RESPONSE, h->ident,
> > -  sizeof dsize, (const char *),
> > +   sppp_auth_send(, sp, CHAP_RESPONSE, h->ident, 0x1,
> > +  1, dsize,
> >
> 
> 
> > -   sppp_auth_send(, sp, CHAP_CHALLENGE, sp->confid[IDX_CHAP],
> > -  sizeof clen, (const char *),
> > +   sppp_auth_send(, sp, CHAP_CHALLENGE, sp->confid[IDX_CHAP],
> > 0x1,
> > +  1, clen,
> >
> 
> 
> > -  sizeof mlen, (const char *),
> > +  0x1,
> > +  1, mlen,
> >
> 
> 
> > -  sizeof idlen, (const char *),
> > -  (size_t)idlen, sp->myauth.name,
> > -  sizeof pwdlen, (const char *),
> > -  (size_t)pwdlen, sp->myauth.secret,
> > +  0x5,
> > +  1, s_id,
> > +  s_id, sp->myauth.name,
> > +  1, s_pwd,
> > +  s_pwd, sp->myauth.secret,
> >
> 
> For all the good this patch might do, it still replaces a lot of things in
> the source with names like XYZlen with 0x1 or 0x5,
> so it will be much harder later on to figure out why some part is sending 5
> over to the function it calls. 8-/
> Magic constants makes peoples eyes hurt.
> 
> -- 
> May the most significant bit of your life be positive.

Re: ppppoe octeon kernel panic .6.6

[Peter J. Philipp]

On Wed, Oct 23, 2019 at 11:18:11AM +0200, Martin Pieuchot wrote:
> On 23/10/19(Wed) 08:43, Peter J. Philipp wrote:
> > Hi Holger & Tech,
> 
> Hello Peter,
> 
> > I have made my octeon router work again and I have a patch.  But I'm not an
> > openbsd developer, nor is this patch official in any way. 
> 
> Could you explain in words what is the issue?  Why does your diff
> prevent it?
> 
> Thanks!

Hi,

The system has a trap 2, which I looked up as:

#define T_TLB_LD_MISS   2   /* TLB miss on load or ifetch */

what happens before this patch, I think, is that there is a varargs size_t 
(which is size 8 in mips64), that gets promoted (I think) in varargs to int 
(which would likely be size 4).  Then what happens is the char * that is 
va_arg'ed after that is somehow corrupted on length 1, bcopy would trap #2 
on this.

If it is a varargs corruption in the builtin mips64 clang code then I don't
want to have to fix that, as I don't even know where to look.  Instead I 
laid out every buffer very carefully and using int's and char *'s so that 
trap 2 is not called.  I made a bitmask in the called function that usually 
gets the trap that it will treat length of one as an int and the rest as a 
char *.

I admit it was a lot of trial and error I must have gone through over 20+ 
compile/reboot cycles to get it right.  I tested this on a unifi security
gateway and an ER-8.  Both agreed to everything and at that spot is not trap 2.

I may have avoided the condition, but the condition may still be there on
other code.  I didn't look.  To easen debug of this I'll attach some config 
files for npppd that I used in my lab that you can see for yourself on any 
octeon pppoe.

I don't know if these were standard example npppd's or if they were left over
from an earlier project.

Thanks!

-peter

beta$ more npppd.conf
###npppd.conf 

tunnel PPPOE protocol pppoe { 
 listen on interface ix1
 pppoe-desc-in-pktdump yes 
 pppoe-desc-out-pktdump yes 
 pppoe-session-in-pktdump yes 
 pppoe-session-out-pktdump yes 
 authentication-method pap
} 

ipcp IPCP { 
 pool-address 10.0.0.2-10.0.0.254 
 dns-servers 192.168.177.40
} 

interface tun1 address 10.0.0.1 ipcp IPCP 
authentication LOCAL type local { 
  users-file "/etc/npppd/npppd-users" 
} 
bind tunnel from PPPOE authenticated by LOCAL to tun1
##

beta# more /etc/npppd/npppd-users
# $OpenBSD: npppd-users,v 1.1 2012/09/20 12:51:43 yasuoka Exp $
# sample npppd-users file.  see npppd-users(5)

testcaller:\
:password=Verizon:\
:framed-ip-address=10.0.0.103

##




> > --- if_spppsubr.c.orig  Tue Oct 22 18:49:47 2019
> > +++ if_spppsubr.c   Wed Oct 23 08:03:35 2019
> > @@ -64,6 +64,7 @@
> >  #endif
> >  
> >  #include 
> > +#include 
> >  
> >  # define UNTIMEOUT(fun, arg, handle)   \
> > timeout_del(&(handle))
> > @@ -233,7 +234,7 @@
> >  int newstate);
> >  void sppp_auth_send(const struct cp *cp,
> >struct sppp *sp, unsigned int type, u_int id,
> > -  ...);
> > +   u_int bitmask, ...);
> >  
> >  void sppp_up_event(const struct cp *cp, struct sppp *sp);
> >  void sppp_down_event(const struct cp *cp, struct sppp *sp);
> > @@ -3277,7 +3278,8 @@
> > STDDCL;
> > struct lcp_header *h;
> > int len, x;
> > -   u_char *value, *name, digest[AUTHCHALEN], dsize;
> > +   u_char *value, *name, digest[AUTHCHALEN];
> > +   int dsize;
> > int value_len, name_len;
> > MD5_CTX ctx;
> >  
> > @@ -3335,8 +3337,8 @@
> > MD5Final(digest, );
> > dsize = sizeof digest;
> >  
> > -   sppp_auth_send(, sp, CHAP_RESPONSE, h->ident,
> > -  sizeof dsize, (const char *),
> > +   sppp_auth_send(, sp, CHAP_RESPONSE, h->ident, 0x1,
> > +  1, dsize,
> >sizeof digest, digest,
> >strlen(sp->myauth.name),
> >sp->myauth.name,
> > @@ -3458,7 +3460,7 @@
> > if (value_len != sizeof digest ||
> > timingsafe_bcmp(digest, value, value_len) != 0) {
> > /* action scn, tld */
> > -   sppp_auth_send(, sp, CHAP_FAILURE, h->ident,
> > +   sppp_auth_send(, sp, CHAP_FAILURE, h->ident, 0, 
> >sizeof(FAILMSG) - 1, (u_char *)FAILMSG,
> >   

Re: ppppoe octeon kernel panic .6.6

[Peter J. Philipp]

On Wed, Oct 23, 2019 at 08:21:50AM +0200, Holger Glaess wrote:
> hi
> 
> 
> here the traceback , i hope ;)

Hi Holger & Tech,

I have made my octeon router work again and I have a patch.  But I'm not an
openbsd developer, nor is this patch official in any way.  It was a lot of
debugging and refactoring I had to do in /sys/net/if_spppsubr.c because
the varargs were really screwy.  size_t is not a standard builtin vararg
I believe and there was some sideffects with that.  I also applied a header
include for strlen() in this patch.

This patch should be CC'ed to tech@ and they can disect it and use it for
hints.  I have not tested this patch on any arch other than octeon.  In the
end it was not time wasted I spent 2 mornings and 2 nights on this.

You should be OK extracing sys.tar.gz in your octeon and build a kernel like
the normal way.  I know the octeons are usually low on diskspace.

Best Regards,
-peter


--- if_spppsubr.c.orig  Tue Oct 22 18:49:47 2019
+++ if_spppsubr.c   Wed Oct 23 08:03:35 2019
@@ -64,6 +64,7 @@
 #endif
 
 #include 
+#include 
 
 # define UNTIMEOUT(fun, arg, handle)   \
timeout_del(&(handle))
@@ -233,7 +234,7 @@
 int newstate);
 void sppp_auth_send(const struct cp *cp,
   struct sppp *sp, unsigned int type, u_int id,
-  ...);
+   u_int bitmask, ...);
 
 void sppp_up_event(const struct cp *cp, struct sppp *sp);
 void sppp_down_event(const struct cp *cp, struct sppp *sp);
@@ -3277,7 +3278,8 @@
STDDCL;
struct lcp_header *h;
int len, x;
-   u_char *value, *name, digest[AUTHCHALEN], dsize;
+   u_char *value, *name, digest[AUTHCHALEN];
+   int dsize;
int value_len, name_len;
MD5_CTX ctx;
 
@@ -3335,8 +3337,8 @@
MD5Final(digest, );
dsize = sizeof digest;
 
-   sppp_auth_send(, sp, CHAP_RESPONSE, h->ident,
-  sizeof dsize, (const char *),
+   sppp_auth_send(, sp, CHAP_RESPONSE, h->ident, 0x1,
+  1, dsize,
   sizeof digest, digest,
   strlen(sp->myauth.name),
   sp->myauth.name,
@@ -3458,7 +3460,7 @@
if (value_len != sizeof digest ||
timingsafe_bcmp(digest, value, value_len) != 0) {
/* action scn, tld */
-   sppp_auth_send(, sp, CHAP_FAILURE, h->ident,
+   sppp_auth_send(, sp, CHAP_FAILURE, h->ident, 0, 
   sizeof(FAILMSG) - 1, (u_char *)FAILMSG,
   0);
chap.tld(sp);
@@ -3467,7 +3469,7 @@
/* action sca, perhaps tlu */
if (sp->state[IDX_CHAP] == STATE_REQ_SENT ||
sp->state[IDX_CHAP] == STATE_OPENED)
-   sppp_auth_send(, sp, CHAP_SUCCESS, h->ident,
+   sppp_auth_send(, sp, CHAP_SUCCESS, h->ident, 0,
   sizeof(SUCCMSG) - 1, (u_char *)SUCCMSG,
   0);
if (sp->state[IDX_CHAP] == STATE_REQ_SENT) {
@@ -3634,7 +3636,7 @@
 void
 sppp_chap_scr(struct sppp *sp)
 {
-   u_char clen;
+   int clen;
 
/* Compute random challenge. */
arc4random_buf(sp->chap_challenge, sizeof(sp->chap_challenge));
@@ -3642,8 +3644,8 @@
 
sp->confid[IDX_CHAP] = ++sp->pp_seq;
 
-   sppp_auth_send(, sp, CHAP_CHALLENGE, sp->confid[IDX_CHAP],
-  sizeof clen, (const char *),
+   sppp_auth_send(, sp, CHAP_CHALLENGE, sp->confid[IDX_CHAP], 0x1,
+  1, clen,
   (size_t)AUTHCHALEN, sp->chap_challenge,
   strlen(sp->myauth.name),
   sp->myauth.name,
@@ -3671,7 +3673,8 @@
STDDCL;
struct lcp_header *h;
int len, x;
-   u_char *name, *passwd, mlen;
+   u_char *name, *passwd;
+   int mlen;
int name_len, passwd_len;
 
len = m->m_pkthdr.len;
@@ -3724,7 +3727,8 @@
/* action scn, tld */
mlen = sizeof(FAILMSG) - 1;
sppp_auth_send(, sp, PAP_NAK, h->ident,
-  sizeof mlen, (const char *),
+  0x1,
+  1, mlen,
   sizeof(FAILMSG) - 1, (u_char *)FAILMSG,
   0);
pap.tld(sp);
@@ -3735,7 +3739,8 @@
sp->state[IDX_PAP] == STATE_OPENED) {
mlen = sizeof(SUCCMSG) - 1;
sppp_auth_send(, sp, PAP_ACK, h->ident,
-  sizeof mlen, (const char *),
+  

Re: if_pppoe.c patch

[Peter J. Philipp]

On Sun, Jan 20, 2019 at 12:56:22PM +, Stuart Henderson wrote:
> On 2019/01/18 10:59, Peter J. Philipp wrote:
> > I have "covered" up PPPoE Session ID's from users because it is a value that
> > is only gotten on the Data Link layer and historically non-root users did 
> > not
> > have access to that.  It really is a value that doesn't concern them.  I 
> > have
> > wrapped the display with a suser() conditional.  The magic value 0x is
> > not used/reserved according to RFC 2516.
> 
> No real comment on whether we should do this or not (it feels a bit like
> restricting arp to root..) but if it is done, it would seem better to use

Not like restricting arp to root..., it's more like TCP hiding its ISN.

> a value which cannot be sent on the wire, rather than one which is just
> reserved. (And actually hide it from ifconfig rather than displaying a
> bogus value).

I'll try to get around to it tomorrow if I can.  Otherwise just drop the
request. :-)

Best Regards,
-peter

> > as root:
> > 
> > beta# ifconfig pppoe0
> > pppoe0: flags=8810 mtu 1492
> > index 12 priority 0 llprio 3
> > dev:  state: initial
> > sid: 0x0 PADI retries: 0 PADR retries: 0
> > groups: pppoe
> > 
> > as non-root:
> > 
> > beta$ ifconfig pppoe0 
> > pppoe0: flags=8810 mtu 1492
> > index 12 priority 0 llprio 3
> > dev:  state: initial
> > sid: 0x PADI retries: 0 PADR retries: 0
> > groups: pppoe
> > 
> > 
> > patch follows:
> > 
> > Index: if_pppoe.c
> > ===
> > RCS file: /cvs/src/sys/net/if_pppoe.c,v
> > retrieving revision 1.67
> > diff -u -p -u -r1.67 if_pppoe.c
> > --- if_pppoe.c  19 Feb 2018 08:59:52 -  1.67
> > +++ if_pppoe.c  18 Jan 2019 09:50:58 -
> > @@ -874,7 +876,12 @@ pppoe_ioctl(struct ifnet *ifp, unsigned 
> > struct pppoeconnectionstate *state =
> > (struct pppoeconnectionstate *)data;
> > state->state = sc->sc_state;
> > -   state->session_id = sc->sc_session;
> > +
> > +   if (! suser(p))
> > +   state->session_id = sc->sc_session;
> > +   else
> > +   state->session_id = 0x; /* reserved sid */
> > +
> > state->padi_retry_no = sc->sc_padi_retried;
> > state->padr_retry_no = sc->sc_padr_retried;
> > state->session_time.tv_sec = sc->sc_session_time.tv_sec;
> > 

if_pppoe.c patch

[Peter J. Philipp]

I have "covered" up PPPoE Session ID's from users because it is a value that
is only gotten on the Data Link layer and historically non-root users did not
have access to that.  It really is a value that doesn't concern them.  I have
wrapped the display with a suser() conditional.  The magic value 0x is
not used/reserved according to RFC 2516.

as root:

beta# ifconfig pppoe0
pppoe0: flags=8810 mtu 1492
index 12 priority 0 llprio 3
dev:  state: initial
sid: 0x0 PADI retries: 0 PADR retries: 0
groups: pppoe

as non-root:

beta$ ifconfig pppoe0 
pppoe0: flags=8810 mtu 1492
index 12 priority 0 llprio 3
dev:  state: initial
sid: 0x PADI retries: 0 PADR retries: 0
groups: pppoe


patch follows:

Index: if_pppoe.c
===
RCS file: /cvs/src/sys/net/if_pppoe.c,v
retrieving revision 1.67
diff -u -p -u -r1.67 if_pppoe.c
--- if_pppoe.c  19 Feb 2018 08:59:52 -  1.67
+++ if_pppoe.c  18 Jan 2019 09:50:58 -
@@ -874,7 +876,12 @@ pppoe_ioctl(struct ifnet *ifp, unsigned 
struct pppoeconnectionstate *state =
(struct pppoeconnectionstate *)data;
state->state = sc->sc_state;
-   state->session_id = sc->sc_session;
+
+   if (! suser(p))
+   state->session_id = sc->sc_session;
+   else
+   state->session_id = 0x; /* reserved sid */
+
state->padi_retry_no = sc->sc_padi_retried;
state->padr_retry_no = sc->sc_padr_retried;
state->session_time.tv_sec = sc->sc_session_time.tv_sec;

handling of magic number in LCP echo replies

[Peter J. Philipp]

Hi,

I'd like to get some help determining if this is a problem per se.  In 
/sys/net/if_spppsubr.c lines 1323-1327 the nmagic is assembled and checked
against sp->lcp.magic, and if it doesn't match then it does something weird.  
It resets the sp->pp_alivecnt to 0.  This to me does nothing much other than 
resetting a counter (which only tears down a connection if it has achieved
MAXALIVECNT.

At first I thought it should tear down the link but RFC 1661 says that this
is the pessimistic approach around page 46.

The RFC is a little vague, because it leaves this as unspecified on page
47:

---
  Procedures for recovery from either case are unspecified, and may
  vary from implementation to implementation.  A somewhat
  pessimistic procedure is to assume a LCP Down event.  A further
  Open event will begin the process of re-establishing the link,
  which can't complete until the looped-back condition is
  terminated, and Magic-Numbers are successfully negotiated.  A more
  optimistic procedure (in the case of a looped-back link) is to
  begin transmitting LCP Echo-Request packets until an appropriate
  Echo-Reply is received, indicating a termination of the looped-
  back condition.
---

I'm shrugging my shoulders as I see an unspecified area and it's not
really handled.  Is no code better than some unspecified code?  Is any code
better than leaving it alone?  In my scenario I only looked at the code,
I have not tested anything, to see if its a detriment.

I have checked FreeBSD source and it also does this in head.

Regards,
-peter

Re: nice side-effect, but rebound doesn't play

[Peter J. Philipp]

oops I just realised I never activated rebound by putting a nameserver entry
for 127.0.0.1 at the top of the nameservers list.  This makes my patch broken
then since I tested it and it could only find the lookup once and then refused
any more queries after that.  Sorry about that!  However in theory my request
is right and it would be cool to have multiple nameserver entries that it
reads from the resolv.conf and then tries.  (Oh noI'm a feature creep!)

Apologies,
-peter

On Sat, Jul 14, 2018 at 07:24:09AM +0200, Peter J. Philipp wrote:
> Hi,
> 
> Yesterday I was messing with my network and particularily my workstation with
> the goal of having an internal nameserver serve "internal.centroid.eu" zones
> for my computers at home, and also do "168.192.in-addr.arpa" reverse.  I had
> no luck diverting this from BIND, and then something unexpected happened to 
> me.
> 
> I accidentally put the internal nameserver in the first nameserver entry of 
> /etc/resolv.conf and it looked up the internal zones and replied "REFUSED"
> on anything not configured on the nameserver.  The resolver in OpenBSD then
> immediately switched to the second nameserver (not even a 1 ms latency) and
> looked up the external address there.  Needless to say this does what I tried
> to do with BIND.
> 
> Then came rebound into the picture and it doesn't do this, why?  Because
> rebound only uses 1 nameserver entry in the config.  I did a quick hack around
> rebound (please don't use it probably has memory problems) and determined that
> it was able to do this with some code modification and if done in a style that
> Ted uses it could fit in the code without sticking out too much.  So take my
> hack as a proof-of-concept and it's just for show.
> 
> My ultimate question then is "why does the resolver do it this way?" was this
> on purpose?  (probably a question for Eric).  I don't mind this and don't want
> to instigate a "oh this is wrong" and then have someone change the 
> behaviour...
> Because it works for me without having to reconfigure the recursing 
> nameserver.
> And, I have a query log locally if I turn up logging on my authoritative name-
> server, which can be good for analysis with scripts.
> 
> So the rebound patch is after my signature, it works but probably is not in
> a style that openbsd wants in their code or that Ted would want in his code.
> Take it as a proof of concept.  But... can we have something like that in 
> rebound?  Otherwise rebound won't be used here.
> 
> -peter
> 
> 
> Index: rebound.c
> ===
> RCS file: /cvs/src/usr.sbin/rebound/rebound.c,v
> retrieving revision 1.98
> diff -u -p -u -r1.98 rebound.c
> --- rebound.c 1 May 2018 15:14:43 -   1.98
> +++ rebound.c 14 Jul 2018 05:03:07 -
> @@ -52,6 +52,10 @@ union sockun {
>   struct sockaddr_in6 i6;
>  };
>  
> +struct cfg {
> + union sockun r[6];
> +};
> +
>  static struct timespec now;
>  static int debug;
>  static int daemonized;
> @@ -340,8 +344,9 @@ servfail(int ud, uint16_t id, struct soc
>  }
>  
>  static struct request *
> -newrequest(int ud, struct sockaddr *remoteaddr)
> +newrequest(int ud, struct cfg *cfg)
>  {
> + struct sockaddr *remoteaddr = >r->a;
>   union sockun from;
>   socklen_t fromlen;
>   struct request *req;
> @@ -369,6 +374,15 @@ newrequest(int ud, struct sockaddr *remo
>  
>   conntotal += 1;
>   if (hit) {
> + if (hit->resp->flags & (0x8000 | 0x5)) { /* got a refused */
> + struct cfg *ncfg = cfg;
> + ncfg++;
> + if (ncfg->r->a.sa_family != AF_INET ||
> + ncfg->r->a.sa_family != AF_INET6)
> + return NULL;
> +
> + return (newrequest(ud, ncfg));
> + }
>   hit->resp->id = dnsreq->id;
>   memcpy(hit->resp->qname, dnsreq->qname, namelen);
>   sendto(ud, hit->resp, hit->resplen, 0, , fromlen);
> @@ -560,8 +574,9 @@ fail:
>  }
>  
>  static struct request *
> -newtcprequest(int ld, struct sockaddr *remoteaddr)
> +newtcprequest(int ld, struct cfg *cfg)
>  {
> + struct sockaddr *remoteaddr = >r->a;
>   struct request *req;
>   int client;
>  
> @@ -719,16 +734,17 @@ preloadPTR(const char *ip, const char *n
>  }
>  
>  static int
> -readconfig(int conffd, union sockun *remoteaddr)
> +readconfig(int conffd, struct cfg *cfg)
>  {
>   const char ns[] = "nameserver";
>   const char rc[] = 

nice side-effect, but rebound doesn't play

[Peter J. Philipp]

Hi,

Yesterday I was messing with my network and particularily my workstation with
the goal of having an internal nameserver serve "internal.centroid.eu" zones
for my computers at home, and also do "168.192.in-addr.arpa" reverse.  I had
no luck diverting this from BIND, and then something unexpected happened to me.

I accidentally put the internal nameserver in the first nameserver entry of 
/etc/resolv.conf and it looked up the internal zones and replied "REFUSED"
on anything not configured on the nameserver.  The resolver in OpenBSD then
immediately switched to the second nameserver (not even a 1 ms latency) and
looked up the external address there.  Needless to say this does what I tried
to do with BIND.

Then came rebound into the picture and it doesn't do this, why?  Because
rebound only uses 1 nameserver entry in the config.  I did a quick hack around
rebound (please don't use it probably has memory problems) and determined that
it was able to do this with some code modification and if done in a style that
Ted uses it could fit in the code without sticking out too much.  So take my
hack as a proof-of-concept and it's just for show.

My ultimate question then is "why does the resolver do it this way?" was this
on purpose?  (probably a question for Eric).  I don't mind this and don't want
to instigate a "oh this is wrong" and then have someone change the behaviour...
Because it works for me without having to reconfigure the recursing nameserver.
And, I have a query log locally if I turn up logging on my authoritative name-
server, which can be good for analysis with scripts.

So the rebound patch is after my signature, it works but probably is not in
a style that openbsd wants in their code or that Ted would want in his code.
Take it as a proof of concept.  But... can we have something like that in 
rebound?  Otherwise rebound won't be used here.

-peter


Index: rebound.c
===
RCS file: /cvs/src/usr.sbin/rebound/rebound.c,v
retrieving revision 1.98
diff -u -p -u -r1.98 rebound.c
--- rebound.c   1 May 2018 15:14:43 -   1.98
+++ rebound.c   14 Jul 2018 05:03:07 -
@@ -52,6 +52,10 @@ union sockun {
struct sockaddr_in6 i6;
 };
 
+struct cfg {
+   union sockun r[6];
+};
+
 static struct timespec now;
 static int debug;
 static int daemonized;
@@ -340,8 +344,9 @@ servfail(int ud, uint16_t id, struct soc
 }
 
 static struct request *
-newrequest(int ud, struct sockaddr *remoteaddr)
+newrequest(int ud, struct cfg *cfg)
 {
+   struct sockaddr *remoteaddr = >r->a;
union sockun from;
socklen_t fromlen;
struct request *req;
@@ -369,6 +374,15 @@ newrequest(int ud, struct sockaddr *remo
 
conntotal += 1;
if (hit) {
+   if (hit->resp->flags & (0x8000 | 0x5)) { /* got a refused */
+   struct cfg *ncfg = cfg;
+   ncfg++;
+   if (ncfg->r->a.sa_family != AF_INET ||
+   ncfg->r->a.sa_family != AF_INET6)
+   return NULL;
+
+   return (newrequest(ud, ncfg));
+   }
hit->resp->id = dnsreq->id;
memcpy(hit->resp->qname, dnsreq->qname, namelen);
sendto(ud, hit->resp, hit->resplen, 0, , fromlen);
@@ -560,8 +574,9 @@ fail:
 }
 
 static struct request *
-newtcprequest(int ld, struct sockaddr *remoteaddr)
+newtcprequest(int ld, struct cfg *cfg)
 {
+   struct sockaddr *remoteaddr = >r->a;
struct request *req;
int client;
 
@@ -719,16 +734,17 @@ preloadPTR(const char *ip, const char *n
 }
 
 static int
-readconfig(int conffd, union sockun *remoteaddr)
+readconfig(int conffd, struct cfg *cfg)
 {
const char ns[] = "nameserver";
const char rc[] = "record";
char buf[1024];
char *p;
-   struct sockaddr_in *sin = >i;
-   struct sockaddr_in6 *sin6 = >i6;
+   struct sockaddr_in *sin = [0].r->i;
+   struct sockaddr_in6 *sin6 = [0].r->i6;
FILE *conf;
int rv = -1;
+   int num_ns = 0;
 
conf = fdopen(conffd, "r");
 
@@ -744,7 +760,10 @@ readconfig(int conffd, union sockun *rem
if (strcmp(p, "127.0.0.1") == 0)
continue;
 
-   memset(remoteaddr, 0, sizeof(*remoteaddr));
+   if (num_ns >= 5)
+   continue;
+
+   memset([num_ns].r, 0, sizeof(union sockun));
if (inet_pton(AF_INET, p, >sin_addr) == 1) {
sin->sin_len = sizeof(*sin);
sin->sin_family = AF_INET;
@@ -756,6 +775,9 @@ readconfig(int conffd, union sockun *rem
sin6->sin6_port = htons(53);
rv = AF_INET6;
}
+   num_ns++;
+   

define rebound magic numbers

[Peter J. Philipp]

Hi,

While reading through rebound, I noticed the author uses a lot of magic numbers
in DNS flags field.  I present OpenBSD a set of #defines that I wrote in 2002
on an OpenBSD/macppc iBook in Montreal.  If I didn't write all of it then, I
followed up with it in 2005 when my own DNS server came into fruition.  The
defines can also be gotten from here and are under a BSD license:

http://centroid.eu/cgi-bin/cvsweb/~checkout~/delphinusdns/delphinusdnsd/ddd-dns.h?rev=1.6=text/plain

patch which defines magic numbers in rebound follows after my sig.

I won't cry if you don't like it.

Regards,
-peter


Index: rebound.c
===
RCS file: /cvs/src/usr.sbin/rebound/rebound.c,v
retrieving revision 1.98
diff -u -p -u -r1.98 rebound.c
--- rebound.c   1 May 2018 15:14:43 -   1.98
+++ rebound.c   13 Jul 2018 13:33:28 -
@@ -43,6 +43,29 @@
 
 #define MINIMUM(a,b) (((a)<(b))?(a):(b))
 
+/* 
+ * flags RFC 1035, page 26
+ */
+
+#define DNS_REPLY   0x8000  /* if set response if not set query */
+#define DNS_NOTIFY  0x2000  /* a NOTIFY query RFC 1996 */
+#define DNS_SREQ0x1000  /* if set a server status request (STATUS) */
+#define DNS_INV 0x800   /* if set an inverse query */
+#define DNS_AUTH0x400   /* Authoritative Answer (AA) in replies */
+#define DNS_TRUNC   0x200   /* Truncated (TC) */
+#define DNS_RECURSE 0x100   /* if set Recursion Desired (RD) */
+#define DNS_RECAVAIL0x80/* if set Recursion Available (RA) */
+#define DNS_BADTIME 0x12/* RCODE (18) BADTIME RFC 2845 p. 3 */
+#define DNS_BADKEY  0x11/* RCODE (17) BADKEY RFC 2845 p. 3 */
+#define DNS_BADSIG  0x10/* RCODE (16) BADSIG RFC 2845 p. 3 */
+#define DNS_BADVERS 0x10/* RCODE (16) BADVERS RFC 2671 p. 6 */
+#define DNS_REFUSED 0x5 /* RCODE - Refused */
+#define DNS_NOTIMPL 0x4 /* RCODE - Not Implemented */
+#define DNS_NAMEERR 0x3 /* RCODE - Name Error, NXDOMAIN */
+#define DNS_SERVFAIL0x2 /* RCODE - Server Failure */
+#define DNS_FORMATERR   0x1 /* RCODE - Format Error */
+#define DNS_NOERR   0x0 /* RCODE - No error */
+
 uint16_t randomid(void);
 
 union sockun {
@@ -335,7 +358,7 @@ servfail(int ud, uint16_t id, struct soc
 
memset(, 0, sizeof(pkt));
pkt.id = id;
-   pkt.flags = htons(1 << 15 | 0x2);
+   pkt.flags = htons(DNS_REPLY | DNS_SERVFAIL);
sendto(ud, , sizeof(pkt), 0, fromaddr, fromlen);
 }
 
@@ -645,7 +668,7 @@ preloadcache(const char *name, uint16_t 
req = malloc(reqlen);
 
req->id = 0;
-   req->flags = htons(0x100);
+   req->flags = htons(DNS_RECURSE);
req->qdcount = htons(1);
req->ancount = 0;
req->nscount = 0;
@@ -662,7 +685,7 @@ preloadcache(const char *name, uint16_t 
resplen = reqlen + 2 + 2 + 2 + 4 + 2 + rdatalen;
resp = malloc(resplen);
memcpy(resp, req, reqlen);
-   resp->flags = htons(0x100 | 0x8000);/* response */
+   resp->flags = htons(DNS_RECURSE | DNS_REPLY);   /* response */
resp->ancount = htons(1);
p = (char *)resp + reqlen;
len = htons(sizeof(*req));

fstat -r flag to display rdomains on sockets

[Peter J. Philipp]

Hi,

I've been running iked for a while now and have been able to guess which iked
belongs to which rdomain by the cpu counter but as I'm using the other iked
more the cpu counter is about the same and it's confusing when I have to 
restart iked with route exec.

I introduce the -r flag to fstat in order to display rdomains on sockets in
order to find the right iked.  The fix is simple but because some peoples
scripts may depend on the old output I made it an extra flag.

Here is how it looks like with and without the -r flag:

uranus$ fstat -rp 84169
USER CMD  PID   FD MOUNTINUM  MODE R/WSZ|DV
_ikediked   84169 text /  105245  -r-xr-xr-x r   321760
_ikediked   84169   wd /var   129920  drwxr-xr-x r  512
_ikediked   84169 root /var   129920  drwxr-xr-x r  512
_ikediked   841690 /  105143  crw-rw-rw-rw null
_ikediked   841691 /  105143  crw-rw-rw-rw null
_ikediked   841692 /  105143  crw-rw-rw-rw null
_ikediked   841693* 30 raw 2 0xd2f8f844  
_ikediked   841694* rdomain 2 internet dgram udp *:500   
_ikediked   841695* rdomain 2 internet dgram udp *:4500
_ikediked   841696* rdomain 2 internet6 dgram udp *:500
_ikediked   841697* rdomain 2 internet6 dgram udp *:4500
_ikediked   841698* unix stream 0xd3eb4180 <-> 0xd3eb4100
_ikediked   84169   10* unix stream 0xd3eb4280 <-> 0xd3eb4200
_ikediked   84169   11 kqueue 0xd32a8ad4 0 state: W

uranus$ fstat -p 47863
USER CMD  PID   FD MOUNTINUM  MODE R/WSZ|DV
_ikediked   47863 text /  105245  -r-xr-xr-x r   321760
_ikediked   47863   wd /var   129920  drwxr-xr-x r  512
_ikediked   47863 root /var   129920  drwxr-xr-x r  512
_ikediked   478630 /  105143  crw-rw-rw-rw null
_ikediked   478631 /  105143  crw-rw-rw-rw null
_ikediked   478632 /  105143  crw-rw-rw-rw null
_ikediked   478633* 30 raw 2 0xd3258e88
_ikediked   478634* internet dgram udp *:500   
_ikediked   478635* internet dgram udp *:4500  
_ikediked   478636* internet6 dgram udp *:500  
_ikediked   478637* internet6 dgram udp *:4500 
_ikediked   478638* unix stream 0xd3e67c00 <-> 0xd3e67b80  
_ikediked   47863   10* unix stream 0xd3e67d00 <-> 0xd3e67c80  
_ikediked   47863   11 kqueue 0xd32a8e7c 0 state: W

patch below signature.

Regards,
-peter

Index: fstat.1
===
RCS file: /cvs/src/usr.bin/fstat/fstat.1,v
retrieving revision 1.56
diff -u -p -u -r1.56 fstat.1
--- fstat.1 16 Mar 2018 16:58:26 -  1.56
+++ fstat.1 7 Apr 2018 10:27:52 -
@@ -37,7 +37,7 @@
 .Nd display status of open files
 .Sh SYNOPSIS
 .Nm fstat
-.Op Fl fnosv
+.Op Fl fnorsv
 .Op Fl M Ar core
 .Op Fl N Ar system
 .Op Fl p Ar pid
@@ -86,6 +86,8 @@ Useful for checking progress as a proces
 This information is only visible to the user or superuser.
 .It Fl p Ar pid
 Report all files open by the specified process.
+.It Fl r
+Report which rdomain a socket belongs to.
 .It Fl s
 Report per file io statistics in two additional columns
 .Sq XFERS
Index: fstat.c
===
RCS file: /cvs/src/usr.bin/fstat/fstat.c,v
retrieving revision 1.92
diff -u -p -u -r1.92 fstat.c
--- fstat.c 6 Apr 2018 14:05:06 -   1.92
+++ fstat.c 7 Apr 2018 10:27:52 -
@@ -98,6 +98,7 @@ int   oflg;   /* display file offset */
 intsflg;   /* display file xfer/bytes counters */
 intvflg;   /* display errors in locating kernel data objects etc... */
 intcflg;   /* fuser only */
+intrflg;   /* display rdomains */
 
 intfuser;  /* 1 if we are fuser, 0 if we are fstat */
 intsigno;  /* signal to send (fuser only) */
@@ -148,7 +149,7 @@ main(int argc, char *argv[])
arg = -1;
what = KERN_FILE_BYPID;
nlistf = memf = NULL;
-   oflg = 0;
+   rflg = oflg = 0;
 
/* are we fstat(1) or fuser(1)? */
if (strcmp(__progname, "fuser") == 0) {
@@ -156,7 +157,7 @@ main(int argc, char *argv[])
optstr = "cfks:uM:N:";
} else {
fuser = 0;
-   optstr = "fnop:su:vN:M:";
+   optstr = "fnop:rsu:vN:M:";
}
 
/*
@@ -203,6 +204,9 @@ main(int argc, char *argv[])
}
what = 

this fixes gif(4) on 6.3

[Peter J. Philipp]

Hello,

Yesterday I wrote to misc@ with this:

https://marc.info/?l=openbsd-misc=152302592426018=2

I apologize with the inline paste, thunderbird is just not good enough for
this stuff.

Anyhow I have produced this patch after upgrading the 6.2 box to 6.3.  It all
works now:

Here is my config:

gif1: flags=8051 mtu 1280
index 12 priority 0 llprio 3
groups: gif
tunnel: inet6 fd43:5602:29bd:16:0:dead:beef:1 -> 
fd43:5602:29bd:16:0:dead:beef:16 ttl 64 nodf rdomain 2
inet 172.16.16.10 --> 172.16.16.16 netmask 0xff00
inet6 fe80::290:bff:fe19:5604%gif1 ->  prefixlen 64 scopeid 0xc

uranus$ ping6 fe80::baae:edff:fe73:a76c%gif1  
PING fe80::baae:edff:fe73:a76c%gif1 (fe80::baae:edff:fe73:a76c%gif1): 56 data 
bytes
64 bytes from fe80::baae:edff:fe73:a76c%gif1: icmp_seq=0 hlim=64 time=8.767 ms
64 bytes from fe80::baae:edff:fe73:a76c%gif1: icmp_seq=1 hlim=64 time=9.854 ms
^C
--- fe80::baae:edff:fe73:a76c%gif1 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 8.767/9.311/9.854/0.543 ms
uranus$ ping 172.16.16.16
PING 172.16.16.16 (172.16.16.16): 56 data bytes
64 bytes from 172.16.16.16: icmp_seq=0 ttl=255 time=10.329 ms
64 bytes from 172.16.16.16: icmp_seq=1 ttl=255 time=12.994 ms
^C
--- 172.16.16.16 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 10.329/11.662/12.994/1.332 ms

The patch follows:


Index: if_gif.c
===
RCS file: /cvs/src/sys/net/if_gif.c,v
retrieving revision 1.113
diff -u -p -u -r1.113 if_gif.c
--- if_gif.c15 Mar 2018 21:01:18 -  1.113
+++ if_gif.c7 Apr 2018 07:59:54 -
@@ -338,7 +338,7 @@ gif_send(struct gif_softc *sc, struct mb
ip6->ip6_flow = htonl(flow);
ip6->ip6_vfc |= IPV6_VERSION;
ip6->ip6_plen = htons(len);
-   ip6->ip6_nxt = IPPROTO_GRE;
+   ip6->ip6_nxt = proto;
ip6->ip6_hlim = ttl;
ip6->ip6_src = sc->sc_tunnel.t_src6;
ip6->ip6_dst = sc->sc_tunnel.t_dst6;


Best regards,
-peter

Re: return packets may not be desired to be scrubbed

[Peter J. Philipp]

On Thu, Mar 29, 2018 at 10:01:02PM +0200, Peter J. Philipp wrote:
...
> The end result is here.  I add 2 arguments to pf_scrub() for rule/state
> direction that is desired and direction that the packet is taking.  Then
> in random-id the logic does not scrub when we had an "outbound scrub" and
> the packets direction is inbound.
> 
> Happy Easter!  May your pf get a little faster!
> 
> -peter

I'd like to retract this patch.  Sorry, it doesn't do what I expected, I
didn't test it well enough, and did just now and it doesn't do what I had
imagined.  I'll re-visit this some time later.  Happy Easter, again!

Regards,
-peter

return packets may not be desired to be scrubbed

[Peter J. Philipp]

Hi,

While writing my own patches to the OpenBSD kernel and the pf subsystem, I
noticed that random-id packets scrub twice.  I noticed this by copying 
random-id's code and modifying it a little.  From that grew a little patch
for scrub and random-id and I'd like OpenBSD to consider it.  I sent a
mail to misc@ before asking "why scrub twice?" and didn't find an answer.
I did the work for myself and put it up for you in a small HTML file on
my website.  It is here:

http://centroid.eu/private/steg-patch.html

The end result is here.  I add 2 arguments to pf_scrub() for rule/state
direction that is desired and direction that the packet is taking.  Then
in random-id the logic does not scrub when we had an "outbound scrub" and
the packets direction is inbound.

Happy Easter!  May your pf get a little faster!

-peter


Index: sys/net/pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.1063
diff -u -p -u -r1.1063 pf.c
--- sys/net/pf.c6 Mar 2018 17:35:53 -   1.1063
+++ sys/net/pf.c29 Mar 2018 19:44:28 -
@@ -7018,7 +7018,7 @@ done:
}
 
pf_scrub(pd.m, s->state_flags, pd.af, s->min_ttl,
-   s->set_tos);
+   s->set_tos, s->direction, dir);
pf_tag_packet(pd.m, s->tag, s->rtableid[pd.didx]);
if (pqid || (pd.tos & IPTOS_LOWDELAY)) {
qid = s->pqid;
@@ -7031,7 +7031,7 @@ done:
}
} else {
pf_scrub(pd.m, r->scrub_flags, pd.af, r->min_ttl,
-   r->set_tos);
+   r->set_tos, r->direction, dir);
if (pqid || (pd.tos & IPTOS_LOWDELAY)) {
qid = r->pqid;
if (r->scrub_flags & PFSTATE_SETPRIO)
Index: sys/net/pf_norm.c
===
RCS file: /cvs/src/sys/net/pf_norm.c,v
retrieving revision 1.209
diff -u -p -u -r1.209 pf_norm.c
--- sys/net/pf_norm.c   6 Feb 2018 09:16:11 -   1.209
+++ sys/net/pf_norm.c   29 Mar 2018 19:44:28 -
@@ -1540,7 +1540,7 @@ pf_normalize_mss(struct pf_pdesc *pd, u_
 
 void
 pf_scrub(struct mbuf *m, u_int16_t flags, sa_family_t af, u_int8_t min_ttl,
-u_int8_t tos)
+u_int8_t tos, u_int8_t ruledir, u_int8_t dir)
 {
struct ip   *h = mtod(m, struct ip *);
 #ifdef INET6
@@ -1574,6 +1574,7 @@ pf_scrub(struct mbuf *m, u_int16_t flags
 
/* random-id, but not for fragments */
if (flags & PFSTATE_RANDOMID && af == AF_INET &&
-   !(h->ip_off & ~htons(IP_DF)))
+   !(h->ip_off & ~htons(IP_DF)) &&
+   (ruledir == PF_INOUT || ruledir == PF_FWD || ruledir == dir))
h->ip_id = htons(ip_randomid());
 }
Index: sys/net/pfvar.h
===
RCS file: /cvs/src/sys/net/pfvar.h,v
retrieving revision 1.476
diff -u -p -u -r1.476 pfvar.h
--- sys/net/pfvar.h 9 Feb 2018 09:35:03 -   1.476
+++ sys/net/pfvar.h 29 Mar 2018 19:44:28 -
@@ -1764,7 +1764,7 @@ int   pf_normalize_tcp_stateful(struct pf_
struct pf_state *, struct pf_state_peer *, struct pf_state_peer *,
int *);
 intpf_normalize_mss(struct pf_pdesc *, u_int16_t);
-void   pf_scrub(struct mbuf *, u_int16_t, sa_family_t, u_int8_t, u_int8_t);
+void   pf_scrub(struct mbuf *, u_int16_t, sa_family_t, u_int8_t, u_int8_t, 
u_int8_t, u_int8_t);
 int32_tpf_state_expires(const struct pf_state *);
 void   pf_purge_expired_fragments(void);
 intpf_routable(struct pf_addr *addr, sa_family_t af, struct pfi_kif *,

httpd/logger.c patch

[Peter J. Philipp]

Hi,

While auditing something in and around /usr/src/usr.sbin/httpd/logger.c 
(didn't find what I was looking for), I noticed that logger_log() was 
returning with an int but the return value was not processed at all.  Here 
is a small patch that makes the return value void.  I tested this patch
with compilation and running it.

Regards,
-peter


Index: logger.c
===
RCS file: /cvs/src/usr.sbin/httpd/logger.c,v
retrieving revision 1.21
diff -u -p -u -r1.21 logger.c
--- logger.c7 Feb 2018 03:28:05 -   1.21
+++ logger.c11 Mar 2018 21:38:38 -
@@ -41,7 +41,7 @@ intlogger_open_fd(struct imsg *);
 int logger_open(struct server *, struct server_config *, void *);
 voidlogger_init(struct privsep *, struct privsep_proc *p, void *);
 int logger_start(void);
-int logger_log(struct imsg *);
+voidlogger_log(struct imsg *);
 
 static uint32_t last_log_id = 0;
 
@@ -236,7 +236,7 @@ logger_start(void)
return (0);
 }
 
-int
+void
 logger_log(struct imsg *imsg)
 {
char*logline;
@@ -257,7 +257,7 @@ logger_log(struct imsg *imsg)
 
if (log == NULL || log->log_fd == -1) {
log_warnx("log file %s not opened", log ? log->log_name : "");
-   return (0);
+   return;
}
 
/* XXX get_string() would sanitize the string, but add a malloc */
@@ -268,10 +268,10 @@ logger_log(struct imsg *imsg)
 
if (dprintf(log->log_fd, "%s\n", logline) == -1) {
if (logger_start() == -1)
-   return (-1);
+   return;
}
 
-   return (0);
+   return;
 }
 
 int

save_errno for SHA256File()

[Peter J. Philipp]

Hi,

I have a program that constantly stalls on reading /etc/spwd.db with 
SHA256File() (from sha2.h).  Here is the program flow:

>
sha256file: Operation not permitted
on file: /etc/spwd.db
2f6574632f737077642e6462
^C
beta$ stat /etc/spwd.db
1024 78977 -rw-r- 1 root _shadow 327856 57344 "Oct 23 14:58:27 2017" "Oct 
17 13:54:38 2017" "Oct 17 13:54:38 2017" 16384 112 0 /etc/spwd.db
beta$ id
uid=0(root) gid=0(wheel) groups=0(wheel), 2(kmem), 3(sys), 4(tty), 5(operator), 
20(staff), 31(guest)
<

I don't know what's up but my research led me to create a patch for this 
function, it basically completes there what was started before because
close() can rewrite errno afaik.

If anyone has a hint as to why my SHA256File() returns with NULL and sets errno
to 0 that would really interest me.  My program does no setuid or seteuid at
all!  If you'd like to see the program, I can provide that but I wanted
to put preference to the patch here.

Patch (against 6.2) below signature.

-peter

Index: helper.c
===
RCS file: /cvs/src/lib/libc/hash/helper.c,v
retrieving revision 1.16
diff -u -p -u -r1.16 helper.c
--- helper.c21 Sep 2016 04:38:57 -  1.16
+++ helper.c23 Oct 2017 13:06:46 -
@@ -71,13 +71,17 @@ HASHFileChunk(const char *filename, char
return (NULL);
if (len == 0) {
if (fstat(fd, ) == -1) {
+   save_errno = errno;
close(fd);
+   errno = save_errno;
return (NULL);
}
len = sb.st_size;
}
if (off > 0 && lseek(fd, off, SEEK_SET) < 0) {
+   save_errno = errno;
close(fd);
+   errno = save_errno;
return (NULL);
}
 

Re: pointer corruption in exec_script.c

[Peter J. Philipp]

Yeah, thanks... I don't know what I was drinking yesterday it was only
ice-tea, sorry for that noise.  In retrospect I unearthed another hole
in my own non-committed implementation and it will need to be rewritten
to work ever.

While I profited on that knowledge, you guys did not or only indirectly,
again sorry.

-peter


On 05/09/17 23:14, Ted Unangst wrote:
> Peter J. Philipp wrote:
>> In my tinkering with the ELFSEC mechanism, I have noticed something
>> possibly troubling.  In /sys/kern/exec_script.c shellname is a pointer
>> to cp which is a pointer to hdrstr which is a pointer to epp->ep_hdr...
>> When calling the intended set shellname variable, later, I get part of the 
>> ELF
>> header of the program that the script executes.  This would be bogus IMO.
> i don't think the pointer is supposed to last that long. the check_exec call
> does all sorts of things to epp.

Re: pointer corruption in exec_script.c

[Peter J. Philipp]

On Tue, May 09, 2017 at 10:05:28PM +0200, Peter J. Philipp wrote:
> Hi,
> 
> In my tinkering with the ELFSEC mechanism, I have noticed something
> possibly troubling.  In /sys/kern/exec_script.c shellname is a pointer
> to cp which is a pointer to hdrstr which is a pointer to epp->ep_hdr...
> When calling the intended set shellname variable, later, I get part of the ELF
> header of the program that the script executes.  This would be bogus IMO.
> So I think what's needed here is a malloc, an strlcpy and a free later.
> 
> Here is a patch for review,

Sorry the patch is bad because I fail to check what I want to free for NULL.
You probably caught it.  Better let someone with lots of experience handle
this.

-peter




> Regards,
> -peter
> 
> 
> Index: exec_script.c
> ===
> RCS file: /cvs/src/sys/kern/exec_script.c,v
> retrieving revision 1.40
> diff -u -p -u -r1.40 exec_script.c
> --- exec_script.c 11 Feb 2017 19:51:06 -  1.40
> +++ exec_script.c 9 May 2017 19:44:46 -
> @@ -184,7 +184,8 @@ check_shell:
>  
>   /* set up the parameters for the recursive check_exec() call */
>   epp->ep_ndp->ni_dirfd = AT_FDCWD;
> - epp->ep_ndp->ni_dirp = shellname;
> + epp->ep_ndp->ni_dirp = malloc(shellnamelen + 1, M_EXEC, M_WAITOK);
> + strlcpy((char *)epp->ep_ndp->ni_dirp, shellname, shellnamelen + 1);
>   epp->ep_ndp->ni_segflg = UIO_SYSSPACE;
>   epp->ep_flags |= EXEC_INDIR;
>  
> @@ -271,6 +272,9 @@ fail:
>   }
>   free(shellargp, M_EXEC, 4 * sizeof(char *));
>   }
> +
> + /* free epp->ep_ndp->ni_dirp */
> + free((char *)epp->ep_ndp->ni_dirp, M_EXEC, shellnamelen + 1);
>  
>   /*
>* free any vmspace-creation commands,

pointer corruption in exec_script.c

[Peter J. Philipp]

Hi,

In my tinkering with the ELFSEC mechanism, I have noticed something
possibly troubling.  In /sys/kern/exec_script.c shellname is a pointer
to cp which is a pointer to hdrstr which is a pointer to epp->ep_hdr...
When calling the intended set shellname variable, later, I get part of the ELF
header of the program that the script executes.  This would be bogus IMO.
So I think what's needed here is a malloc, an strlcpy and a free later.

Here is a patch for review,

Regards,
-peter


Index: exec_script.c
===
RCS file: /cvs/src/sys/kern/exec_script.c,v
retrieving revision 1.40
diff -u -p -u -r1.40 exec_script.c
--- exec_script.c   11 Feb 2017 19:51:06 -  1.40
+++ exec_script.c   9 May 2017 19:44:46 -
@@ -184,7 +184,8 @@ check_shell:
 
/* set up the parameters for the recursive check_exec() call */
epp->ep_ndp->ni_dirfd = AT_FDCWD;
-   epp->ep_ndp->ni_dirp = shellname;
+   epp->ep_ndp->ni_dirp = malloc(shellnamelen + 1, M_EXEC, M_WAITOK);
+   strlcpy((char *)epp->ep_ndp->ni_dirp, shellname, shellnamelen + 1);
epp->ep_ndp->ni_segflg = UIO_SYSSPACE;
epp->ep_flags |= EXEC_INDIR;
 
@@ -271,6 +272,9 @@ fail:
}
free(shellargp, M_EXEC, 4 * sizeof(char *));
}
+
+   /* free epp->ep_ndp->ni_dirp */
+   free((char *)epp->ep_ndp->ni_dirp, M_EXEC, shellnamelen + 1);
 
/*
 * free any vmspace-creation commands,

Re: My ELFSEC implementation (signed binaries for amd64)

[Peter J. Philipp]

On Fri, May 05, 2017 at 10:48:30PM +, Christian Weisgerber wrote:
> On 2017-05-05, "Peter J. Philipp" <p...@centroid.eu> wrote:
> 
> > This is my second official contribution to what I call ELFSEC, it places a 
> > signature in binaries, in the ELF header to be exact.
> -snip-
> 
> How does this defend against binary code introduced as a shared
> library by way of LD_LIBRARY_PATH or LD_PRELOAD?
> 
> -- 
> Christian "naddy" Weisgerber  na...@mips.inka.de

Hi,

It doesn't check shared libraries, afaik.  If it did that then my test 
environment wouldn't work.  So this is a gaping hole.  I'll need some time 
to see where in the kernel shared libraries have their ELF header checked.  
Maybe the fix is trivial...

Regards,
-peter

Re: My ELFSEC implementation (signed binaries for amd64)

[Peter J. Philipp]

On Fri, May 05, 2017 at 05:25:57PM +0100, Kevin Chadwick wrote:
> > There was concern about my use of MD5 HMAC's so I 
> > took them out.  The ELF header of 32 bit systems is too small to fit
> > SHA256 checksums, so I'm leaving it out.
> 
> Have you considered CMAC which can be truncated if need be and also
> could take advantage of AES acceleration.
> 
> Alternatively, signify perhaps.

I never considered that.  In discussion with a friend, I did consider
truncating a SHA256 HMAC, but that didn't feel right.

If CMAC's can be truncated then this entire implementation can be rewritten
to not truncate for 64 bit machines and truncate for 32 bit machines.

The code to this should be straight forward and I'll work on that next I
guess.  I have a 32 bit firewall here that I'd love to ELFSEC.

I know too little about signify in-kernel, I know I love it as a userland
program.

Regards,
-peter

My ELFSEC implementation (signed binaries for amd64)

[Peter J. Philipp]

2);
+   if (error != 0) {
+   printf("elfsec debug: elf_read_from %d\n", 
error);
+   VOP_CLOSE(esvp, FREAD, p->p_ucred, p);
+   free(ph2, M_TEMP, phsize2);
+   goto bad;
+   }
+
+   HMAC_SHA256_Update(, (u_int8_t *)ph2, phsize2);
+
+   memset(, 0, sizeof(es.digest));
+   HMAC_SHA256_Final(es.digest, );
+   free(ph2, M_TEMP, phsize2);
+
+   VOP_CLOSE(esvp, FREAD, p->p_ucred, p);
+
+   /* now compare the elfsechdr with the checksum */
+   eshdr = (ELFSEChdr *)pp;
+   if (memcmp(eshdr->hmac, es.digest, 
SHA256_DIGEST_LENGTH) != 0) {
+   printf("ELFSEC violation!  Not executing binary 
(%s) for uid %u\n", epp->ep_ndp->ni_dirp, p->p_ucred->cr_uid);
+   goto bad;
+   }
+   break;
+#endif /* __amd64__ */
+
default:
/*
 * Not fatal, we don't need to understand everything
@@ -710,6 +823,11 @@ exec_elf_makecmds(struct proc *p, struct
 */
break;
}
+   }
+
+   if (elfsecactive == 1 && visited_elfsec == 0 && suser(p, 0) != 0) {
+   printf("ELFSEC violation!  Not executing binary (%s) for uid 
%u\n", epp->ep_ndp->ni_dirp, p->p_ucred->cr_uid);
+   goto bad;
}
 
phdr += exe_base;
Index: sys/kern/exec_elfsec.c
===
RCS file: sys/kern/exec_elfsec.c
diff -N sys/kern/exec_elfsec.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ sys/kern/exec_elfsec.c  5 May 2017 09:34:47 -
@@ -0,0 +1,49 @@
+/* exec_elfsec.c - $Id$ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+
+
+int elfsecactive = 0;
+char elfseckey[32];
+
+int
+sys_elfsec(struct proc *p, void *v, register_t *retval)
+{
+   struct sys_elfsec_args /* {
+   syscallarg(char *) buf;
+   syscallarg(size_t) nbyte;
+   } */ *uap = v;
+
+   char *key;
+   size_t size;
+   int error;
+
+   if (securelevel > 0)
+   return (EPERM);
+
+   if ((error = suser(p, 0)) != 0)
+   return (error);
+
+key = SCARG(uap, buf);
+size = SCARG(uap, nbyte);
+
+   if (size != sizeof(elfseckey)) 
+   return (EINVAL);
+
+   if ((error = copyin(key, , sizeof(elfseckey))) != 0)
+   return (error);
+
+   elfsecactive = 1;
+   printf("elfsec active\n");
+
+   return (0);
+}
Index: sys/kern/init_sysent.c
===
RCS file: /var/cvsroot/src/src/sys/kern/init_sysent.c,v
retrieving revision 1.1.1.1
diff -u -p -u -r1.1.1.1 init_sysent.c
--- sys/kern/init_sysent.c  4 May 2017 19:58:28 -   1.1.1.1
+++ sys/kern/init_sysent.c  5 May 2017 09:34:41 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: init_sysent.c,v 1.186 2016/09/26 16:43:58 jca Exp $   */
+/* $OpenBSD$   */
 
 /*
  * System call switch table.
@@ -751,5 +751,7 @@ struct sysent sysent[] = {
sys___set_tcb },/* 329 = __set_tcb */
{ 0, 0, SY_NOLOCK | 0,
sys___get_tcb },/* 330 = __get_tcb */
+   { 2, s(struct sys_elfsec_args), 0,
+   sys_elfsec },   /* 331 = elfsec */
 };
 
Index: sys/kern/syscalls.c
===
RCS file: /var/cvsroot/src/src/sys/kern/syscalls.c,v
retrieving revision 1.1.1.1
diff -u -p -u -r1.1.1.1 syscalls.c
--- sys/kern/syscalls.c 4 May 2017 19:58:28 -   1.1.1.1
+++ sys/kern/syscalls.c 5 May 2017 09:34:34 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: syscalls.c,v 1.185 2016/09/26 16:43:58 jca Exp $  */
+/* $OpenBSD$   */
 
 /*
  * System call names.
@@ -393,4 +393,5 @@ char *syscallnames[] = {
"#328 (obsolete __tfork51)",    /* 328 = obsolete __tfork51 */
"__set_tcb",/* 329 = __set_tcb */
"__get_tcb",/* 330 = __get_tcb */
+   "elfsec",   /* 331 = elfsec */
 };
Index: sys/kern/syscalls.master
===
RCS file: /var/cvsroot/src/src/sys/kern/syscalls.master,v
retrieving revision 1.1.1.1
diff -u -p -u -r1.1.1.1 syscalls.master
--- sys/kern/syscalls.master4 May 2017 19:58:28 -   1.1.1.1
+++ sys/kern/syscalls.master5 May 2017 09:34:28 -
@@ -563,3 +563,4 @@
 328OBSOL   __tfork51

Re: asr: support for RES_USE_DNSSEC

[Peter J. Philipp]

On Mon, Feb 27, 2017 at 11:14:13AM +0100, Jeremie Courreges-Anglas wrote:
> "Peter J. Philipp" <p...@centroid.eu> writes:
> 
> > On Mon, Feb 27, 2017 at 10:26:48AM +0100, Peter J. Philipp wrote:
> >> I had a patch somewhere for TSIG as well somewhere, give me some time to
> >> find it.  TSIG can secure the channel as well, but my implementation wasn't
> >> all that pretty.
> >
> > Here is the patch, it would need fixing up, and it only would work with BIND
> > nameservers currently :-(.
> >
> > http://marc.info/?l=openbsd-tech=145656997013119=2
> 
> Interesting.  I can't speak for others but I don't think that TSIG is
> a good solution.  Shared secrets don't buy us much, especially if we
> have to store them in /etc/resolv.conf.
> 
> -- 
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

You're right.  If I may point you to RFC 4033 section 7 (not a long read) it
talks about securing this channel for stub resolvers.  It actually talks about
SIG(0) or TSIG (like my example, which isn't the best use).  And it talks about
IPSEC to secure the channel (another good way) but who can say that they have
an IPSEC tunnel to their nameserver especially when it's the ISP's?  Really
all that we're left with (if we want security) is a local recursive nameserver.

I think making the stub resolver security aware and validating would be a good
thing but it's not a 1 person effort unless you can invest 2-3 years into it
and work for a living on the side.  I'm open to help (still) and I know I'm
talking to the right people here, yet a group should form and a mandate be set
in place for this to work best.

Cheers,
-peter

Re: asr: support for RES_USE_DNSSEC

[Peter J. Philipp]

On Mon, Feb 27, 2017 at 10:26:48AM +0100, Peter J. Philipp wrote:
> I had a patch somewhere for TSIG as well somewhere, give me some time to
> find it.  TSIG can secure the channel as well, but my implementation wasn't
> all that pretty.

Here is the patch, it would need fixing up, and it only would work with BIND
nameservers currently :-(.

http://marc.info/?l=openbsd-tech=145656997013119=2

Regards,

-peter

Re: asr: support for RES_USE_DNSSEC

[Peter J. Philipp]

On Mon, Feb 27, 2017 at 10:19:52AM +0100, Jeremie Courreges-Anglas wrote:
> > Thanks for considering my patch.  OpenBSD tremendously improves with this 
> > work of yours, I'm all for it!  However to make use of this DNSSEC mode, 
> > the channel to the recursive DNS server has to be absolutely secure (for DO 
> > or AD in a response).  
> 
> Yes, the assumption is that the resolver listed in /etc/resolv.conf is
> trusted, including the network in between.
> 
> The easiest method is to run unbound on 127.0.0.1 with
> "auto-trust-anchor-file".

I had a patch somewhere for TSIG as well somewhere, give me some time to
find it.  TSIG can secure the channel as well, but my implementation wasn't
all that pretty.

> > My looming question that noone wants to ask because it's a bit (a lot)
> > of work for the programmer(s) is: can we work toward the goal of a 
> > validating
> > dnssec resolver?
> 
> Please clarify: do you mean "stub resolver" here, ie the code that runs
> in libc?

Yes, that is what I mean.  That way the recursive dns server doesn't have to
be on the same box and answers are validated locally.

Regards,
-peter

Re: asr: support for RES_USE_DNSSEC

[Peter J. Philipp]

On Mon, Feb 27, 2017 at 12:35:33AM +0100, Jeremie Courreges-Anglas wrote:
> Setting the AD flag for a query is possible, however those semantics are
> newer than the EDNS0 extension.  As far as I know, rfc6840 introduced
> AD=1 for queries in 2013, whereas rfc3225 specifies the DO flag since
> 2001.
> 
>   https://tools.ietf.org/html/rfc3225
>   https://tools.ietf.org/html/rfc6840#section-5.7
> 
> Also EDNS0 can give you more than 512 bytes on UDP (if the resolver
> supports it).  So I thought I'd rather implement RES_USE_DNSSEC on top
> of EDNS0.
> 
> -- 
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Jeremie & tech@,

Thanks for considering my patch.  OpenBSD tremendously improves with this 
work of yours, I'm all for it!  However to make use of this DNSSEC mode, 
the channel to the recursive DNS server has to be absolutely secure (for DO 
or AD in a response).  

My looming question that noone wants to ask because it's a bit (a lot)
of work for the programmer(s) is: can we work toward the goal of a validating
dnssec resolver?  (I know it's a lot of work, we'd need a group and an 
architect perhaps, ultimately the RFC's are the guideline)  Luckily I'm
between projects outside of my main job and I think I can contribute a little.

Is any (DNS) security programmers interested in this?  I can come to Paris
for EuroBSDCon to get together for this matter, but I'd want to get started
earlier if we form a small group for that matter.

Regards,
-peter

Re: asr: support for RES_USE_DNSSEC

[Peter J. Philipp]

Hi,

I'm not the best in reading patches, so I'm going to query you.  Does
your patch check for the "AD" flag from the resolver?  As basically a
DNSSEC able recursive nameserver should set this meaning it has
authenticated the data.  I wrote a patch for DNSSEC (possibly erroneous
by comparing it to you) and posted it to #opensmtpd in hopes that eric
would see it.  Much of that functionality is superfluous now but it does
have an "AD_MASK" check.

Here is my patch from last year, which I gave up on, feel free to cherry
pick anything needed out of it.  You'll see some similarities but they
are different enough to show two different peoples work.

http://centroid.eu/private/dnssec.patch.txt

Yours is a lot more complete of course.

Cheers,

-peter

On 02/25/17 19:24, Jeremie Courreges-Anglas wrote:
> Jeremie Courreges-Anglas  writes:
>
>> This flag is useful for software that wants to rely on the resolver to
>> perform DNSSEC validation.  Among the use cases there are DANE and SSHFP
>> records, and the obvious interfaces that I think are useful are
>> res_mkquery and getrrsetbyname.  The latter still doesn't support
>> DNSSEC, another diff will follow.
> Diff on top of the previous one.  I'd like to make getrrsetbyname(3)
> "use" RES_USE_DNSSEC again.  This would improve support for ssh -o
> VerifyHostKeyDNS (SSHFP records).
>
> The "easy" way would be something like:
>
> Index: getrrsetbyname_async.c
> ===
> RCS file: /d/cvs/src/lib/libc/asr/getrrsetbyname_async.c,v
> retrieving revision 1.11
> diff -u -p -p -u -r1.11 getrrsetbyname_async.c
> --- getrrsetbyname_async.c23 Feb 2017 17:04:02 -  1.11
> +++ getrrsetbyname_async.c25 Feb 2017 17:25:25 -
> @@ -42,6 +42,7 @@ getrrsetbyname_async(const char *hostnam
>   struct asr_query *as;
>  
>   ac = _asr_use_resolver(asr);
> + ac->ac_options |= RES_USE_DNSSEC;
>   if ((as = _asr_async_new(ac, ASR_GETRRSETBYNAME)) == NULL)
>   goto abort; /* errno set */
>   as->as_run = getrrsetbyname_async_run;
>
> IIUC this means that we modify the thread-local resolver options used by
> subsequent queries.  Cleaning up by resetting the flag before returning
> doesn't work in all cases because you could have overlap between two
> active getrrsetbyname_async and eg getaddrinfo_async contexts.
>
> The diff below instead adds an as_flags member to struct asr_query, and
> merges the flags of the various union members.  struct rrset and struct
> ni keep their flags member, as they are a different kind of flags.
> A subset of as_flags is passed down to the child ASR_SEND subq, the only
> flag that is inherited right now is ASYNC_DNSSEC, which allows
> getrrsetbyname_async to communicate its intent.
>
> That's a bit of churn for a small improvement, maybe there is a simpler
> diff?
>
> Comments welcome.
>
>
> diff -pruN asr.1/asr.c asr/asr.c
> --- asr.1/asr.c   Sat Feb 25 17:57:40 2017
> +++ asr/asr.c Sat Feb 25 17:58:10 2017
> @@ -244,7 +244,7 @@ _asr_async_free(struct asr_query *as)
>   case ASR_SEND:
>   if (as->as_fd != -1)
>   close(as->as_fd);
> - if (as->as.dns.obuf && !(as->as.dns.flags & ASYNC_EXTOBUF))
> + if (as->as.dns.obuf && !(as->as_flags & ASYNC_EXTOBUF))
>   free(as->as.dns.obuf);
>   if (as->as.dns.ibuf)
>   free(as->as.dns.ibuf);
> diff -pruN asr.1/asr_private.h asr/asr_private.h
> --- asr.1/asr_private.h   Sat Feb 25 17:57:40 2017
> +++ asr/asr_private.h Sat Feb 25 18:12:23 2017
> @@ -156,15 +156,19 @@ struct asr {
>  #define  ASYNC_NODATA0x0100
>  #define  ASYNC_AGAIN 0x0200
>  
> +#define  ASYNC_DNSSEC0x1000
>  #define  ASYNC_EXTOBUF   0x2000
>  
>  #define  ASYNC_NO_INET   0x0001
>  #define  ASYNC_NO_INET6  0x0002
>  
> +#define  ASYNC_ASR_SEND_MASK (ASYNC_DNSSEC)
> +
>  struct asr_query {
>   int (*as_run)(struct asr_query *, struct asr_result *);
>   struct asr_ctx  *as_ctx;
>   int  as_type;
> + int  as_flags;
>   int  as_state;
>  
>   /* cond */
> @@ -183,7 +187,6 @@ struct asr_query {
>  
>   union {
>   struct {
> - int  flags;
>   uint16_t reqid;
>   int  class;
>   int  type;
> @@ -206,7 +209,6 @@ struct asr_query {
>   } dns;
>  
>   struct {
> - int  flags;
>   int  class;
>   int  type;
>   char*name;
> @@ -249,7 +251,6 @@ struct asr_query {
>   char*fqdn;
>   struct addrinfo 

pf.conf.5 patch

[Peter J. Philipp]

Hi,

Please consider this patch for the pf.conf.5 manpage, it took me hours to
figure out what went wrong with my network after parts stopped working due
to this example.  Changing it to what I have now makes it work right.

Symptoms without this fix caused IPv6 neighbours to stop pinging/being 
available and even the NAT64 did not work anymore.

Thank you,

-peter


Index: pf.conf.5
===
RCS file: /cvs/src/share/man/man5/pf.conf.5,v
retrieving revision 1.552
diff -u -p -u -r1.552 pf.conf.5
--- pf.conf.5   14 May 2016 08:21:40 -  1.552
+++ pf.conf.5   24 Sep 2016 09:55:23 -
@@ -863,8 +863,8 @@ translated to 2001:db8::c633:6464.
 .Pp
 In the reverse case the following rules are identical:
 .Bd -literal -offset indent
-pass in inet6 af-to inet from 198.51.100.1 to 0.0.0.0/0
-pass in inet6 af-to inet from 198.51.100.1
+pass in inet6 from any to 64:ff9b::/96 af-to inet from 198.51.100.1 to 
0.0.0.0/0
+pass in inet6 from any to 64:ff9b::/96 af-to inet from 198.51.100.1
 .Ed
 .Pp
 The destination IPv4 address is assumed to be embedded inside the

TSIG authentication in libasr

[Peter J. Philipp]

Hi,

I have a patch for TSIG authentication in libasr.  It is enabled by the "tsig"
keyword in /etc/resolv.conf.  My /etc/resolv.conf looks like this:

search centroid.eu
#nameserver 192.168.34.1
nameserver 200.46.208.61
tsig secret-key.:DONTTRY
lookup file bind

The HMAC over the TSIG is SHA256-HMAC by default but this can be expanded if
willed.

I have tested this by relinking ping and running chrome on websites that I
never visited before, it works.  If you need help setting this up on a BIND
nameserver so that it can recurse a TSIG authenticated lookup, let me know
I can share my example.

The code follows.  If there is an interest for this, I'll clean it up and 
write a manpage, I worked on getting this working as a start.


? asr.patch
Index: asr.c
===
RCS file: /cvs/src/lib/libc/asr/asr.c,v
retrieving revision 1.50
diff -u -p -u -r1.50 asr.c
--- asr.c   16 Dec 2015 16:32:30 -  1.50
+++ asr.c   27 Feb 2016 10:26:33 -
@@ -527,6 +527,7 @@ pass0(char **tok, int n, struct asr_ctx 
 {
int  i, j, d;
const char  *e;
+   char*p;
struct sockaddr_storage ss;
 
if (!strcmp(tok[0], "nameserver")) {
@@ -548,6 +549,32 @@ pass0(char **tok, int n, struct asr_ctx 
return;
ac->ac_domain = strdup(tok[1]);
 
+   } else if (!strcmp(tok[0], "tsig")) {
+   if (n != 2)
+   return;
+   if (ac->ac_use_tsig)
+   return;
+
+   p = strchr(tok[1], ':');
+   if (p == NULL)
+   return;
+
+   *p = '\0';
+   if (_asr_dname_from_fqdn(tok[1], ac->ac_tsig_key, 
sizeof(ac->ac_tsig_key)) == -1)
+   return;
+
+   /* RFC 4635 */
+   if (_asr_dname_from_fqdn("hmac-sha256.", ac->ac_dn_algorithm, 
sizeof(ac->ac_dn_algorithm)) == -1)
+   return;
+
+   p++;
+   ac->ac_use_tsig = 1;
+   
+   ac->ac_dn_algorithm_len = strlen(ac->ac_dn_algorithm);
+   ac->ac_algorithm_size = 32;
+
+   ac->ac_tsig_password = strdup(p);
+   
} else if (!strcmp(tok[0], "lookup")) {
/* ensure that each lookup is only given once */
for (i = 1; i < n; i++)
Index: asr_private.h
===
RCS file: /cvs/src/lib/libc/asr/asr_private.h,v
retrieving revision 1.38
diff -u -p -u -r1.38 asr_private.h
--- asr_private.h   16 Dec 2015 16:32:30 -  1.38
+++ asr_private.h   27 Feb 2016 10:26:33 -
@@ -135,7 +135,13 @@ struct asr_ctx {
int  ac_nstimeout;
int  ac_nsretries;
struct sockaddr *ac_ns[ASR_MAXNS];
-
+   /* pjp below */
+   int  ac_use_tsig;
+   char*ac_tsig_password;
+   char ac_tsig_key[MAXDNAME];
+   char ac_dn_algorithm[MAXDNAME];
+   int  ac_dn_algorithm_len;
+   int  ac_algorithm_size;
 };
 
 struct asr {
@@ -301,6 +307,7 @@ __BEGIN_HIDDEN_DECLS
 void _asr_pack_init(struct asr_pack *, char *, size_t);
 int _asr_pack_header(struct asr_pack *, const struct asr_dns_header *);
 int _asr_pack_query(struct asr_pack *, uint16_t, uint16_t, const char *);
+int _asr_tsig_query(struct asr_pack *, const struct asr_dns_header *, struct 
asr_ctx *, const char *, uint16_t);
 void _asr_unpack_init(struct asr_unpack *, const char *, size_t);
 int _asr_unpack_header(struct asr_unpack *, struct asr_dns_header *);
 int _asr_unpack_query(struct asr_unpack *, struct asr_dns_query *);
@@ -308,6 +315,7 @@ int _asr_unpack_rr(struct asr_unpack *, 
 int _asr_sockaddr_from_str(struct sockaddr *, int, const char *);
 ssize_t _asr_dname_from_fqdn(const char *, char *, size_t);
 ssize_t _asr_addr_as_fqdn(const char *, int, char *, size_t);
+void _asr_hmac_sha256(u_char *text, int text_len, u_char *key, int key_len, 
char *digest);
 
 /* asr.c */
 static void *_asr_resolver(void);
Index: asr_utils.c
===
RCS file: /cvs/src/lib/libc/asr/asr_utils.c,v
retrieving revision 1.13
diff -u -p -u -r1.13 asr_utils.c
--- asr_utils.c 9 Sep 2015 15:49:34 -   1.13
+++ asr_utils.c 27 Feb 2016 10:26:34 -
@@ -32,6 +32,8 @@
 #include 
 #include 
 
+#include 
+
 #include "asr_private.h"
 
 static int dname_check_label(const char *, size_t);
@@ -373,6 +375,14 @@ pack_data(struct asr_pack *p, const void
 }
 
 static int
+pack_u32(struct asr_pack *p, uint32_t v)
+{
+   v = htonl(v);
+
+   return (pack_data(p, , 4));
+}
+
+static int
 pack_u16(struct asr_pack *p, uint16_t v)
 {
v = htons(v);
@@ -415,6 +425,89 @@ _asr_pack_query(struct asr_pack *p, uint
 }
 
 int
+_asr_tsig_query(struct asr_pack *p, const struct 

Re: I have a program I wish to submit for the base

[Peter J. Philipp]

Luke, don't feel bad.  Very little code that is "offered" gets taken by
the OpenBSD project.  OpenBSD really only takes when they see benefit
for the project.  An example for that is openssh.  What you really want
to do is focus on your own projects and make them available somewhere so
that when OpenBSD gets wind of it they'll take it.

Cheers,

-peter

On 01/29/16 09:19, Nicholas Marriott wrote:
> Firstly, I don't think we need this in base and I think there is little
> to no chance of it being taken, even if the code is improved.
>
> Secondly:
>
> - The code is still miles off style(9) and isn't really a consistent
>   style within itself either.
>
> - Forking uname(1)? What? No offence, but that is hilarious :-). Why
>   fork uname(1) for uname(3) but not date(1) for gettimeofday(2)?
>
> - Why would you fork sed either?
>
> I think C is the wrong tool for this. Why not write a shell, perl, or
> python script?
>
> Then if people start to use it you could make a port.
>
>
>
> On Fri, Jan 29, 2016 at 01:34:30AM -0600, Luke Small wrote:
>> I think I fixed all your suggestions. I don't strictly adhere to kernel
>> normal in the use of comments and I parse command-line arguments without
>> using getopt(3), but the method is robust.
>>
>> -Luke
>>
>> >
>>  o I definitely don't think camel case will be accepted
>>
>>  o I'm pretty sure strtonum(3) is strongly preferred over strtod(3) et al.
>>

httpd patch

[Peter J. Philipp]

Hello,

I had nothing better to do tonight after work so I read a little in httpd.
I have come up with a patch for i386 and any architecture where off_t != 
size_t.

So on i386 there is this:

uranus$ ./sizetest
off_t = 8
size_t = 4

and I have these files in a directory:

uranus$ ls -lhi
total 12672
364207 -rw-r--r--  3 root  daemon   4.9G Jan 15 21:06 output.txt
364207 -rw-r--r--  3 root  daemon   4.9G Jan 15 21:06 output2.txt
364207 -rw-r--r--  3 root  daemon   4.9G Jan 15 21:06 output3.txt

A download (cancelled, but it doesn't matter) of the httpd without my patch
looks like so:

default 192.168.1.127 - - [15/Jan/2016:21:11:55 +0100] "GET /public/output2.txt 
HTTP/1.1" 200 948961280 "http://192.168.1.1/public/; "Mozilla/5.0 (X11; OpenBSD 
amd64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.157 
Safari/537.36"

A download (cancelled again) of the httpd with my patch looks like so:

default 192.168.1.127 - - [15/Jan/2016:21:18:07 +0100] "GET /public/output3.txt 
HTTP/1.1" 200 5243928576 "http://192.168.1.1/public/; "Mozilla/5.0 (X11; 
OpenBSD amd64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.157 
Safari/537.36"

It looks accurate in this case.  Checking again with ls:

uranus$ ls -li output3.txt  
364207 -rw-r--r--  3 root  daemon  5243928576 Jan 15 21:06 output3.txt

Absolutely.

patch follows:

Cheers,
-peter

? httpd.patch
Index: httpd.h
===
RCS file: /cvs/src/usr.sbin/httpd/httpd.h,v
retrieving revision 1.96
diff -u -p -u -r1.96 httpd.h
--- httpd.h 3 Aug 2015 11:45:17 -   1.96
+++ httpd.h 15 Jan 2016 20:19:12 -
@@ -602,7 +602,7 @@ const char *
 server_http_host(struct sockaddr_storage *, char *, size_t);
 char   *server_http_parsehost(char *, char *, size_t, int *);
 ssize_t server_http_time(time_t, char *, size_t);
-int server_log_http(struct client *, u_int, size_t);
+int server_log_http(struct client *, u_int, off_t);
 
 /* server_file.c */
 int server_file(struct httpd *, struct client *);
Index: server_http.c
===
RCS file: /cvs/src/usr.sbin/httpd/server_http.c,v
retrieving revision 1.96
diff -u -p -u -r1.96 server_http.c
--- server_http.c   31 Jul 2015 00:10:51 -  1.96
+++ server_http.c   15 Jan 2016 20:19:12 -
@@ -1450,7 +1450,7 @@ server_httperror_cmp(const void *a, cons
 }
 
 int
-server_log_http(struct client *clt, u_int code, size_t len)
+server_log_http(struct client *clt, u_int code, off_t len)
 {
static char  tstamp[64];
static char  ip[INET6_ADDRSTRLEN];
@@ -1511,7 +1511,7 @@ server_log_http(struct client *clt, u_in
goto done;
 
ret = evbuffer_add_printf(clt->clt_log,
-   "%s %s - %s [%s] \"%s %s%s%s%s%s\" %03d %zu\n",
+   "%s %s - %s [%s] \"%s %s%s%s%s%s\" %03d %qu\n",
srv_conf->name, ip, clt->clt_remote_user == NULL ? "-" :
user, tstamp,
server_httpmethod_byid(desc->http_method),
@@ -1559,7 +1559,7 @@ server_log_http(struct client *clt, u_in
 
ret = evbuffer_add_printf(clt->clt_log,
"%s %s - %s [%s] \"%s %s%s%s%s%s\""
-   " %03d %zu \"%s\" \"%s\"\n",
+   " %03d %qu \"%s\" \"%s\"\n",
srv_conf->name, ip, clt->clt_remote_user == NULL ? "-" :
user, tstamp,
server_httpmethod_byid(desc->http_method),

Re: httpd patch

[Peter J. Philipp]

On Fri, Jan 15, 2016 at 08:36:05PM +, Peter J. Philipp wrote:
> Hello,
> 
> I had nothing better to do tonight after work so I read a little in httpd.
> I have come up with a patch for i386 and any architecture where off_t != 
> size_t.
> 
> So on i386 there is this:
> 
> uranus$ ./sizetest
> off_t = 8
> size_t = 4
> 
> and I have these files in a directory:
> 
> uranus$ ls -lhi
> total 12672
> 364207 -rw-r--r--  3 root  daemon   4.9G Jan 15 21:06 output.txt
> 364207 -rw-r--r--  3 root  daemon   4.9G Jan 15 21:06 output2.txt
> 364207 -rw-r--r--  3 root  daemon   4.9G Jan 15 21:06 output3.txt
> 
> A download (cancelled, but it doesn't matter) of the httpd without my patch
> looks like so:
> 
> default 192.168.1.127 - - [15/Jan/2016:21:11:55 +0100] "GET 
> /public/output2.txt HTTP/1.1" 200 948961280 "http://192.168.1.1/public/; 
> "Mozilla/5.0 (X11; OpenBSD amd64) AppleWebKit/537.36 (KHTML, like Gecko) 
> Chrome/44.0.2403.157 Safari/537.36"
> 
> A download (cancelled again) of the httpd with my patch looks like so:
> 
> default 192.168.1.127 - - [15/Jan/2016:21:18:07 +0100] "GET 
> /public/output3.txt HTTP/1.1" 200 5243928576 "http://192.168.1.1/public/; 
> "Mozilla/5.0 (X11; OpenBSD amd64) AppleWebKit/537.36 (KHTML, like Gecko) 
> Chrome/44.0.2403.157 Safari/537.36"
> 
> It looks accurate in this case.  Checking again with ls:
> 
> uranus$ ls -li output3.txt  
> 364207 -rw-r--r--  3 root  daemon  5243928576 Jan 15 21:06 output3.txt
> 
> Absolutely.
> 
> patch follows:
> 
> Cheers,
> -peter
> 
> ? httpd.patch
> Index: httpd.h
> ===
> RCS file: /cvs/src/usr.sbin/httpd/httpd.h,v
> retrieving revision 1.96
> diff -u -p -u -r1.96 httpd.h
> --- httpd.h   3 Aug 2015 11:45:17 -   1.96
> +++ httpd.h   15 Jan 2016 20:19:12 -
> @@ -602,7 +602,7 @@ const char *
>server_http_host(struct sockaddr_storage *, char *, size_t);
>  char *server_http_parsehost(char *, char *, size_t, int *);
>  ssize_t   server_http_time(time_t, char *, size_t);
> -int   server_log_http(struct client *, u_int, size_t);
> +int   server_log_http(struct client *, u_int, off_t);
>  
>  /* server_file.c */
>  int   server_file(struct httpd *, struct client *);
> Index: server_http.c
> ===
> RCS file: /cvs/src/usr.sbin/httpd/server_http.c,v
> retrieving revision 1.96
> diff -u -p -u -r1.96 server_http.c
> --- server_http.c 31 Jul 2015 00:10:51 -  1.96
> +++ server_http.c 15 Jan 2016 20:19:12 -
> @@ -1450,7 +1450,7 @@ server_httperror_cmp(const void *a, cons
>  }
>  
>  int
> -server_log_http(struct client *clt, u_int code, size_t len)
> +server_log_http(struct client *clt, u_int code, off_t len)
>  {
>   static char  tstamp[64];
>   static char  ip[INET6_ADDRSTRLEN];
> @@ -1511,7 +1511,7 @@ server_log_http(struct client *clt, u_in
>   goto done;
>  
>   ret = evbuffer_add_printf(clt->clt_log,
> - "%s %s - %s [%s] \"%s %s%s%s%s%s\" %03d %zu\n",
> + "%s %s - %s [%s] \"%s %s%s%s%s%s\" %03d %qu\n",
>   srv_conf->name, ip, clt->clt_remote_user == NULL ? "-" :
>   user, tstamp,
>   server_httpmethod_byid(desc->http_method),
> @@ -1559,7 +1559,7 @@ server_log_http(struct client *clt, u_in
>  
>   ret = evbuffer_add_printf(clt->clt_log,
>   "%s %s - %s [%s] \"%s %s%s%s%s%s\""
> - " %03d %zu \"%s\" \"%s\"\n",
> + " %03d %qu \"%s\" \"%s\"\n",
>   srv_conf->name, ip, clt->clt_remote_user == NULL ? "-" :
>   user, tstamp,
>   server_httpmethod_byid(desc->http_method),


Hello again,

I couldn't sleep because for some reason my head was spinning around this 
code.  In sleep I reviewed what I remembered of this code and noticed two
things.

1.  My patch was against 5.8 not -current, so it needed special hand fixing.

2.  The "Range" code required the same attention as my original attention.

I'm gonna need someone to look over my changes closely that I'm gonna put
forward next, because -current httpd doesn't compile on my system due to
some changes in SSL, and I don't want to fully go -current just yet on this
box (my only i386 box).  The following has a change in content_length from
size_t to off_t in function server_partial_file_

Re: httpd patch

[Peter J. Philipp]

On Sat, Jan 16, 2016 at 04:35:16AM +, Peter J. Philipp wrote:
> Hello again,
> 
> I couldn't sleep because for some reason my head was spinning around this 
> code.  In sleep I reviewed what I remembered of this code and noticed two
> things.
> 
> 1.  My patch was against 5.8 not -current, so it needed special hand fixing.
> 
> 2.  The "Range" code required the same attention as my original attention.
> 
> I'm gonna need someone to look over my changes closely that I'm gonna put
> forward next, because -current httpd doesn't compile on my system due to
> some changes in SSL, and I don't want to fully go -current just yet on this
> box (my only i386 box).  The following has a change in content_length from
> size_t to off_t in function server_partial_file_request() because it does 
> this:
> 
> content_length = range->end - range->start + 1;
> 
> and range->end and range->start are both off_t.
> 
> Here then the patches against -current (need review and testing):

Here is my third attempt.  Someone correctly told me that off_t is signed.
This makes it difficult to make it clean as it was before my attempts.  But
take a look at this code and see what I mean.  The below is untested.

I set content_length to 0 because it's better than having a negative value
fly around the code execution path.

-peter


? httpd.patch
Index: httpd.h
===
RCS file: /cvs/src/usr.sbin/httpd/httpd.h,v
retrieving revision 1.102
diff -u -p -u -r1.102 httpd.h
--- httpd.h 2 Dec 2015 15:13:00 -   1.102
+++ httpd.h 16 Jan 2016 04:58:16 -
@@ -597,7 +597,7 @@ const char *
 server_http_host(struct sockaddr_storage *, char *, size_t);
 char   *server_http_parsehost(char *, char *, size_t, int *);
 ssize_t server_http_time(time_t, char *, size_t);
-int server_log_http(struct client *, unsigned int, size_t);
+int server_log_http(struct client *, unsigned int, off_t);
 
 /* server_file.c */
 int server_file(struct httpd *, struct client *);
Index: server_file.c
===
RCS file: /cvs/src/usr.sbin/httpd/server_file.c,v
retrieving revision 1.60
diff -u -p -u -r1.60 server_file.c
--- server_file.c   3 Aug 2015 11:45:17 -   1.60
+++ server_file.c   16 Jan 2016 04:58:16 -
@@ -303,7 +303,7 @@ server_partial_file_request(struct httpd
struct media_type   *media, multipart_media;
struct range*range;
struct evbuffer *evb = NULL;
-   size_t   content_length;
+   off_tcontent_length;
int  code = 500, fd = -1, i, nranges, ret;
uint32_t boundary;
char content_range[64];
@@ -386,6 +386,9 @@ server_partial_file_request(struct httpd
"byteranges; boundary=%ud", boundary);
media = _media;
}
+
+   if (content_length < 0)
+   content_length = 0;
 
ret = server_response_http(clt, 206, media, content_length,
MINIMUM(time(NULL), st->st_mtim.tv_sec));
Index: server_http.c
===
RCS file: /cvs/src/usr.sbin/httpd/server_http.c,v
retrieving revision 1.103
diff -u -p -u -r1.103 server_http.c
--- server_http.c   7 Dec 2015 20:30:17 -   1.103
+++ server_http.c   16 Jan 2016 04:58:17 -
@@ -1443,7 +1443,7 @@ server_httperror_cmp(const void *a, cons
 }
 
 int
-server_log_http(struct client *clt, unsigned int code, size_t len)
+server_log_http(struct client *clt, unsigned int code, off_t len)
 {
static char  tstamp[64];
static char  ip[INET6_ADDRSTRLEN];
@@ -1504,7 +1504,7 @@ server_log_http(struct client *clt, unsi
goto done;
 
ret = evbuffer_add_printf(clt->clt_log,
-   "%s %s - %s [%s] \"%s %s%s%s%s%s\" %03d %zu\n",
+   "%s %s - %s [%s] \"%s %s%s%s%s%s\" %03d %qd\n",
srv_conf->name, ip, clt->clt_remote_user == NULL ? "-" :
user, tstamp,
server_httpmethod_byid(desc->http_method),
@@ -1552,7 +1552,7 @@ server_log_http(struct client *clt, unsi
 
ret = evbuffer_add_printf(clt->clt_log,
"%s %s - %s [%s] \"%s %s%s%s%s%s\""
-   " %03d %zu \"%s\" \"%s\"\n",
+   " %03d %qd \"%s\" \"%s\"\n",
srv_conf->name, ip, clt->clt_remote_user == NULL ? "-" :
user, tstamp,
server_httpmethod_byid(desc->http_method),

Re: pledge idea

[Peter J. Philipp]

On Thu, Oct 29, 2015 at 06:39:58PM +0100, Peter J. Philipp wrote:
> Hi Reyk,
> 
> deraadt already told me there was a patch for this already.  Yes it
> would be more cycles for stdio I see that.
> 
> Thanks for your effort in making me see this.
> 
> -peter
> 
> > $ time obj/sleep 0.01 
> > 0m00.01s real 0m00.00s user 0m00.01s system
> >
> > Are you trying to solve an issue?

Hi,

I just want to revisit this because I couldn't believe it.  I turned on
system accounting and rebooted my test box.  Here is what I found the following
programs were run this many times:

23 sh
10 ntpd
 9 smtpd
 7 domainname
 6 id
 6 getty
 6 getcap
 6 basename

I'm gonna stop here.  Some of these programs were not pledged yet in my sources
(-current from last week).  

So I did the tedious work of adding up the cycles of pledge/strcmp on sh binary
and then gave the bsearch idea a guessed average of 6 rounds per lookup.  What 
I came up with was that pledge/strcmp has 120 cycles where bsearch had 60 
cycles.  Multiplied by 23 times would give pledge/strcmp 2760 cycles and 
bsearch 1380 cycles.  /bin/sh is probably always going to be the most used in
any system, well it is at startup.

Another comparison was for getty:
pledge/strcmp 420 cycles
bsearch = 216 cycles

getcap had stdio and rpath which is 3 cycles, here it wins against bsearch
which has 12 cycles.

I do understand that most little programs such as basename have only stdio
in pledge and thus will save cycles but when you average it all out by 
occurences there might be a case for using bsearch?

I know it was just halloween but I'm still creeped out by this.

-peter

pledge idea

[Peter J. Philipp]

Hi deraadt,

I know you know I don't code well, but in order to show you what's on my 
mind I had to write code, I took the bsearch() from the ieee80211 code, so
perhaps there is a better way (like always) perhaps to unify the function 
between these two areas.

The reason I did this is to save on cpu cycles when you look at X amount
of processes all pledging...one time'd process won't show much difference.

below's diff:

-peter


? pledge.diff
Index: kern/kern_pledge.c
===
RCS file: /cvs/src/sys/kern/kern_pledge.c,v
retrieving revision 1.90
diff -u -p -u -r1.90 kern_pledge.c
--- kern/kern_pledge.c  28 Oct 2015 17:38:52 -  1.90
+++ kern/kern_pledge.c  29 Oct 2015 16:23:04 -
@@ -58,6 +58,32 @@
 
 int canonpath(const char *input, char *buf, size_t bufsize);
 int substrcmp(const char *p1, size_t s1, const char *p2, size_t s2);
+int pledge_cmp(const void *pi, const void *ph);
+
+/* taken from net80211/ieee80211_regdomain.c */
+const void *pledge_bsearch(const void *, const void *, size_t, size_t,
+int (*)(const void *, const void *));
+
+const void *
+pledge_bsearch(const void *key, const void *base0, size_t nmemb, size_t size,
+int (*compar)(const void *, const void *))
+{
+const char *base = base0;
+int lim, cmp;
+const void *p;
+
+for (lim = nmemb; lim != 0; lim >>= 1) {
+p = base + (lim >> 1) * size;
+cmp = (*compar)(key, p);
+if (cmp == 0)
+return ((const void *)p);
+if (cmp > 0) {  /* key > p: move right */
+base = (const char *)p + size;
+lim--;
+} /* else move left */
+}
+return (NULL);
+}
 
 const u_int pledge_syscalls[SYS_MAXSYSCALL] = {
[SYS_exit] = 0x,
@@ -256,40 +282,42 @@ const u_int pledge_syscalls[SYS_MAXSYSCA
[SYS_swapctl] = PLEDGE_VMINFO,  /* XXX should limit to "get" operations 
*/
 };
 
-static const struct {
+/* MUST be sorted! */
+static const struct PR {
char *name;
int flags;
 } pledgereq[] = {
-   { "stdio",  PLEDGE_STDIO },
-   { "rpath",  PLEDGE_RPATH },
-   { "wpath",  PLEDGE_WPATH },
-   { "tmppath",PLEDGE_TMPPATH },
-   { "inet",   PLEDGE_INET },
-   { "unix",   PLEDGE_UNIX },
+   { "abort",  0 },/* XXX reserve for later */
+   { "cpath",  PLEDGE_CPATH },
{ "dns",PLEDGE_DNS },
+   { "exec",   PLEDGE_EXEC },
+   { "fattr",  PLEDGE_FATTR },
+   { "flock",  PLEDGE_FLOCK },
{ "getpw",  PLEDGE_GETPW },
-   { "sendfd", PLEDGE_SENDFD },
-   { "recvfd", PLEDGE_RECVFD },
-   { "ioctl",  PLEDGE_IOCTL },
{ "id", PLEDGE_ID },
-   { "route",  PLEDGE_ROUTE },
+   { "inet",   PLEDGE_INET },
+   { "ioctl",  PLEDGE_IOCTL },
{ "mcast",  PLEDGE_MCAST },
-   { "tty",PLEDGE_TTY },
{ "proc",   PLEDGE_PROC },
-   { "exec",   PLEDGE_EXEC },
-   { "cpath",  PLEDGE_CPATH },
-   { "fattr",  PLEDGE_FATTR },
{ "prot_exec",  PLEDGE_PROTEXEC },
-   { "flock",  PLEDGE_FLOCK },
{ "ps", PLEDGE_PS },
-   { "vminfo", PLEDGE_VMINFO },
+   { "recvfd", PLEDGE_RECVFD },
+   { "route",  PLEDGE_ROUTE },
+   { "rpath",  PLEDGE_RPATH },
+   { "sendfd", PLEDGE_SENDFD },
{ "settime",PLEDGE_SETTIME },
-   { "abort",  0 },/* XXX reserve for later */
+   { "stdio",  PLEDGE_STDIO },
+   { "tmppath",PLEDGE_TMPPATH },
+   { "tty",PLEDGE_TTY },
+   { "unix",   PLEDGE_UNIX },
+   { "vminfo", PLEDGE_VMINFO },
+   { "wpath",  PLEDGE_WPATH },
 };
 
 int
 sys_pledge(struct proc *p, void *v, register_t *retval)
 {
+   struct PR *pr = NULL;
struct sys_pledge_args /* {
syscallarg(const char *)request;
syscallarg(const char **)paths;
@@ -300,7 +328,7 @@ sys_pledge(struct proc *p, void *v, regi
if (SCARG(uap, request)) {
size_t rbuflen;
char *rbuf, *rp, *pn;
-   int f, i;
+   int f;
 
rbuf = malloc(MAXPATHLEN, M_TEMP, M_WAITOK);
error = copyinstr(SCARG(uap, request), rbuf, MAXPATHLEN,
@@ -321,16 +349,15 @@ sys_pledge(struct proc *p, void *v, regi
*pn++ = '\0';
}
 
-   for (f = i = 0; i < 

Re: pledge idea

[Peter J. Philipp]

On 10/29/15 18:51, Reyk Floeter wrote:
> On Thu, Oct 29, 2015 at 04:32:25PM +0000, Peter J. Philipp wrote:
>> Hi deraadt,
>>
>> I know you know I don't code well, but in order to show you what's on my 
>> mind I had to write code, I took the bsearch() from the ieee80211 code, so
>> perhaps there is a better way (like always) perhaps to unify the function 
>> between these two areas.
>>
>> The reason I did this is to save on cpu cycles when you look at X amount
>> of processes all pledging...one time'd process won't show much difference.
>>
> I'm not deraadt, but -
>
> smart but have you considered that this is not worth the effort?
> pledge() is only called once or twice during a process' lifetime -
> start, pledge, run - the linear search on such a short list is still
> relatively fast, and the entries are even sorted in the order of
> relevance.  By convention "stdio" always comes first.  So what is the
> impact without your diff of pledge in src/bin/sleep/sleep.c:
>
> if (pledge("stdio", NULL) == -1)
> err(1, "pledge");

Hi Reyk,

deraadt already told me there was a patch for this already.  Yes it
would be more cycles for stdio I see that.

Thanks for your effort in making me see this.

-peter

> $ time obj/sleep 0.01 
> 0m00.01s real 0m00.00s user 0m00.01s system
>
> Are you trying to solve an issue?
>
> Reyk
>
>> below's diff:
>>
>> -peter
>>
>>
>> ? pledge.diff
>> Index: kern/kern_pledge.c
>> ===
>> RCS file: /cvs/src/sys/kern/kern_pledge.c,v
>> retrieving revision 1.90
>> diff -u -p -u -r1.90 kern_pledge.c
>> --- kern/kern_pledge.c   28 Oct 2015 17:38:52 -  1.90
>> +++ kern/kern_pledge.c   29 Oct 2015 16:23:04 -
>> @@ -58,6 +58,32 @@
>>  
>>  int canonpath(const char *input, char *buf, size_t bufsize);
>>  int substrcmp(const char *p1, size_t s1, const char *p2, size_t s2);
>> +int pledge_cmp(const void *pi, const void *ph);
>> +
>> +/* taken from net80211/ieee80211_regdomain.c */
>> +const void *pledge_bsearch(const void *, const void *, size_t, size_t,
>> +int (*)(const void *, const void *));
>> +
>> +const void *
>> +pledge_bsearch(const void *key, const void *base0, size_t nmemb, size_t 
>> size,
>> +int (*compar)(const void *, const void *))
>> +{
>> +const char *base = base0;
>> +int lim, cmp;
>> +const void *p;
>> +
>> +for (lim = nmemb; lim != 0; lim >>= 1) {
>> +p = base + (lim >> 1) * size;
>> +cmp = (*compar)(key, p);
>> +if (cmp == 0)
>> +return ((const void *)p);
>> +if (cmp > 0) {  /* key > p: move right */
>> +base = (const char *)p + size;
>> +lim--;
>> +} /* else move left */
>> +}
>> +return (NULL);
>> +}
>>  
>>  const u_int pledge_syscalls[SYS_MAXSYSCALL] = {
>>  [SYS_exit] = 0x,
>> @@ -256,40 +282,42 @@ const u_int pledge_syscalls[SYS_MAXSYSCA
>>  [SYS_swapctl] = PLEDGE_VMINFO,  /* XXX should limit to "get" operations 
>> */
>>  };
>>  
>> -static const struct {
>> +/* MUST be sorted! */
>> +static const struct PR {
>>  char *name;
>>  int flags;
>>  } pledgereq[] = {
>> -{ "stdio",  PLEDGE_STDIO },
>> -{ "rpath",  PLEDGE_RPATH },
>> -{ "wpath",  PLEDGE_WPATH },
>> -{ "tmppath",PLEDGE_TMPPATH },
>> -{ "inet",   PLEDGE_INET },
>> -{ "unix",   PLEDGE_UNIX },
>> +{ "abort",  0 },/* XXX reserve for later */
>> +{ "cpath",  PLEDGE_CPATH },
>>  { "dns",PLEDGE_DNS },
>> +{ "exec",   PLEDGE_EXEC },
>> +{ "fattr",  PLEDGE_FATTR },
>> +{ "flock",  PLEDGE_FLOCK },
>>  { "getpw",  PLEDGE_GETPW },
>> -{ "sendfd", PLEDGE_SENDFD },
>> -{ "recvfd", PLEDGE_RECVFD },
>> -{ "ioctl",  PLEDGE_IOCTL },
>>  { "id", PLEDGE_ID },
>> -{ "route",  PLEDGE_ROUTE },
&

an XOR improvement of 1%

[Peter J. Philipp]

Hi,

I have made a patch against 5.7 that improves the speed of xor for amd64
by 1% (timed on a seperate userland program).   I tested the userland
program against an i386 and a amd64 host, didn't have access to any other
architectures.  

If a hardcore developer thinks this is worth it ... feel free to include
something similar to my patch.  The modes this affects is the CTR and the 
XTS AES modes, the latter being tested by me on my amd64 host with a encrypted
sparse file:

sd1 at scsibus3 targ 1 lun 0: OPENBSD, SR CRYPTO, 005 SCSI2 0/direct fixed
sd1: 1023MB, 512 bytes/sector, 2096561 sectors

It worked so the function must be working.  I have attached my patch for 
review inline.  It goes against /sys/crypto/xform.c

-peter

--- xform.c.origMon Jun  8 09:29:27 2015
+++ xform.c Mon Jun  8 09:34:14 2015
@@ -106,6 +106,8 @@
 u_int32_t deflate_decompress(u_int8_t *, u_int32_t, u_int8_t **);
 u_int32_t lzs_dummy(u_int8_t *, u_int32_t, u_int8_t **);
 
+void xorfunc(u_int8_t *, u_int8_t *, int);
+
 #define AESCTR_NONCESIZE   4
 #define AESCTR_IVSIZE  8
 #define AESCTR_BLOCKSIZE   16
@@ -499,8 +501,11 @@
if (++ctx-ac_block[i])   /* continue on overflow */
break;
rijndaelEncrypt(ctx-ac_ek, ctx-ac_nr, ctx-ac_block, keystream);
+#if 0
for (i = 0; i  AESCTR_BLOCKSIZE; i++)
data[i] ^= keystream[i];
+#endif
+   xorfunc(data, keystream, AESCTR_BLOCKSIZE);
explicit_bzero(keystream, sizeof(keystream));
 }
 
@@ -557,8 +562,11 @@
else
rijndael_decrypt(ctx-key1, block, data);
 
+#if 0
for (i = 0; i  AES_XTS_BLOCKSIZE; i++)
data[i] ^= ctx-tweak[i];
+#endif
+   xorfunc(data, ctx-tweak, AES_XTS_BLOCKSIZE);
 
/* Exponentiate tweak */
carry_in = 0;
@@ -676,4 +684,27 @@
 {
*out = NULL;
return (0);
+}
+
+void
+xorfunc(u_int8_t *output, u_int8_t *input, int len)
+{
+int i;
+#if __amd64__
+u_int8_t *i0, *i1, *i2, *i3;
+u_int8_t *o0, *o1, *o2, *o3;
+
+for (i = 0; i  len; i += 4) {
+i0 = (u_int8_t *)input[0 + i]; i1=(u_int8_t *)input[1 + i];
+i2 = (u_int8_t *)input[2 + i]; i3=(u_int8_t *)input[3 + i];
+o0 = (u_int8_t *)output[0 + i]; o1=(u_int8_t *)output[1 + i];
+o2 = (u_int8_t *)output[2 + i]; o3=(u_int8_t *)output[3 + i];
+
+*o0 ^= *i0; *o1 ^= *i1; *o2 ^= *i2; *o3 ^= *i3;
+}
+#else
+for (i = 0; i  len; i++) {
+output[i] ^= input[i];
+}
+#endif
 }

Re: Request for Funding our Electricity

[Peter J. Philipp]

On 01/14/14 21:56, Theo de Raadt wrote:

Hi,

 Anyone want to suggest we hold a bake sale?

I just donated a little bit.  Looking for roughly 10 dozen like minded
people.  I'm not suggesting a bake sale but one thing I noticed with the
freebsdfoundation.org's website, that I think works out good, is that
they have a donation meter on how much was put in the hat.  I think
something like this would benefit OpenBSD too.  Just there would need to
be someone able to make such a meter on a website.  Also showing how
much came from private donations vs. corporate donations would be
interesting to see.

Cheers,

-peter

urtwn(4) patch

[Peter J. Philipp]

Hi,

I previously sent out a patch for this device support here:

   Linkname: 'USB Wireless Micro Adapter IWL 4000 support' - MARC
URL: http://marc.info/?l=openbsd-techm=135342591418924w=2

Now I've looked at the usbdevs file a little closer and finally replaced
my PJPUK device with something a little more proper, here is patch:


Index: if_urtwn.c
===
RCS file: /cvs/src/sys/dev/usb/if_urtwn.c,v
retrieving revision 1.25
diff -u -p -u -r1.25 if_urtwn.c
--- if_urtwn.c  15 Apr 2013 09:23:01 -  1.25
+++ if_urtwn.c  11 May 2013 21:36:59 -
@@ -83,6 +83,7 @@ static const struct usb_devno urtwn_devs
{ USB_VENDOR_AZUREWAVE, USB_PRODUCT_AZUREWAVE_RTL8188CE_2 },
{ USB_VENDOR_AZUREWAVE, USB_PRODUCT_AZUREWAVE_RTL8188CU },
{ USB_VENDOR_BELKIN,USB_PRODUCT_BELKIN_F7D2102 },
+   { USB_VENDOR_BELKIN,USB_PRODUCT_BELKIN_RTL8192CU_4 },
{ USB_VENDOR_BELKIN,USB_PRODUCT_BELKIN_RTL8188CU },
{ USB_VENDOR_BELKIN,USB_PRODUCT_BELKIN_RTL8192CU },
{ USB_VENDOR_CHICONY,   USB_PRODUCT_CHICONY_RTL8188CUS_1 },
Index: usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.598
diff -u -p -u -r1.598 usbdevs
--- usbdevs 7 Mar 2013 23:39:14 -   1.598
+++ usbdevs 11 May 2013 21:39:19 -
@@ -1120,6 +1120,7 @@ product BELKIN RTL8188CU  0x1102  RTL8188C
 product BELKIN F5U120  0x1203  F5U120-PC Hub
 product BELKIN RTL8192CU   0x2102  RTL8192CU
 product BELKIN F7D2102 0x2103  F7D2102
+product BELKIN RTL8192CU_4 0x21f2  RTL8192CU
 product BELKIN ZD1211B 0x4050  ZD1211B
 product BELKIN F5D5055 0x5055  F5D5055
 product BELKIN F5D7050 0x7050  F5D7050 54g USB Network Adapter


The particular device doesn't always attach right, as you can see from this
grep from my kernel dmesg:

urtwn0 at uhub0 port 2 Belkin Components PJPUK rev 2.00/2.00 addr 2
urtwn0: could not set configuration no
urtwn0 detached
urtwn0 at uhub0 port 1 Belkin Components PJPUK rev 2.00/2.00 addr 2
urtwn0: MAC/BB RTL8192CU, RF 6052 2T2R, address ec:1a:59:0d:fa:1c
urtwn0 at uhub0 port 1 Belkin Components PJPUK rev 2.00/2.00 addr 2
urtwn0: could not set configuration no
urtwn0 detached
urtwn0 at uhub0 port 1 Belkin Components PJPUK rev 2.00/2.00 addr 2
urtwn0: could not set configuration no
urtwn0 detached
urtwn0 at uhub0 port 2 Belkin Components PJPUK rev 2.00/2.00 addr 2
urtwn0: could not set configuration no
urtwn0 detached
urtwn0 at uhub0 port 1 Belkin Components PJPUK rev 2.00/2.00 addr 2
urtwn0: MAC/BB RTL8192CU, RF 6052 2T2R, address ec:1a:59:0d:fa:1c
urtwn0 at uhub0 port 2 Belkin Components PJPUK rev 2.00/2.00 addr 2
urtwn0: MAC/BB RTL8192CU, RF 6052 2T2R, address ec:1a:59:0d:fa:1c
urtwn0 at uhub0 port 2 Belkin Components RTL8192CU rev 2.00/2.00 addr 2
urtwn0: MAC/BB RTL8192CU, RF 6052 2T2R, address ec:1a:59:0d:fa:1c
urtwn0 at uhub0 port 2 Belkin Components RTL8192CU rev 2.00/2.00 addr 2
urtwn0: could not set configuration no
urtwn0 detached
urtwn0 at uhub0 port 1 Realtek Belkin Wireless Adapter rev 2.00/2.00 addr 2
urtwn0: MAC/BB RTL8192CU, RF 6052 2T2R, address ec:1a:59:0d:fa:1c

it sometimes (1 in 3 attempts) bails with could not set configuration no
I looked at it a little closer and think it's probably in the usb device 
driver code that it determines this.  

-peter

USB Wireless Micro Adapter IWL 4000 support

[Peter J. Philipp]

First off I'd like to say that today luck was with me.  Big time.  I went to
a local store (saturn.de) to buy a wireless usb adapter and picked one out 
that I thought was supported.  I did not take my netbook with me so I didn't
know if it would work or not.  So when I got home it was detected as ugen0...
damn.  So then I compared the USB Vendor in a list and made an educated guess
that this is a urtwn(4) device and hacked the support into the kernel and
rebooted.  Then I prayed and it did configure and attach!  success then I
did a ifconfig urtwn scan and it worked, success and then I read the manpage
on how to configure wireless as I've never done it on OpenBSD since 2002.

Anyhow the driver specification needs a better name I called it PJPUK for
my initials and unknown.  But I can give you information about the box what
I bought:   This is a ISY (simply connected) USB Wireless Micro Adapter,
IWL 4000 and claimed to be a (N300 standard).  Thank you Damien Bergamini
for this driver!

Here is some relevant information:

ifconfig urtwn0

urtwn0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
lladdr ec:1a:59:0d:fa:1c
priority: 4
groups: wlan egress
media: IEEE802.11 autoselect (OFDM54 mode 11g)
status: active
ieee80211: nwid AREA27 chan 11 bssid 24:65:11:68:a1:43 196dB wpakey 
CENSORED wpaprotos wpa1,wpa2 wpaakms psk wpaciphers tkip,ccmp wpagroupcipher 
tkip
inet6 fe80::ee1a:59ff:fe0d:fa1c%urtwn0 prefixlen 64 scopeid 0x4
inet 192.168.178.36 netmask 0xff00 broadcast 192.168.178.255

usbdevs -v

Controller /dev/usb0:
addr 1: high speed, self powered, config 1, EHCI root hub(0x), ATI(0x1002), 
rev 1.00
 port 1 addr 2: high speed, power 500 mA, config 1, Belkin Wireless 
Adapter(0x21f2), Realtek(0x050d), rev 2.00, iSerialNumber 00e04c01
 port 2 powered
 port 3 powered
 port 4 powered
 port 5 powered
Controller /dev/usb1:
...


The diff against a -current snapshot from last week:

Index: if_urtwn.c
===
RCS file: /cvs/src/sys/dev/usb/if_urtwn.c,v
retrieving revision 1.23
diff -u -r1.23 if_urtwn.c
--- if_urtwn.c  17 Sep 2012 15:14:14 -  1.23
+++ if_urtwn.c  20 Nov 2012 15:11:56 -
@@ -83,6 +83,7 @@
{ USB_VENDOR_AZUREWAVE, USB_PRODUCT_AZUREWAVE_RTL8188CE_2 },
{ USB_VENDOR_AZUREWAVE, USB_PRODUCT_AZUREWAVE_RTL8188CU },
{ USB_VENDOR_BELKIN,USB_PRODUCT_BELKIN_F7D2102 },
+   { USB_VENDOR_BELKIN,USB_PRODUCT_BELKIN_PJPUK },
{ USB_VENDOR_BELKIN,USB_PRODUCT_BELKIN_RTL8188CU },
{ USB_VENDOR_BELKIN,USB_PRODUCT_BELKIN_RTL8192CU },
{ USB_VENDOR_CHICONY,   USB_PRODUCT_CHICONY_RTL8188CUS_1 },
Index: usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.591
diff -u -r1.591 usbdevs
--- usbdevs 14 Nov 2012 16:53:49 -  1.591
+++ usbdevs 20 Nov 2012 15:11:59 -
@@ -1118,6 +1118,7 @@
 product BELKIN F5U120  0x1203  F5U120-PC Hub
 product BELKIN RTL8192CU   0x2102  RTL8192CU
 product BELKIN F7D2102 0x2103  F7D2102
+product BELKIN PJPUK   0x21f2  PJPUK
 product BELKIN ZD1211B 0x4050  ZD1211B
 product BELKIN F5D5055 0x5055  F5D5055
 product BELKIN F5D7050 0x7050  F5D7050 54g USB Network Adapter


and last but not least a dmesg:

OpenBSD 5.2-current (SATURN) #1: Tue Nov 20 15:57:38 CET 2012
p...@saturn.centroid.eu:/usr/src/sys/arch/amd64/compile/SATURN
RTC BIOS diagnostic error 80clock_battery
real mem = 4003721216 (3818MB)
avail mem = 3874660352 (3695MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe3e70 (51 entries)
bios0: vendor Acer version V1.08 date 12/06/2011
bios0: Acer AO722
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC MCFG BOOT SLIC SSDT SSDT
acpi0: wakeup devices SPB2(S4) GEC_(S4) USB0(S3) USB4(S3) P2P_(S5)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD C-60 APU with Radeon(tm) HD Graphics, 998.31 MHz
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,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
16-way L2 cache
cpu0: 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: apic clock running at 199MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD C-60 APU with Radeon(tm) HD Graphics, 997.51 MHz
cpu1: 

Re: USB Wireless Micro Adapter IWL 4000 support

[Peter J. Philipp]

On Tue, Nov 20, 2012 at 04:33:27PM +0100, Peter J. Philipp wrote:
 urtwn0 at uhub0 port 1 Realtek Belkin Wireless Adapter rev 2.00/2.00 addr 2
 urtwn0: MAC/BB RTL8192CU, RF 6052 2T2R, address ec:1a:59:0d:fa:1c

Hrmm, sometimes it does not detect right.  I had to cold boot my netbook
last for it to detect, the dmesg has also changed:

urtwn0 at uhub0 port 1 Belkin Components PJPUK rev 2.00/2.00 addr 2
urtwn0: MAC/BB RTL8192CU, RF 6052 2T2R, address ec:1a:59:0d:fa:1c

For the fact that it works is amazing to me.  However not perfectly, and 
that skillset is beyond me, but I thought I'd let you know.

-peter

tftpd patch

[Peter J. Philipp]

Hi,

I have the weird scenario when I try to tftp a file from a remote tftpd that's
also openbsd that my pf doesn't keep a state open.  This is something I need
to fix, however I found this in the logs on the remote tftpd and it's 
misleading:

Jun 28 14:03:21 hostname tftpd[2506]: recv: Connection refused

It first boggled my mind what it's trying to recv and then it came to me...
the write error message is delayed because of the ICMP port unreachable 
travel time at which point the descriptor is already blocking in read I guess.
So I have changed it to this:

Jun 28 14:03:21 hostname tftpd[2506]: sendfile: Connection refused

which to me is a lot more explanatory on what it fails on.  sendfile is
the function not the syscall.  I'd rather see send in there than recv.

Here is the patch:


Index: tftpd.c
===
RCS file: /cvs/src/libexec/tftpd/tftpd.c,v
retrieving revision 1.63
diff -u -r1.63 tftpd.c
--- tftpd.c 27 Oct 2009 23:59:32 -  1.63
+++ tftpd.c 28 Jun 2012 18:00:29 -
@@ -669,7 +669,10 @@
error = 1;
if (errno == EINTR)
continue;
-   syslog(LOG_ERR, recv: %m);
+   if (errno == ECONNREFUSED) 
+   syslog(LOG_ERR, sendfile: %m);
+   else
+   syslog(LOG_ERR, recv: %m);
goto abort;
}
ap-th_opcode = ntohs((u_short)ap-th_opcode);



If you think kittens will die because of this patch then don't commit it
but otherwise I'm just trying to make sense of this better.

Cheers,

-peter

Re: ip6(4) manpage update

[Peter J. Philipp]

On Mon, Jun 18, 2012 at 08:06:06AM +0100, Jason McIntyre wrote:
 the blank line above should be a .Pp.
 
 also this diff adds trailing whitespace at eol in a few places. please
 remove it.
 
 except for that, i'm fine with this diff, if some developer wants to
 take it.
 
 jmc

Awesome!  Well here is my attempt three then.


Index: ip6.4
===
RCS file: /cvs/src/share/man/man4/ip6.4,v
retrieving revision 1.25
diff -u -r1.25 ip6.4
--- ip6.4   8 Sep 2011 16:43:56 -   1.25
+++ ip6.4   18 Jun 2012 08:06:35 -
@@ -237,7 +237,7 @@
 .It Dv IPV6_PORTRANGE_LOW
 Use a low, reserved range (600\-1023).
 .El
-.It Dv IPV6_PKTINFO Fa int *
+.It Dv IPV6_RECVPKTINFO Fa int *
 Get or set whether additional information about subsequent packets will
 be provided as ancillary data along with the payload in subsequent
 .Xr recvmsg 2
@@ -250,7 +250,10 @@
unsigned intipi6_ifindex; /* send/recv if index */
 };
 .Ed
-.It Dv IPV6_HOPLIMIT Fa int *
+.Pp
+Turning this option on will result in this socket getting cmsg data of
+type IPV6_PKTINFO.
+.It Dv IPV6_RECVHOPLIMIT Fa int *
 Get or set whether the hop limit header field from subsequent packets
 will be provided as ancillary data along with the payload in subsequent
 .Xr recvmsg 2
@@ -258,6 +261,8 @@
 The value is stored as an
 .Vt int
 in the ancillary data returned.
+Turning this option on will result in this socket getting cmsg data of
+type IPV6_HOPLIMIT.
 .\ .It Dv IPV6_NEXTHOP Fa int *
 .\ Get or set whether the address of the next hop for subsequent
 .\ packets will be provided as ancillary data along with the payload in
@@ -269,7 +274,7 @@
 .\ structure in the ancillary data returned.
 .\ .Pp
 .\ This option requires superuser privileges.
-.It Dv IPV6_HOPOPTS Fa int *
+.It Dv IPV6_RECVHOPOPTS Fa int *
 Get or set whether the hop-by-hop options from subsequent packets will be
 provided as ancillary data along with the payload in subsequent
 .Xr recvmsg 2
@@ -289,7 +294,9 @@
 routine and family of routines may be used to manipulate this data.
 .Pp
 This option requires superuser privileges.
-.It Dv IPV6_DSTOPTS Fa int *
+Turning this option on will result in this socket getting cmsg data of
+type IPV6_HOPOPTS.
+.It Dv IPV6_RECVDSTOPTS Fa int *
 Get or set whether the destination options from subsequent packets will
 be provided as ancillary data along with the payload in subsequent
 .Xr recvmsg 2
@@ -309,6 +316,8 @@
 routine and family of routines may be used to manipulate this data.
 .Pp
 This option requires superuser privileges.
+Turning this option on will result in this socket getting cmsg data of
+type IPV6_DSTOPTS.
 .It Dv IPV6_TCLASS Fa int *
 Get or set the value of the traffic class field used for outgoing datagrams
 on this socket.
@@ -321,7 +330,7 @@
 calls.
 The header field is stored as a single value of type
 .Vt int .
-.It Dv IPV6_RTHDR Fa int *
+.It Dv IPV6_RECVRTHDR Fa int *
 Get or set whether the routing header from subsequent packets will be
 provided as ancillary data along with the payload in subsequent
 .Xr recvmsg 2
@@ -343,6 +352,8 @@
 routine and family of routines may be used to manipulate this data.
 .Pp
 This option requires superuser privileges.
+Turning this option on will result in this socket getting cmsg data of
+type IPV6_RTHDR.
 .It Dv IPV6_PKTOPTIONS Fa struct cmsghdr *
 Get or set all header options and extension headers at one time on the
 last packet sent or received on the socket.
@@ -413,11 +424,11 @@
 .El
 .Pp
 The
-.Dv IPV6_PKTINFO ,
-.\ .Dv IPV6_NEXTHOP ,
-.Dv IPV6_HOPLIMIT ,
-.Dv IPV6_HOPOPTS ,
-.Dv IPV6_DSTOPTS ,
+.Dv IPV6_RECVPKTINFO ,
+.\ .Dv IPV6_RECVNEXTHOP ,
+.Dv IPV6_RECVHOPLIMIT ,
+.Dv IPV6_RECVHOPOPTS ,
+.Dv IPV6_RECVDSTOPTS ,
 and
 .Dv IPV6_RTHDR
 options will return ancillary data along with payload contents in subsequent
@@ -429,7 +440,7 @@
 and
 .Va cmsg_type
 set to respective option name value (e.g.,
-.Dv IPV6_HOPTLIMIT ) .
+.Dv IPV6_HOPLIMIT ) .
 These options may also be used directly as ancillary
 .Va cmsg_type
 values in
@@ -455,7 +466,7 @@
 can be set by the
 .Dv IPV6_MULTICAST_IF
 socket option, through the
-.Dv IPV6_PKTINFO
+.Dv IPV6_RECVPKTINFO
 option, and through the
 .Va sin6_scope_id
 field of the socket address passed to the
@@ -590,7 +601,7 @@
  * returned along with the payload.
  */
 optval = 1;
-if (setsockopt(s, IPPROTO_IPV6, IPV6_HOPLIMIT, optval,
+if (setsockopt(s, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, optval,
 sizeof(optval)) == -1)
err(1, setsockopt);
 
@@ -685,6 +696,15 @@
 .%A B. Fenner
 .%A A. Rudoff
 .%T UNIX Network Programming, third edition
+.Re
+.Rs
+.%A W. Stevens
+.%A M. Thomas
+.%A E. Nordmark
+.%A T. Jinmei
+.%T Advanced Sockets Application Program Interface (API) for IPv6
+.%R RFC 3542
+.%D May 2003
 .Re
 .Sh STANDARDS
 Most of the socket options are defined in RFC 2292 or RFC 2553.

Re: ip6(4) manpage update

[Peter J. Philipp]

On Sat, Jun 16, 2012 at 07:17:16PM -0700, Philip Guenther wrote:
  You can expect the same issue with IPV6_PKTINFO, IPV6_HOPOPTS, IPV6_DSTOPTS,
  and IPV6_RTHDR. The RECV part was added to them in RFC3542.
 
 Yep.  In addition, the text should be clarified to indicate that
 turning on IPV6_RECV* will result in the process getting cmsg data of
 type IPV6_*.  E.g., IPV6_RECVHOPLIMIT turns on receiving of
 IPV6_HOPLIMIT cmsg data.
 
 Peter, do you want to take a stab at that part too?
 
 
 (There's also a typo in the current page: s/HOPTLIMIT/HOPLIMIT/)
 
 
 Philip Guenther

Sure I'll take a stab at it but its very difficult I found (I was also 
distracted by freeing a bird from the attic).  Here goes:

-peter

Index: ip6.4
===
RCS file: /cvs/src/share/man/man4/ip6.4,v
retrieving revision 1.25
diff -u -r1.25 ip6.4
--- ip6.4   8 Sep 2011 16:43:56 -   1.25
+++ ip6.4   17 Jun 2012 10:45:19 -
@@ -237,7 +237,7 @@
 .It Dv IPV6_PORTRANGE_LOW
 Use a low, reserved range (600\-1023).
 .El
-.It Dv IPV6_PKTINFO Fa int *
+.It Dv IPV6_RECVPKTINFO Fa int *
 Get or set whether additional information about subsequent packets will
 be provided as ancillary data along with the payload in subsequent
 .Xr recvmsg 2
@@ -250,14 +250,19 @@
unsigned intipi6_ifindex; /* send/recv if index */
 };
 .Ed
-.It Dv IPV6_HOPLIMIT Fa int *
+
+Turning this option on will result in this process getting cmsg data of
+type IPV6_PKTINFO.
+.It Dv IPV6_RECVHOPLIMIT Fa int *
 Get or set whether the hop limit header field from subsequent packets
 will be provided as ancillary data along with the payload in subsequent
 .Xr recvmsg 2
-calls.
+calls. 
 The value is stored as an
 .Vt int
 in the ancillary data returned.
+Turning this option on will result in this process getting cmsg data of
+type IPV6_HOPLIMIT.
 .\ .It Dv IPV6_NEXTHOP Fa int *
 .\ Get or set whether the address of the next hop for subsequent
 .\ packets will be provided as ancillary data along with the payload in
@@ -269,7 +274,7 @@
 .\ structure in the ancillary data returned.
 .\ .Pp
 .\ This option requires superuser privileges.
-.It Dv IPV6_HOPOPTS Fa int *
+.It Dv IPV6_RECVHOPOPTS Fa int *
 Get or set whether the hop-by-hop options from subsequent packets will be
 provided as ancillary data along with the payload in subsequent
 .Xr recvmsg 2
@@ -288,8 +293,10 @@
 .Fn inet6_option_space
 routine and family of routines may be used to manipulate this data.
 .Pp
-This option requires superuser privileges.
-.It Dv IPV6_DSTOPTS Fa int *
+This option requires superuser privileges.  
+Turning this option on will result in this process getting cmsg data of
+type IPV6_HOPOPTS.
+.It Dv IPV6_RECVDSTOPTS Fa int *
 Get or set whether the destination options from subsequent packets will
 be provided as ancillary data along with the payload in subsequent
 .Xr recvmsg 2
@@ -309,6 +316,8 @@
 routine and family of routines may be used to manipulate this data.
 .Pp
 This option requires superuser privileges.
+Turning this option on will result in this process getting cmsg data of
+type IPV6_DSTOPTS.
 .It Dv IPV6_TCLASS Fa int *
 Get or set the value of the traffic class field used for outgoing datagrams
 on this socket.
@@ -321,7 +330,7 @@
 calls.
 The header field is stored as a single value of type
 .Vt int .
-.It Dv IPV6_RTHDR Fa int *
+.It Dv IPV6_RECVRTHDR Fa int *
 Get or set whether the routing header from subsequent packets will be
 provided as ancillary data along with the payload in subsequent
 .Xr recvmsg 2
@@ -343,6 +352,8 @@
 routine and family of routines may be used to manipulate this data.
 .Pp
 This option requires superuser privileges.
+Turning this option on will result in this process getting cmsg data of
+type IPV6_RTHDR.
 .It Dv IPV6_PKTOPTIONS Fa struct cmsghdr *
 Get or set all header options and extension headers at one time on the
 last packet sent or received on the socket.
@@ -413,11 +424,11 @@
 .El
 .Pp
 The
-.Dv IPV6_PKTINFO ,
-.\ .Dv IPV6_NEXTHOP ,
-.Dv IPV6_HOPLIMIT ,
-.Dv IPV6_HOPOPTS ,
-.Dv IPV6_DSTOPTS ,
+.Dv IPV6_RECVPKTINFO ,
+.\ .Dv IPV6_RECVNEXTHOP ,
+.Dv IPV6_RECVHOPLIMIT ,
+.Dv IPV6_RECVHOPOPTS ,
+.Dv IPV6_RECVDSTOPTS ,
 and
 .Dv IPV6_RTHDR
 options will return ancillary data along with payload contents in subsequent
@@ -429,7 +440,7 @@
 and
 .Va cmsg_type
 set to respective option name value (e.g.,
-.Dv IPV6_HOPTLIMIT ) .
+.Dv IPV6_HOPLIMIT ) .
 These options may also be used directly as ancillary
 .Va cmsg_type
 values in
@@ -455,7 +466,7 @@
 can be set by the
 .Dv IPV6_MULTICAST_IF
 socket option, through the
-.Dv IPV6_PKTINFO
+.Dv IPV6_RECVPKTINFO
 option, and through the
 .Va sin6_scope_id
 field of the socket address passed to the
@@ -590,7 +601,7 @@
  * returned along with the payload.
  */
 optval = 1;
-if (setsockopt(s, IPPROTO_IPV6, IPV6_HOPLIMIT, optval,
+if (setsockopt(s, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, optval,
 sizeof(optval)) == -1)
err(1, 

Re: ip6(4) manpage update

[Peter J. Philipp]

On Sun, Jun 17, 2012 at 12:49:08PM +0200, Peter J. Philipp wrote:
 On Sat, Jun 16, 2012 at 07:17:16PM -0700, Philip Guenther wrote:
   You can expect the same issue with IPV6_PKTINFO, IPV6_HOPOPTS, 
   IPV6_DSTOPTS,
   and IPV6_RTHDR. The RECV part was added to them in RFC3542.
  
  Yep.  In addition, the text should be clarified to indicate that
  turning on IPV6_RECV* will result in the process getting cmsg data of
  type IPV6_*.  E.g., IPV6_RECVHOPLIMIT turns on receiving of
  IPV6_HOPLIMIT cmsg data.
  
  Peter, do you want to take a stab at that part too?
  
  
  (There's also a typo in the current page: s/HOPTLIMIT/HOPLIMIT/)
  
  
  Philip Guenther
 
 Sure I'll take a stab at it but its very difficult I found (I was also 
 distracted by freeing a bird from the attic).  Here goes:

attempt two.. process was the wrong word, I substituted it with socket.

-peter

Index: ip6.4
===
RCS file: /cvs/src/share/man/man4/ip6.4,v
retrieving revision 1.25
diff -u -r1.25 ip6.4
--- ip6.4   8 Sep 2011 16:43:56 -   1.25
+++ ip6.4   17 Jun 2012 10:45:19 -
@@ -237,7 +237,7 @@
 .It Dv IPV6_PORTRANGE_LOW
 Use a low, reserved range (600\-1023).
 .El
-.It Dv IPV6_PKTINFO Fa int *
+.It Dv IPV6_RECVPKTINFO Fa int *
 Get or set whether additional information about subsequent packets will
 be provided as ancillary data along with the payload in subsequent
 .Xr recvmsg 2
@@ -250,14 +250,19 @@
unsigned intipi6_ifindex; /* send/recv if index */
 };
 .Ed
-.It Dv IPV6_HOPLIMIT Fa int *
+
+Turning this option on will result in this socket getting cmsg data of
+type IPV6_PKTINFO.
+.It Dv IPV6_RECVHOPLIMIT Fa int *
 Get or set whether the hop limit header field from subsequent packets
 will be provided as ancillary data along with the payload in subsequent
 .Xr recvmsg 2
-calls.
+calls. 
 The value is stored as an
 .Vt int
 in the ancillary data returned.
+Turning this option on will result in this socket getting cmsg data of
+type IPV6_HOPLIMIT.
 .\ .It Dv IPV6_NEXTHOP Fa int *
 .\ Get or set whether the address of the next hop for subsequent
 .\ packets will be provided as ancillary data along with the payload in
@@ -269,7 +274,7 @@
 .\ structure in the ancillary data returned.
 .\ .Pp
 .\ This option requires superuser privileges.
-.It Dv IPV6_HOPOPTS Fa int *
+.It Dv IPV6_RECVHOPOPTS Fa int *
 Get or set whether the hop-by-hop options from subsequent packets will be
 provided as ancillary data along with the payload in subsequent
 .Xr recvmsg 2
@@ -288,8 +293,10 @@
 .Fn inet6_option_space
 routine and family of routines may be used to manipulate this data.
 .Pp
-This option requires superuser privileges.
-.It Dv IPV6_DSTOPTS Fa int *
+This option requires superuser privileges.  
+Turning this option on will result in this socket getting cmsg data of
+type IPV6_HOPOPTS.
+.It Dv IPV6_RECVDSTOPTS Fa int *
 Get or set whether the destination options from subsequent packets will
 be provided as ancillary data along with the payload in subsequent
 .Xr recvmsg 2
@@ -309,6 +316,8 @@
 routine and family of routines may be used to manipulate this data.
 .Pp
 This option requires superuser privileges.
+Turning this option on will result in this socket getting cmsg data of
+type IPV6_DSTOPTS.
 .It Dv IPV6_TCLASS Fa int *
 Get or set the value of the traffic class field used for outgoing datagrams
 on this socket.
@@ -321,7 +330,7 @@
 calls.
 The header field is stored as a single value of type
 .Vt int .
-.It Dv IPV6_RTHDR Fa int *
+.It Dv IPV6_RECVRTHDR Fa int *
 Get or set whether the routing header from subsequent packets will be
 provided as ancillary data along with the payload in subsequent
 .Xr recvmsg 2
@@ -343,6 +352,8 @@
 routine and family of routines may be used to manipulate this data.
 .Pp
 This option requires superuser privileges.
+Turning this option on will result in this socket getting cmsg data of
+type IPV6_RTHDR.
 .It Dv IPV6_PKTOPTIONS Fa struct cmsghdr *
 Get or set all header options and extension headers at one time on the
 last packet sent or received on the socket.
@@ -413,11 +424,11 @@
 .El
 .Pp
 The
-.Dv IPV6_PKTINFO ,
-.\ .Dv IPV6_NEXTHOP ,
-.Dv IPV6_HOPLIMIT ,
-.Dv IPV6_HOPOPTS ,
-.Dv IPV6_DSTOPTS ,
+.Dv IPV6_RECVPKTINFO ,
+.\ .Dv IPV6_RECVNEXTHOP ,
+.Dv IPV6_RECVHOPLIMIT ,
+.Dv IPV6_RECVHOPOPTS ,
+.Dv IPV6_RECVDSTOPTS ,
 and
 .Dv IPV6_RTHDR
 options will return ancillary data along with payload contents in subsequent
@@ -429,7 +440,7 @@
 and
 .Va cmsg_type
 set to respective option name value (e.g.,
-.Dv IPV6_HOPTLIMIT ) .
+.Dv IPV6_HOPLIMIT ) .
 These options may also be used directly as ancillary
 .Va cmsg_type
 values in
@@ -455,7 +466,7 @@
 can be set by the
 .Dv IPV6_MULTICAST_IF
 socket option, through the
-.Dv IPV6_PKTINFO
+.Dv IPV6_RECVPKTINFO
 option, and through the
 .Va sin6_scope_id
 field of the socket address passed to the
@@ -590,7 +601,7 @@
  * returned along with the payload.
  */
 optval = 1

ip6(4) manpage update

[Peter J. Philipp]

Hi,

I just got through a thread in misc@,

http://marc.info/?l=openbsd-miscm=133934252713974w=2

and it seems like the sample code in ip6(4) is wrong.  I've made adjustments
but it doesn't look as nice anymore, perhaps someone can look over it?  These
changes will really help someone first time trying the sample code, I think.
Credit should be given to Simon Perreault, I just did what he suggested.

-peter

patch below (against 5.1):


Index: ip6.4
===
RCS file: /cvs/src/share/man/man4/ip6.4,v
retrieving revision 1.25
diff -u -r1.25 ip6.4
--- ip6.4   8 Sep 2011 16:43:56 -   1.25
+++ ip6.4   11 Jun 2012 19:26:44 -
@@ -251,6 +251,7 @@
 };
 .Ed
 .It Dv IPV6_HOPLIMIT Fa int *
+.It Dv IPV6_RECVHOPLIMIT Fa int *
 Get or set whether the hop limit header field from subsequent packets
 will be provided as ancillary data along with the payload in subsequent
 .Xr recvmsg 2
@@ -590,7 +591,7 @@
  * returned along with the payload.
  */
 optval = 1;
-if (setsockopt(s, IPPROTO_IPV6, IPV6_HOPLIMIT, optval,
+if (setsockopt(s, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, optval,
 sizeof(optval)) == -1)
err(1, setsockopt);
 
@@ -685,6 +686,15 @@
 .%A B. Fenner
 .%A A. Rudoff
 .%T UNIX Network Programming, third edition
+.Re
+.Rs
+.%A W. Stevens
+.%A M. Thomas
+.%A E. Nordmark
+.%A T. Jinmei
+.%T Advanced Sockets Application Program Interface (API) for IPv6
+.%R RFC 3542
+.%D May 2003
 .Re
 .Sh STANDARDS
 Most of the socket options are defined in RFC 2292 or RFC 2553.

path correction

[Peter J. Philipp]

This probably saw some debate in the past, which I did not see.  On my IRC
channel it is concensus that the path given out is dangerous.

-peter

Index: dot.profile
===
RCS file: /cvs/src/etc/skel/dot.profile,v
retrieving revision 1.4
diff -u -r1.4 dot.profile
--- dot.profile 16 Feb 2005 06:56:57 -  1.4
+++ dot.profile 13 Apr 2012 15:05:11 -
@@ -2,5 +2,5 @@
 #
 # sh/ksh initialization
 
-PATH=$HOME/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games:.
+PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games:$HOME/bin:.
 export PATH HOME TERM

Re: path correction

[Peter J. Philipp]

On Fri, Apr 13, 2012 at 05:08:32PM +0200, Peter J. Philipp wrote:
 This probably saw some debate in the past, which I did not see.  On my IRC
 channel it is concensus that the path given out is dangerous.

I'd like to retract this patch.  I lied.  Yes I told a lie.  Danger talking or
discussing about this patch will make friends foes.  Just leave it as it is, 
it's been so for 11 years anyhow.  

-peter

smtpd.conf.5 match reality

[Peter J. Philipp]

Thanks to kdump I was able to figure this one out before reading the source.

-peter

? smtpd.conf.5.patch
Index: smtpd.conf.5
===
RCS file: /cvs/src/usr.sbin/smtpd/smtpd.conf.5,v
retrieving revision 1.45
diff -u -r1.45 smtpd.conf.5
--- smtpd.conf.53 Oct 2011 17:57:43 -   1.45
+++ smtpd.conf.522 Nov 2011 17:57:56 -
@@ -417,7 +417,7 @@
 The configuration file would look like this:
 .Bd -literal -offset indent
 listen on lo0
-listen on bnx0 tls certificate mail.example.com.crt enable auth
+listen on bnx0 tls certificate mail.example.com enable auth
 map aliases { source db /etc/mail/aliases.db }
 accept for local deliver to mda /path/to/mda -f -
 accept from all for domain example.org deliver to mda /path/to/mda -f -

Anyone interested in writing a driver for this?

[Peter J. Philipp]

Hi,

I have a USB device called a USB FM transmitter from Keene Electronics.
It looks like this when I plug it in.

uaudio0 at uhub1 port 1 configuration 1 interface 0 HOLTEK B-LINK USB Audio 
rev 1.10/1.00 addr 3
uaudio0: audio rev 1.00, 2 mixer controls
audio1 at uaudio0
uhidev0 at uhub1 port 1 configuration 1 interface 2 HOLTEK B-LINK USB Audio 
rev 1.10/1.00 addr 3
uhidev0: no report descriptor

Basically there is two USB hids to this device, one is a standard audio device
that acts like a sound card and transmits on FM.  The second part controls it,
sets its frequency and other things such as US/Europe FM stepping, TX gain
etc.  The driver for the audio exists as you can see.  The second part is
partially done by kenchy who did an incredible amount of reverse engineering
of this device and wrote a libUSB program to set frequency and turns it on.

https://github.com/kenchy/keene-usb-audio

But the device has a few more knobs that I would love to see in a driver,
such as TX gain and US/Europe settings, basically everything that the Windows
XP driver does.

Is anyone who is knowledged in writing a USB driver interested in writing 
a driver for this?  I'd send you this device free of charge as it's 
collecting dust over here.  There was a USB extension cable in the package
which I have misplaced other than that there is a mini CDROM and the 
device itself.

Kenchy has no license on his libusb program so its info can easily be used
to make a BSD licensed driver out of this.

Let me know in private email if you're interested.

-peter