Re: distrib: arm64: remove gratitious customization from mr.fs
I like that.
Sebastien Marie wrote:
> Hi,
>
> arm64 ramdisk has customization in mr.fs target, in order to create
> usr/mdec/pine64 and usr/mdec/rpi directories (files will be copied
> inside them by runlist.sh).
>
> I will argue that mr.fs target isn't the place for such per-arch
> customization as runlist.sh supports MKDIR directive from the list
> file.
>
> The diff belows put back mr.fs target identical to others archs and
> make the directories to be created with directives from list file.
>
> Please note that armv7 already uses such MKDIR directives for the same
> purpose (usr/mdec/xxx directory creation).
>
> Comments or OK ?
> --
> Sebastien Marie
>
> diff 1c9ddf109f6795c0adfcf5b19fd0bc61b3839042 /home/semarie/repos/openbsd/src
> blob - 04b89cbda8d32468e5e91d2785b43d8e6094d90b
> file + distrib/arm64/ramdisk/Makefile
> --- distrib/arm64/ramdisk/Makefile
> +++ distrib/arm64/ramdisk/Makefile
> @@ -24,10 +24,6 @@ UTILS= ${.CURDIR}/../../miniroot
> MRFSDISKTYPE=rdroot
> MRMAKEFSARGS=-o disklabel=${MRFSDISKTYPE},minfree=0,density=4096
>
> -DIRS=\
> - pine64 \
> - rpi
> -
> PIFILES=\
> bootcode.bin \
> start.elf \
> @@ -85,9 +81,6 @@ bsd:
> mr.fs: instbin
> rm -rf $@.d
> install -d -o root -g wheel $@.d
> -.for DIR in ${DIRS}
> - mkdir -p $@.d/usr/mdec/${DIR}
> -.endfor
> mtree -def ${MTREE} -p $@.d -u
> CURDIR=${.CURDIR} OBJDIR=${.OBJDIR} OSrev=${OSrev} \
> TARGDIR=$@.d UTILS=${UTILS} RELEASEDIR=${RELEASEDIR} \
> blob - 6e7a37085a9024988fd24d7d63a5689ea78aed4c
> file + distrib/arm64/ramdisk/list
> --- distrib/arm64/ramdisk/list
> +++ distrib/arm64/ramdisk/list
> @@ -91,6 +91,7 @@ COPY${DESTDIR}/etc/firmware/atu-rfmd2958-int
> etc/firm
> COPY ${DESTDIR}/etc/firmware/atu-rfmd2958smc-ext
> etc/firmware/atu-rfmd2958smc-ext
> COPY ${DESTDIR}/etc/firmware/atu-rfmd2958smc-int
> etc/firmware/atu-rfmd2958smc-int
>
> +MKDIRusr/mdec/rpi
> COPY /usr/local/share/raspberrypi-firmware/boot/bcm2710-rpi-3-b.dtb
> usr/mdec/rpi/bcm2710-rpi-3-b.dtb
> COPY /usr/local/share/raspberrypi-firmware/boot/bcm2710-rpi-3-b-plus.dtb
> usr/mdec/rpi/bcm2710-rpi-3-b-plus.dtb
> COPY /usr/local/share/raspberrypi-firmware/boot/bcm2710-rpi-cm3.dtb
> usr/mdec/rpi/bcm2710-rpi-cm3.dtb
> @@ -100,6 +101,7 @@ COPY
> /usr/local/share/raspberrypi-firmware/boot/fixup.
> COPY /usr/local/share/raspberrypi-firmware/boot/overlays/disable-bt.dtbo
> usr/mdec/rpi/disable-bt.dtbo
> COPY /usr/local/share/u-boot/rpi_3/u-boot.bin usr/mdec/rpi/u-boot.bin
>
> +MKDIRusr/mdec/pine64
> COPY /usr/local/share/u-boot/pine64_plus/u-boot-sunxi-with-spl.bin
> usr/mdec/pine64/u-boot-sunxi-with-spl.bin
>
> # copy the MAKEDEV script and make some devices
>
distrib: arm64: remove gratitious customization from mr.fs
Hi,
arm64 ramdisk has customization in mr.fs target, in order to create
usr/mdec/pine64 and usr/mdec/rpi directories (files will be copied
inside them by runlist.sh).
I will argue that mr.fs target isn't the place for such per-arch
customization as runlist.sh supports MKDIR directive from the list
file.
The diff belows put back mr.fs target identical to others archs and
make the directories to be created with directives from list file.
Please note that armv7 already uses such MKDIR directives for the same
purpose (usr/mdec/xxx directory creation).
Comments or OK ?
--
Sebastien Marie
diff 1c9ddf109f6795c0adfcf5b19fd0bc61b3839042 /home/semarie/repos/openbsd/src
blob - 04b89cbda8d32468e5e91d2785b43d8e6094d90b
file + distrib/arm64/ramdisk/Makefile
--- distrib/arm64/ramdisk/Makefile
+++ distrib/arm64/ramdisk/Makefile
@@ -24,10 +24,6 @@ UTILS= ${.CURDIR}/../../miniroot
MRFSDISKTYPE= rdroot
MRMAKEFSARGS= -o disklabel=${MRFSDISKTYPE},minfree=0,density=4096
-DIRS=\
- pine64 \
- rpi
-
PIFILES=\
bootcode.bin \
start.elf \
@@ -85,9 +81,6 @@ bsd:
mr.fs: instbin
rm -rf $@.d
install -d -o root -g wheel $@.d
-.for DIR in ${DIRS}
- mkdir -p $@.d/usr/mdec/${DIR}
-.endfor
mtree -def ${MTREE} -p $@.d -u
CURDIR=${.CURDIR} OBJDIR=${.OBJDIR} OSrev=${OSrev} \
TARGDIR=$@.d UTILS=${UTILS} RELEASEDIR=${RELEASEDIR} \
blob - 6e7a37085a9024988fd24d7d63a5689ea78aed4c
file + distrib/arm64/ramdisk/list
--- distrib/arm64/ramdisk/list
+++ distrib/arm64/ramdisk/list
@@ -91,6 +91,7 @@ COPY ${DESTDIR}/etc/firmware/atu-rfmd2958-int etc/firm
COPY ${DESTDIR}/etc/firmware/atu-rfmd2958smc-ext
etc/firmware/atu-rfmd2958smc-ext
COPY ${DESTDIR}/etc/firmware/atu-rfmd2958smc-int
etc/firmware/atu-rfmd2958smc-int
+MKDIR usr/mdec/rpi
COPY /usr/local/share/raspberrypi-firmware/boot/bcm2710-rpi-3-b.dtb
usr/mdec/rpi/bcm2710-rpi-3-b.dtb
COPY /usr/local/share/raspberrypi-firmware/boot/bcm2710-rpi-3-b-plus.dtb
usr/mdec/rpi/bcm2710-rpi-3-b-plus.dtb
COPY /usr/local/share/raspberrypi-firmware/boot/bcm2710-rpi-cm3.dtb
usr/mdec/rpi/bcm2710-rpi-cm3.dtb
@@ -100,6 +101,7 @@ COPY
/usr/local/share/raspberrypi-firmware/boot/fixup.
COPY /usr/local/share/raspberrypi-firmware/boot/overlays/disable-bt.dtbo
usr/mdec/rpi/disable-bt.dtbo
COPY /usr/local/share/u-boot/rpi_3/u-boot.bin usr/mdec/rpi/u-boot.bin
+MKDIR usr/mdec/pine64
COPY /usr/local/share/u-boot/pine64_plus/u-boot-sunxi-with-spl.bin
usr/mdec/pine64/u-boot-sunxi-with-spl.bin
# copy the MAKEDEV script and make some devices
relayd check script memory explosion
It's fairly easy to accidentally configure relayd to try to run check scripts
faster than they finish, for example if you have a check interval of one
second and the check script makes a tcp connection to a host that doesn't
exist any more.
In this situation, the hce process will keep writing messages to its imsg
buffer to the parent process asking it to run checks, which causes its memory
usage to grow without bounds. If the check script starts working again
(or if you change it to just 'exit 0') the parent works its way through the
backlog and memory usage goes back to normal, but ideally relayd would avoid
doing this to itself.
If we don't clear the F_CHECK_SENT and F_CHECK_DONE flags in
hce_launch_checks(), check_script() can use them to figure out if the
last check request it sent for the host has finished yet, so it can avoid
building up a backlog of work for the parent. The ICMP and script check
implementations clear these flags as they start checks, and the TCP check
code doesn't use them at all, so this shouldn't affect anything else.
ok?
Index: check_script.c
===
RCS file: /cvs/src/usr.sbin/relayd/check_script.c,v
retrieving revision 1.21
diff -u -p -u -p -r1.21 check_script.c
--- check_script.c 28 May 2017 10:39:15 - 1.21
+++ check_script.c 15 Feb 2021 01:28:54 -
@@ -38,6 +38,9 @@ check_script(struct relayd *env, struct
struct ctl_scriptscr;
struct table*table;
+ if ((host->flags & (F_CHECK_SENT|F_CHECK_DONE)) == F_CHECK_SENT)
+ return;
+
if ((table = table_find(env, host->conf.tableid)) == NULL)
fatalx("%s: invalid table id", __func__);
@@ -52,7 +55,9 @@ check_script(struct relayd *env, struct
fatalx("invalid script path");
memcpy(, >conf.timeout, sizeof(scr.timeout));
- proc_compose(env->sc_ps, PROC_PARENT, IMSG_SCRIPT, , sizeof(scr));
+ if (proc_compose(env->sc_ps, PROC_PARENT, IMSG_SCRIPT, ,
+ sizeof(scr)) == 0)
+ host->flags |= F_CHECK_SENT;
}
void
Index: hce.c
===
RCS file: /cvs/src/usr.sbin/relayd/hce.c,v
retrieving revision 1.79
diff -u -p -u -p -r1.79 hce.c
--- hce.c 6 Aug 2018 17:31:31 - 1.79
+++ hce.c 15 Feb 2021 01:28:54 -
@@ -139,7 +139,6 @@ hce_launch_checks(int fd, short event, v
TAILQ_FOREACH(host, >hosts, entry) {
if ((host->flags & F_CHECK_DONE) == 0)
host->he = HCE_INTERVAL_TIMEOUT;
- host->flags &= ~(F_CHECK_SENT|F_CHECK_DONE);
if (event_initialized(>cte.ev)) {
event_del(>cte.ev);
close(host->cte.s);
veb(4), a virtual ethernet bridge (that could replace bridge(4)?)
i was bored at home a few weeks back, so i had a go at scratching an itch i've had for a while now which was to write a quick and dirty ethernet switch. the itch got worse recently when stsp@ asked about some weird packet behaviour that may or may not have been caused by bridge(4). trying to follow the code and how it interacts with the stack was... challenging. since then it has become less quick and dirty, and i've shined it enough that i think it should be considered for the tree. however, it's not a rewrite of bridge(4), there's some very significant semantic differences that need to be explained. the new driver is called veb(4), short for Virtual Ethernet Bridge. it also contains a companion driver called vport(4), which i'll explain on the way. veb(4), like bridge(4), is a software implementation of an ethernet switch. it is also represented as a virtual clonable interface that you create at runtime, and then you add other ethernet interfaces to as ports. these ethernet interfaces then act like ports on a switch. packets received by the ethernet port interfaces are input to the switch, which then decides which other Ethernet port interface to send the packet out of based on the destination ethernet address. the most fundamental difference between bridge(4) and veb(4) is that veb(4) takes over ports completely and only uses them for l2. packets coming into a veb member goes into the switching code, and then the packet pops out another interface. that's it. this is different to bridge(4), which kind of treats each member interface as two ports, one which goes to the wire and one which goes to the network stack using that port. this is where a lot of my confusion about the bridge(4) comes from, both in terms of the code and when im trying to actually use it. this difference is where most of the simplifcation in veb comes from, and is fundamental to how it works. because veb is only a layer 2 switch, by default does not interact with the layer 3 kernel handling at all. this includes both the ip/mpls stacks, and pf. probably the biggest visible consequence of this is if you add an interface that is currently how you're connected to the host, veb(4) will basically take those packets away from the stack and you'll be disconnected. to have pf look at packets going in and out of interfaces on a veb(4), you have to enable the link1 flag. if you want the layer 3 stacks in the kernel to participate on a veb(4), you have to explicitly create and add vport(4) interfaces. vport(4) is special, and is handled specially by veb(4). one half of the special handling is that veb(4) tries to disable l3 handling on ports, but it doesnt do that on vport(4) ports. this allows you to treat vport interfaces like a normal ethernet interface, but instead of being plugged into a physical switch, the vport interface is plugged into the virtual switch. veb does not run pf on vport inteface because pf will be run as packets enter and leave the network stack. the stack runs pf on vport interfaces regardless of whether link1 is set on the veb interface or not. a weird consequence of this is that pf on vport interfaces runs in the opposite direction of pf on other veb ports. packets going from veb out to an interface have pf run with PF_OUT, but if the packet is going from veb to a vport, it will be run with PF_IN by the stack. the reason that pf is disabled on normal port interfaces by default is to minimise the complications in pf state tracking that happen in this situation. a simple ruleset with pf enabled on normal ports would have a state get created when it enters the member port. then if the packet was destined for the vport, it would match the same state in the same direction that was created on the normal port. having vports as explicit interfaces you have to create and add to the veb allows for a couple of interesting use cases. firstly, you can use veb as a nexus between different rdomains by attaching multiple vports in their own rdomains to the same veb. i think ive figured all the dragons out in the code to support that. as always, care must be taken with how and when pf gets run on those different interfaces. the second is that you can have veb implement as a "bump in the wire", applying policy or monitoring to traffic going over the veb with confidence that it won't leak into the stack of the local system unless you explicitly configure it to do so. another part of the itch this diff was tryign to scratch was factoring out the bridge (not bridge(4)) code i have in bpe and nvgre. there's now some common code in if_etherbridge that is used by bpe, nvgre, and veb(4) that handles the actual leaning and port lookups used by all those drivers. i am also looking at using that same code for vxlan(4), but i'm holding off on that because i'd probably want to rework that code to use udp sockets at the same time. some of the recent polishing has been to implemented the "protected" pvlan, and filter rules features
Re: Posted vs. non-posted device access
Am Mon, Feb 15, 2021 at 09:55:56AM +1000 schrieb David Gwynne: > > > > On 15 Feb 2021, at 07:54, Mark Kettenis wrote: > > > > One of the aspects of device access is whether CPU writes to a device > > are posted or non-posted. For non-posted writes, the CPU will wait > > for the device to acknowledge that the write has performed. If the > > device sits on a bus far away, this can take a while and slow things > > down. The alternative are so-called posted writes. The CPU will > > "post" the write to the bus without waiting for an acknowledgement. > > The CPU may receive an asynchronous notifaction at a later time that > > the write didn't succeed or a failing write may be dropped without > > further botification. On most architectures whether writes are posted > > or not is a property of the bus between the CPU and the device. For > > example, memory mapped I/O on the PCI bus is always posted and there > > is nothing the CPU can do about it. > > > > On the ARM architecture though we can indicate to the CPU whether > > writes to a certain address range should be posted or not. This is > > done by specifying certain memory attributes in the mappings used by > > the MMU. The OpenBSD kernel always specifies device access as > > non-posted. On all ARM implementations we have seen so far this seems > > to work even for writes to devices connected to a PCIe bus. There > > might be a penalty though, so I need to investigate this a bit > > further. > > > > However, on Apple's M1 SoC, this isn't the case. Non-posted writes to > > a bus that uses posted writes fail and vice-versa. So in order to use > > the PCIe bus on these SoCs we need to specify the right memory > > attributes. The diff below implements this by introducing a new > > BUS_SPACE_MAP_POSTED flag. At this point I don't expect generic > > drivers to use this flag yet. So there is no need to add it for other > > architectures. But I don't rule out we may have to use this flag in > > sys/dev/fdt sometime in the future. That is why I posted this to a > > wider audience. > > You don't want to (ab)use one of the existing flags? If I squint and read > kind of quickly I could imagine this is kind of like write combining, like > what BUS_SPACE_MAP_PREFETCHABLE can do on pci busses. BUS_SPACE_MAP_PREFETCHABLE should be "normal uncached" memory on arm64, which is different to device memory. That said I have a device where amdgpu(4) doesn't behave if it's "normal uncached", and I'm not sure if it's the HW's fault or if there's some barrier missing. Still, I would not use BUS_SPACE_MAP_PREFETCHABLE for nGnRnE vs nGnRE. More info on device vs normal is here: https://developer.arm.com/documentation/102376/0100/Normal-memory https://developer.arm.com/documentation/102376/0100/Device-memory > If this does leak into fdt, would it just be a nop on other archs that use > those drivers? > > dlg > > > > > ok? > > > > > > Index: arch/arm64/arm64/locore.S > > === > > RCS file: /cvs/src/sys/arch/arm64/arm64/locore.S,v > > retrieving revision 1.32 > > diff -u -p -r1.32 locore.S > > --- arch/arm64/arm64/locore.S 19 Oct 2020 17:57:40 - 1.32 > > +++ arch/arm64/arm64/locore.S 14 Feb 2021 21:28:26 - > > @@ -233,9 +233,10 @@ switch_mmu_kernel: > > mair: > > /* Device | Normal (no cache, write-back, write-through) */ > > .quad MAIR_ATTR(0x00, 0) |\ > > - MAIR_ATTR(0x44, 1) |\ > > - MAIR_ATTR(0xff, 2) |\ > > - MAIR_ATTR(0x88, 3) > > + MAIR_ATTR(0x04, 1) |\ > > + MAIR_ATTR(0x44, 2) |\ > > + MAIR_ATTR(0xff, 3) |\ > > + MAIR_ATTR(0x88, 4) > > tcr: > > .quad (TCR_T1SZ(64 - VIRT_BITS) | TCR_T0SZ(64 - 48) | \ > > TCR_AS | TCR_TG1_4K | TCR_CACHE_ATTRS | TCR_SMP_ATTRS) > > Index: arch/arm64/arm64/locore0.S > > === > > RCS file: /cvs/src/sys/arch/arm64/arm64/locore0.S,v > > retrieving revision 1.5 > > diff -u -p -r1.5 locore0.S > > --- arch/arm64/arm64/locore0.S 28 May 2019 20:32:30 - 1.5 > > +++ arch/arm64/arm64/locore0.S 14 Feb 2021 21:28:26 - > > @@ -34,8 +34,8 @@ > > #include > > > > #define DEVICE_MEM 0 > > -#defineNORMAL_UNCACHED 1 > > -#defineNORMAL_MEM 2 > > +#defineNORMAL_UNCACHED 2 > > +#defineNORMAL_MEM 3 > > > > /* > > * We assume: > > Index: arch/arm64/arm64/machdep.c > > === > > RCS file: /cvs/src/sys/arch/arm64/arm64/machdep.c,v > > retrieving revision 1.57 > > diff -u -p -r1.57 machdep.c > > --- arch/arm64/arm64/machdep.c 11 Feb 2021 23:55:48 - 1.57 > > +++ arch/arm64/arm64/machdep.c 14 Feb 2021 21:28:27 - > > @@ -1188,7 +1188,7 @@ pmap_bootstrap_bs_map(bus_space_tag_t t, > > > > for (pa = startpa; pa < endpa; pa += PAGE_SIZE,
Re: Posted vs. non-posted device access
> On 15 Feb 2021, at 07:54, Mark Kettenis wrote: > > One of the aspects of device access is whether CPU writes to a device > are posted or non-posted. For non-posted writes, the CPU will wait > for the device to acknowledge that the write has performed. If the > device sits on a bus far away, this can take a while and slow things > down. The alternative are so-called posted writes. The CPU will > "post" the write to the bus without waiting for an acknowledgement. > The CPU may receive an asynchronous notifaction at a later time that > the write didn't succeed or a failing write may be dropped without > further botification. On most architectures whether writes are posted > or not is a property of the bus between the CPU and the device. For > example, memory mapped I/O on the PCI bus is always posted and there > is nothing the CPU can do about it. > > On the ARM architecture though we can indicate to the CPU whether > writes to a certain address range should be posted or not. This is > done by specifying certain memory attributes in the mappings used by > the MMU. The OpenBSD kernel always specifies device access as > non-posted. On all ARM implementations we have seen so far this seems > to work even for writes to devices connected to a PCIe bus. There > might be a penalty though, so I need to investigate this a bit > further. > > However, on Apple's M1 SoC, this isn't the case. Non-posted writes to > a bus that uses posted writes fail and vice-versa. So in order to use > the PCIe bus on these SoCs we need to specify the right memory > attributes. The diff below implements this by introducing a new > BUS_SPACE_MAP_POSTED flag. At this point I don't expect generic > drivers to use this flag yet. So there is no need to add it for other > architectures. But I don't rule out we may have to use this flag in > sys/dev/fdt sometime in the future. That is why I posted this to a > wider audience. You don't want to (ab)use one of the existing flags? If I squint and read kind of quickly I could imagine this is kind of like write combining, like what BUS_SPACE_MAP_PREFETCHABLE can do on pci busses. If this does leak into fdt, would it just be a nop on other archs that use those drivers? dlg > > ok? > > > Index: arch/arm64/arm64/locore.S > === > RCS file: /cvs/src/sys/arch/arm64/arm64/locore.S,v > retrieving revision 1.32 > diff -u -p -r1.32 locore.S > --- arch/arm64/arm64/locore.S 19 Oct 2020 17:57:40 - 1.32 > +++ arch/arm64/arm64/locore.S 14 Feb 2021 21:28:26 - > @@ -233,9 +233,10 @@ switch_mmu_kernel: > mair: > /* Device | Normal (no cache, write-back, write-through) */ > .quad MAIR_ATTR(0x00, 0) |\ > - MAIR_ATTR(0x44, 1) |\ > - MAIR_ATTR(0xff, 2) |\ > - MAIR_ATTR(0x88, 3) > + MAIR_ATTR(0x04, 1) |\ > + MAIR_ATTR(0x44, 2) |\ > + MAIR_ATTR(0xff, 3) |\ > + MAIR_ATTR(0x88, 4) > tcr: > .quad (TCR_T1SZ(64 - VIRT_BITS) | TCR_T0SZ(64 - 48) | \ > TCR_AS | TCR_TG1_4K | TCR_CACHE_ATTRS | TCR_SMP_ATTRS) > Index: arch/arm64/arm64/locore0.S > === > RCS file: /cvs/src/sys/arch/arm64/arm64/locore0.S,v > retrieving revision 1.5 > diff -u -p -r1.5 locore0.S > --- arch/arm64/arm64/locore0.S28 May 2019 20:32:30 - 1.5 > +++ arch/arm64/arm64/locore0.S14 Feb 2021 21:28:26 - > @@ -34,8 +34,8 @@ > #include > > #define DEVICE_MEM 0 > -#define NORMAL_UNCACHED 1 > -#define NORMAL_MEM 2 > +#define NORMAL_UNCACHED 2 > +#define NORMAL_MEM 3 > > /* > * We assume: > Index: arch/arm64/arm64/machdep.c > === > RCS file: /cvs/src/sys/arch/arm64/arm64/machdep.c,v > retrieving revision 1.57 > diff -u -p -r1.57 machdep.c > --- arch/arm64/arm64/machdep.c11 Feb 2021 23:55:48 - 1.57 > +++ arch/arm64/arm64/machdep.c14 Feb 2021 21:28:27 - > @@ -1188,7 +1188,7 @@ pmap_bootstrap_bs_map(bus_space_tag_t t, > > for (pa = startpa; pa < endpa; pa += PAGE_SIZE, va += PAGE_SIZE) > pmap_kenter_cache(va, pa, PROT_READ | PROT_WRITE, > - PMAP_CACHE_DEV); > + PMAP_CACHE_DEV_NGNRNE); > > virtual_avail = va; > > Index: arch/arm64/arm64/pmap.c > === > RCS file: /cvs/src/sys/arch/arm64/arm64/pmap.c,v > retrieving revision 1.70 > diff -u -p -r1.70 pmap.c > --- arch/arm64/arm64/pmap.c 25 Jan 2021 19:37:17 - 1.70 > +++ arch/arm64/arm64/pmap.c 14 Feb 2021 21:28:28 - > @@ -472,7 +472,7 @@ pmap_enter(pmap_t pm, vaddr_t va, paddr_ > if (pa & PMAP_NOCACHE) > cache = PMAP_CACHE_CI; > if (pa & PMAP_DEVICE) > - cache = PMAP_CACHE_DEV; > +
Posted vs. non-posted device access
One of the aspects of device access is whether CPU writes to a device are posted or non-posted. For non-posted writes, the CPU will wait for the device to acknowledge that the write has performed. If the device sits on a bus far away, this can take a while and slow things down. The alternative are so-called posted writes. The CPU will "post" the write to the bus without waiting for an acknowledgement. The CPU may receive an asynchronous notifaction at a later time that the write didn't succeed or a failing write may be dropped without further botification. On most architectures whether writes are posted or not is a property of the bus between the CPU and the device. For example, memory mapped I/O on the PCI bus is always posted and there is nothing the CPU can do about it. On the ARM architecture though we can indicate to the CPU whether writes to a certain address range should be posted or not. This is done by specifying certain memory attributes in the mappings used by the MMU. The OpenBSD kernel always specifies device access as non-posted. On all ARM implementations we have seen so far this seems to work even for writes to devices connected to a PCIe bus. There might be a penalty though, so I need to investigate this a bit further. However, on Apple's M1 SoC, this isn't the case. Non-posted writes to a bus that uses posted writes fail and vice-versa. So in order to use the PCIe bus on these SoCs we need to specify the right memory attributes. The diff below implements this by introducing a new BUS_SPACE_MAP_POSTED flag. At this point I don't expect generic drivers to use this flag yet. So there is no need to add it for other architectures. But I don't rule out we may have to use this flag in sys/dev/fdt sometime in the future. That is why I posted this to a wider audience. ok? Index: arch/arm64/arm64/locore.S === RCS file: /cvs/src/sys/arch/arm64/arm64/locore.S,v retrieving revision 1.32 diff -u -p -r1.32 locore.S --- arch/arm64/arm64/locore.S 19 Oct 2020 17:57:40 - 1.32 +++ arch/arm64/arm64/locore.S 14 Feb 2021 21:28:26 - @@ -233,9 +233,10 @@ switch_mmu_kernel: mair: /* Device | Normal (no cache, write-back, write-through) */ .quad MAIR_ATTR(0x00, 0) |\ - MAIR_ATTR(0x44, 1) |\ - MAIR_ATTR(0xff, 2) |\ - MAIR_ATTR(0x88, 3) + MAIR_ATTR(0x04, 1) |\ + MAIR_ATTR(0x44, 2) |\ + MAIR_ATTR(0xff, 3) |\ + MAIR_ATTR(0x88, 4) tcr: .quad (TCR_T1SZ(64 - VIRT_BITS) | TCR_T0SZ(64 - 48) | \ TCR_AS | TCR_TG1_4K | TCR_CACHE_ATTRS | TCR_SMP_ATTRS) Index: arch/arm64/arm64/locore0.S === RCS file: /cvs/src/sys/arch/arm64/arm64/locore0.S,v retrieving revision 1.5 diff -u -p -r1.5 locore0.S --- arch/arm64/arm64/locore0.S 28 May 2019 20:32:30 - 1.5 +++ arch/arm64/arm64/locore0.S 14 Feb 2021 21:28:26 - @@ -34,8 +34,8 @@ #include #defineDEVICE_MEM 0 -#defineNORMAL_UNCACHED 1 -#defineNORMAL_MEM 2 +#defineNORMAL_UNCACHED 2 +#defineNORMAL_MEM 3 /* * We assume: Index: arch/arm64/arm64/machdep.c === RCS file: /cvs/src/sys/arch/arm64/arm64/machdep.c,v retrieving revision 1.57 diff -u -p -r1.57 machdep.c --- arch/arm64/arm64/machdep.c 11 Feb 2021 23:55:48 - 1.57 +++ arch/arm64/arm64/machdep.c 14 Feb 2021 21:28:27 - @@ -1188,7 +1188,7 @@ pmap_bootstrap_bs_map(bus_space_tag_t t, for (pa = startpa; pa < endpa; pa += PAGE_SIZE, va += PAGE_SIZE) pmap_kenter_cache(va, pa, PROT_READ | PROT_WRITE, - PMAP_CACHE_DEV); + PMAP_CACHE_DEV_NGNRNE); virtual_avail = va; Index: arch/arm64/arm64/pmap.c === RCS file: /cvs/src/sys/arch/arm64/arm64/pmap.c,v retrieving revision 1.70 diff -u -p -r1.70 pmap.c --- arch/arm64/arm64/pmap.c 25 Jan 2021 19:37:17 - 1.70 +++ arch/arm64/arm64/pmap.c 14 Feb 2021 21:28:28 - @@ -472,7 +472,7 @@ pmap_enter(pmap_t pm, vaddr_t va, paddr_ if (pa & PMAP_NOCACHE) cache = PMAP_CACHE_CI; if (pa & PMAP_DEVICE) - cache = PMAP_CACHE_DEV; + cache = PMAP_CACHE_DEV_NGNRNE; pg = PHYS_TO_VM_PAGE(pa); pmap_lock(pm); @@ -648,7 +648,7 @@ _pmap_kenter_pa(vaddr_t va, paddr_t pa, pmap_pte_insert(pted); ttlb_flush(pm, va & ~PAGE_MASK); - if (cache == PMAP_CACHE_CI || cache == PMAP_CACHE_DEV) + if (cache == PMAP_CACHE_CI || cache == PMAP_CACHE_DEV_NGNRNE) cpu_idcache_wbinv_range(va & ~PAGE_MASK, PAGE_SIZE); } @@ -735,7 +735,9 @@ pmap_fill_pte(pmap_t pm, vaddr_t va, pad
Re: Back-out USB data toggle fix
On Sun, Feb 14, 2021 at 04:43:17PM +, Stuart Henderson wrote:
> On 2021/02/14 15:22, Marcus Glocker wrote:
> > Unfortunately I'm seeing more and more USB device breakages reported
> > the last few days related to the USB data toggle fix which we did
> > commit 2-3 weeks ago.
>
> Do you think this could this be implicated in a keyboard with 'stuck'
> keys i.e. keep repeating? I've hit it a few times recently, but didn't
> look that far back. (Nothing amiss in logs when it happens).
I don't think so since the issue also has been reported for some fido(4)
devices.
> > +/*
> > + * Workaround for OpenBSD <=6.6-current (as of 201910) bug that loses
> > + * sync of DATA0/DATA1 sequence bit across uhid open/close.
> > + * Send pings until we get a response - early pings with incorrect
> > + * sequence bits will be ignored as duplicate packets by the device.
> > + */
> > +static int
> > +terrible_ping_kludge(struct hid_openbsd *ctx)
>
> it will need to be put back in chromium too (and port revision will
> need to be bumped)
Right, the chromium diff was included, but I did forget to bump.
Index: www/chromium/Makefile
===
RCS file: /cvs/ports/www/chromium/Makefile,v
retrieving revision 1.546
diff -u -p -u -p -r1.546 Makefile
--- www/chromium/Makefile 6 Feb 2021 07:33:27 - 1.546
+++ www/chromium/Makefile 14 Feb 2021 19:24:08 -
@@ -18,6 +18,7 @@ COMMENT= Chromium browser
V= 88.0.4324.150
DISTNAME= chromium-${V}
+REVISION= 0
DISTFILES+=chromium-${V}${EXTRACT_SUFX}
Index: www/chromium/files/hid_service_fido.cc
===
RCS file: /cvs/ports/www/chromium/files/hid_service_fido.cc,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 hid_service_fido.cc
--- www/chromium/files/hid_service_fido.cc 6 Feb 2021 05:05:04 -
1.4
+++ www/chromium/files/hid_service_fido.cc 14 Feb 2021 19:24:09 -
@@ -11,7 +11,10 @@
#include
#include
+// TODO: remove once the missing guard in fido.h is fixed upstream.
+extern "C" {
#include
+}
#include
#include
@@ -72,6 +75,55 @@ void FinishOpen(std::unique_ptr params) {
base::ScopedBlockingCall scoped_blocking_call(FROM_HERE,
base::BlockingType::MAY_BLOCK);
@@ -85,6 +137,11 @@ void OpenOnBlockingThread(std::unique_pt
if (!device_file.IsValid()) {
HID_LOG(EVENT) << "Failed to open '" << device_node << "': "
<< base::File::ErrorToString(device_file.error_details());
+task_runner->PostTask(FROM_HERE,
base::BindOnce(std::move(params->callback), nullptr));
+return;
+ }
+ if (!terrible_ping_kludge(device_file.GetPlatformFile(), device_node)) {
+HID_LOG(EVENT) << "Failed to ping " << device_node;
task_runner->PostTask(FROM_HERE,
base::BindOnce(std::move(params->callback), nullptr));
return;
}
Re: ftp: make use of getline(3)
Christian Weisgerber:
> > Make use of getline(3) in ftp(1).
> >
> > Replace fparseln(3) with getline(3). This removes the only use
> > of libutil.a(fparseln.o) from the ramdisk.
> > Replace a complicated fgetln(3) idiom with the much simpler getline(3).
>
> OK?
ping?
I've been fetching distfiles with it, and I also built a bsd.rd and
performed a http install with it.
Index: distrib/special/ftp/Makefile
===
RCS file: /cvs/src/distrib/special/ftp/Makefile,v
retrieving revision 1.14
diff -u -p -r1.14 Makefile
--- distrib/special/ftp/Makefile16 May 2019 12:44:17 - 1.14
+++ distrib/special/ftp/Makefile29 Jan 2021 18:05:46 -
@@ -6,7 +6,4 @@ PROG= ftp
SRCS= fetch.c ftp.c main.c small.c util.c
.PATH: ${.CURDIR}/../../../usr.bin/ftp
-LDADD+=-lutil
-DPADD+=${LIBUTIL}
-
.include
Index: usr.bin/ftp/Makefile
===
RCS file: /cvs/src/usr.bin/ftp/Makefile,v
retrieving revision 1.34
diff -u -p -r1.34 Makefile
--- usr.bin/ftp/Makefile27 Jan 2021 22:27:41 - 1.34
+++ usr.bin/ftp/Makefile29 Jan 2021 17:57:31 -
@@ -8,8 +8,8 @@ PROG= ftp
SRCS= cmds.c cmdtab.c complete.c cookie.c domacro.c fetch.c ftp.c \
list.c main.c ruserpass.c small.c stringlist.c util.c
-LDADD+=-ledit -lcurses -lutil -ltls -lssl -lcrypto
-DPADD+=${LIBEDIT} ${LIBCURSES} ${LIBUTIL} ${LIBTLS} ${LIBSSL}
${LIBCRYPTO}
+LDADD+=-ledit -lcurses -ltls -lssl -lcrypto
+DPADD+=${LIBEDIT} ${LIBCURSES} ${LIBTLS} ${LIBSSL} ${LIBCRYPTO}
#COPTS+= -Wall -Wconversion -Wstrict-prototypes -Wmissing-prototypes
Index: usr.bin/ftp/cookie.c
===
RCS file: /cvs/src/usr.bin/ftp/cookie.c,v
retrieving revision 1.9
diff -u -p -r1.9 cookie.c
--- usr.bin/ftp/cookie.c16 May 2019 12:44:17 - 1.9
+++ usr.bin/ftp/cookie.c6 Feb 2021 16:23:32 -
@@ -58,10 +58,10 @@ void
cookie_load(void)
{
field_t field;
- size_t len;
time_t date;
char*line;
- char*lbuf;
+ char*lbuf = NULL;
+ size_t lbufsize = 0;
char*param;
const char *estr;
FILE*fp;
@@ -75,19 +75,9 @@ cookie_load(void)
if (fp == NULL)
err(1, "cannot open cookie file %s", cookiefile);
date = time(NULL);
- lbuf = NULL;
- while ((line = fgetln(fp, )) != NULL) {
- if (line[len - 1] == '\n') {
- line[len - 1] = '\0';
- --len;
- } else {
- if ((lbuf = malloc(len + 1)) == NULL)
- err(1, NULL);
- memcpy(lbuf, line, len);
- lbuf[len] = '\0';
- line = lbuf;
- }
- line[strcspn(line, "\r")] = '\0';
+ while (getline(, , fp) != -1) {
+ line = lbuf;
+ line[strcspn(line, "\r\n")] = '\0';
line += strspn(line, " \t");
if ((*line == '#') || (*line == '\0')) {
Index: usr.bin/ftp/fetch.c
===
RCS file: /cvs/src/usr.bin/ftp/fetch.c,v
retrieving revision 1.200
diff -u -p -r1.200 fetch.c
--- usr.bin/ftp/fetch.c 2 Feb 2021 12:58:42 - 1.200
+++ usr.bin/ftp/fetch.c 2 Feb 2021 13:59:09 -
@@ -56,7 +56,6 @@
#include
#include
#include
-#include
#include
#include
@@ -76,7 +75,6 @@ static void aborthttp(int);
static charhextochar(const char *);
static char*urldecode(const char *);
static char*recode_credentials(const char *_userinfo);
-static char*ftp_readline(FILE *, size_t *);
static voidftp_close(FILE **, struct tls **, int *);
static const char *sockerror(struct tls *);
#ifdef SMALL
@@ -330,6 +328,7 @@ url_get(const char *origline, const char
off_t hashbytes;
const char *errstr;
ssize_t len, wlen;
+ size_t bufsize;
char *proxyhost = NULL;
#ifndef NOSSL
char *sslpath = NULL, *sslhost = NULL;
@@ -805,12 +804,13 @@ noslash:
free(buf);
#endif /* !NOSSL */
buf = NULL;
+ bufsize = 0;
if (fflush(fin) == EOF) {
warnx("Writing HTTP request: %s", sockerror(tls));
goto cleanup_url_get;
}
- if ((buf = ftp_readline(fin, )) == NULL) {
+ if ((len = getline(, , fin)) == -1) {
warnx("Receiving HTTP reply: %s", sockerror(tls));
goto cleanup_url_get;
}
@@ -885,11 +885,10 @@ noslash:
/*
* Read the rest of the header.
*/
- free(buf);
filesize = -1;
for (;;) {
- if ((buf = ftp_readline(fin, )) ==
Remove unused variables in bin/ps
Hi,
I stumbled upon some compiler warnings in bin/.
This diff removes two unused variables in bin/ps/print.c.
I hope that such tiny contributions are welcome.
For me, it's a test of whether I am contributing the right way.
diff --git bin/ps/print.c bin/ps/print.c
index 71d4a72a842..c10d8aa0523 100644
--- bin/ps/print.c
+++ bin/ps/print.c
@@ -305,8 +305,7 @@ printstate(const struct kinfo_proc *kp, VARENT *ve)
void
printpledge(const struct kinfo_proc *kp, VARENT *ve)
{
- int flag, i;
- char *cp, state = '\0';
+ int i;
VAR *v;
char buf[1024];
Re: [PATCH] umb(4) fix for X20 (DW5821e) in Dell Latitude 7300
On Thu, Dec 10, 2020 at 10:03:16PM -0800, Bryan Vyhmeister wrote:
> On Mon, Nov 30, 2020 at 07:58:39AM -0800, Bryan Vyhmeister wrote:
> > On Mon, Oct 19, 2020 at 08:11:04PM -0700, Bryan Vyhmeister wrote:
> > > On Fri, Oct 02, 2020 at 12:33:15PM -0700, Bryan Vyhmeister wrote:
> > > > On Wed, Sep 30, 2020 at 04:05:51PM -0700, Bryan Vyhmeister wrote:
> > > > > Gerhard Roth provided a patch to me to get the Qualcomm Snapdragon X20
> > > > > umb(4) interface in my Dell Latitude 7300 working. It is also known
> > > > > as a
> > > > > Dell DW5821e interface. I have been using this patch for months now
> > > > > with
> > > > > AT Wireless in the US and it works great just as I have been used to
> > > > > on my ThinkPad X270 with the older umb(4) interface. This is how it
> > > > > shows up now in my dmesg:
> > > > >
> > > > > umb0 at uhub0 port 16 "Dell Inc. DW5821e Snapdragon X20 LTE" rev
> > > > > 3.10/3.18 addr 2
> > > > >
> > > > > I would love to get this committed at some point so I no longer have
> > > > > to
> > > > > keep compiling a new kernel for every snapshot to have umb(4) working.
> > > >
> > > > Thanks to jmc@ for suggesting a man page diff as well. Both the diff for
> > > > if_umb.c and umb.4 are below.
> > >
> > > Ping.
> >
> > Any further comments on this patch? I would love to see this fixed so
> > umb(4) on my laptop will work fine without a custom kernel. Thank you.
>
> Ping. Any feedback? Thank you.
Here is the updated patch by Gerhard Roth for umb(4) reflecting the
bNumInterface to bNumInterfaces change. Any willing to take a look?
Thank you.
Bryan
Index: share/man/man4/umb.4
===
RCS file: /cvs/src/share/man/man4/umb.4,v
retrieving revision 1.11
diff -u -p -r1.11 umb.4
--- share/man/man4/umb.412 May 2020 13:03:52 - 1.11
+++ share/man/man4/umb.42 Oct 2020 19:30:53 -
@@ -44,6 +44,7 @@ PIN again even if the system was reboote
The following devices should work:
.Pp
.Bl -tag -width Ds -offset indent -compact
+.It Dell DW5821e
.It Ericsson H5321gw and N5321gw
.It Fibocom L831-EAU
.It Medion Mobile S4222 (MediaTek OEM)
Index: sys/dev/usb/if_umb.c
===
RCS file: /cvs/src/sys/dev/usb/if_umb.c,v
retrieving revision 1.36
diff -u -p -r1.36 if_umb.c
--- sys/dev/usb/if_umb.c22 Jul 2020 02:16:02 - 1.36
+++ sys/dev/usb/if_umb.c2 Oct 2020 19:30:53 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: if_umb.c,v 1.36 2020/07/22 02:16:02 dlg Exp $ */
+/* $OpenBSD: if_umb.c,v 1.34 2020/05/04 14:41:03 gerhard Exp $ */
/*
* Copyright (c) 2016 genua mbH
@@ -225,6 +225,26 @@ const struct cfattach umb_ca = {
int umb_delay = 4000;
/*
+ * Normally, MBIM devices are detected by their interface class and subclass.
+ * But for some models that have multiple configurations, it is better to
+ * match by vendor and product id so that we can select the desired
+ * configuration ourselves.
+ *
+ * OTOH, some devices identifiy themself als an MBIM device but fail to speak
+ * the MBIM protocol.
+ */
+struct umb_products {
+ struct usb_devno dev;
+ int confno;
+};
+const struct umb_products umb_devs[] = {
+ { { USB_VENDOR_DELL, 0x81d7 }, 2 }, /* XXX FIXME */
+};
+
+#define umb_lookup(vid, pid) \
+ ((const struct umb_products *)usb_lookup(umb_devs, vid, pid))
+
+/*
* These devices require an "FCC Authentication" command.
*/
const struct usb_devno umb_fccauth_devs[] = {
@@ -263,6 +283,8 @@ umb_match(struct device *parent, void *m
struct usb_attach_arg *uaa = aux;
usb_interface_descriptor_t *id;
+ if (umb_lookup(uaa->vendor, uaa->product) != NULL)
+ return UMATCH_VENDOR_PRODUCT;
if (!uaa->iface)
return UMATCH_NONE;
if ((id = usbd_get_interface_descriptor(uaa->iface)) == NULL)
@@ -315,6 +337,43 @@ umb_attach(struct device *parent, struct
sc->sc_ctrl_ifaceno = uaa->ifaceno;
ml_init(>sc_tx_ml);
+ if (uaa->configno < 0) {
+ /*
+* In case the device was matched by VID/PID instead of
+* InterfaceClass/InterfaceSubClass, we have to pick the
+* correct configuration ourself.
+*/
+ uaa->configno = umb_lookup(uaa->vendor, uaa->product)->confno;
+ DPRINTF("%s: switching to config #%d\n", DEVNAM(sc),
+ uaa->configno);
+ status = usbd_set_config_no(sc->sc_udev, uaa->configno, 1);
+ if (status) {
+ printf("%s: failed to switch to config #%d: %s\n",
+ DEVNAM(sc), uaa->configno, usbd_errstr(status));
+ goto fail;
+ }
+ usbd_delay_ms(sc->sc_udev, 200);
+
+ /*
+* Need to do some manual setups that
rpki-client: get Authority Information Access (AIA) from CA & EE certs
Make the AIA more easily available for debugging purposes & future
changesets
In the context of the RPKI, the AIA extension identifies the publication
point of the certificate of the issuer of the certificate in which the
extension appears. A single reference to the publication point of the
immediate superior certificate MUST be present, except for a
"self-signed" certificate.
OK?
Kind regards,
Job
Index: regress/usr.sbin/rpki-client/test-cert.c
===
RCS file: /cvs/src/regress/usr.sbin/rpki-client/test-cert.c,v
retrieving revision 1.8
diff -u -p -r1.8 test-cert.c
--- regress/usr.sbin/rpki-client/test-cert.c8 Feb 2021 09:28:58 -
1.8
+++ regress/usr.sbin/rpki-client/test-cert.c14 Feb 2021 17:29:17 -
@@ -52,6 +52,8 @@ cert_print(const struct cert *p)
printf("Subject key identifier: %s\n", p->ski);
if (p->aki != NULL)
printf("Authority key identifier: %s\n", p->aki);
+ if (p->aia != NULL)
+ printf("Authority info access: %s\n", p->aia);
for (i = 0; i < p->asz; i++)
switch (p->as[i].type) {
Index: regress/usr.sbin/rpki-client/test-gbr.c
===
RCS file: /cvs/src/regress/usr.sbin/rpki-client/test-gbr.c,v
retrieving revision 1.1
diff -u -p -r1.1 test-gbr.c
--- regress/usr.sbin/rpki-client/test-gbr.c 9 Dec 2020 11:30:44 -
1.1
+++ regress/usr.sbin/rpki-client/test-gbr.c 14 Feb 2021 17:29:17 -
@@ -42,6 +42,7 @@ gbr_print(const struct gbr *p)
printf("Subject key identifier: %s\n", p->ski);
printf("Authority key identifier: %s\n", p->aki);
+ printf("Authority info access: %s\n", p->aia);
printf("vcard:\n%s", p->vcard);
}
Index: regress/usr.sbin/rpki-client/test-mft.c
===
RCS file: /cvs/src/regress/usr.sbin/rpki-client/test-mft.c,v
retrieving revision 1.10
diff -u -p -r1.10 test-mft.c
--- regress/usr.sbin/rpki-client/test-mft.c 9 Nov 2020 16:13:02 -
1.10
+++ regress/usr.sbin/rpki-client/test-mft.c 14 Feb 2021 17:29:17 -
@@ -54,6 +54,7 @@ mft_print(const struct mft *p)
printf("Subject key identifier: %s\n", p->ski);
printf("Authority key identifier: %s\n", p->aki);
+ printf("Authority info access: %s\n", p->aia);
for (i = 0; i < p->filesz; i++) {
b64_ntop(p->files[i].hash, sizeof(p->files[i].hash),
hash, sizeof(hash));
Index: regress/usr.sbin/rpki-client/test-roa.c
===
RCS file: /cvs/src/regress/usr.sbin/rpki-client/test-roa.c,v
retrieving revision 1.8
diff -u -p -r1.8 test-roa.c
--- regress/usr.sbin/rpki-client/test-roa.c 29 Jan 2021 10:15:42 -
1.8
+++ regress/usr.sbin/rpki-client/test-roa.c 14 Feb 2021 17:29:17 -
@@ -42,6 +42,7 @@ roa_print(const struct roa *p)
printf("Subject key identifier: %s\n", p->ski);
printf("Authority key identifier: %s\n", p->aki);
+ printf("Authority info access: %s\n", p->aia);
printf("asID: %" PRIu32 "\n", p->asid);
for (i = 0; i < p->ipsz; i++) {
ip_addr_print(>ips[i].addr,
Index: regress/usr.sbin/rpki-client/Makefile.inc
===
RCS file: /cvs/src/regress/usr.sbin/rpki-client/Makefile.inc,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile.inc
--- regress/usr.sbin/rpki-client/Makefile.inc 3 Feb 2021 10:45:12 -
1.6
+++ regress/usr.sbin/rpki-client/Makefile.inc 14 Feb 2021 17:29:17 -
@@ -4,9 +4,9 @@
PROGS += test-ip
PROGS += test-cert
+PROGS += test-gbr
PROGS += test-mft
PROGS += test-roa
-PROGS += test-gbr
PROGS += test-tal
.for p in ${PROGS}
Index: usr.sbin/rpki-client/cert.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/cert.c,v
retrieving revision 1.25
diff -u -p -r1.25 cert.c
--- usr.sbin/rpki-client/cert.c 8 Feb 2021 09:22:53 - 1.25
+++ usr.sbin/rpki-client/cert.c 14 Feb 2021 17:29:18 -
@@ -1079,6 +1079,11 @@ cert_parse_inner(X509 **xp, const char *
case NID_crl_distribution_points:
/* ignored here, handled later */
break;
+ case NID_info_access:
+ free(p.res->aia);
+ p.res->aia = x509_get_aia(x, p.fn);
+ c = (p.res->aia != NULL);
+ break;
case NID_authority_key_identifier:
free(p.res->aki);
p.res->aki = x509_get_aki_ext(ext, p.fn);
Index: usr.sbin/rpki-client/gbr.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/gbr.c,v
retrieving revision 1.4
diff -u -p -r1.4
Re: distrib: make rdsetroot -x to work again
On Sun, Feb 14, 2021 at 09:46:32AM -0700, Theo de Raadt wrote: > Sure. > > I guess the next thing to do would be using gzopen type functions, > to edit a gzip'd version of the file. I am unsure it would be doable in sane manner. rdsetroot is using libelf to do elf manipulation, and the read-write support is using a plain file descriptor. and adding support of gz in libelf is a no for me. gunzip the file before manipulation isn't a big deal. > Then the recent move to .gz files would be more transparent for this > specific use case (which I think is very rare, honestly). I'm not sure > if it matters. I would not say it is rare, but I agree that it isn't a common use case. I recently asked on ports@ about withdraw upobsd tool I wrote (we have sysupgrade in base now which do upgrade better than my tool), and I got several replies from people using it for unattented installation. Thanks. -- Sebastien Marie
Re: distrib: make rdsetroot -x to work again
Sure.
I guess the next thing to do would be using gzopen type functions,
to edit a gzip'd version of the file.
Then the recent move to .gz files would be more transparent for this
specific use case (which I think is very rare, honestly). I'm not sure
if it matters.
> The following diff makes various distrib Makefile to use ${MACHINE}
> instead of hardcoded value.
>
> Currently, some archs are using ${MACHINE} and others are using
> hardcoded value.
>
> Please note I am unsure about sgi: disklabel -w is using
> "OpenBSD/sgi " as packid, and I changed it to "OpenBSD/${MACHINE}".
> But the packid used isn't uniform across archs, so it might not matter.
>
> The purpose is to reduce gradually the difference of Makefile between
> archs.
>
> Comments or OK ?
> --
> Sebastien Marie
>
> Index: amd64/ramdisk_cd/Makefile
> ===
> RCS file: /cvs/src/distrib/amd64/ramdisk_cd/Makefile,v
> retrieving revision 1.28
> diff -u -p -r1.28 Makefile
> --- amd64/ramdisk_cd/Makefile 13 Feb 2021 18:52:08 - 1.28
> +++ amd64/ramdisk_cd/Makefile 14 Feb 2021 13:40:13 -
> @@ -38,18 +38,18 @@ ${FS}: bsd.gz
>
> ${CDROM}: bsd.rd
> rm -rf ${.OBJDIR}/cd-dir
> - mkdir -p ${.OBJDIR}/cd-dir/${OSREV}/amd64
> + mkdir -p ${.OBJDIR}/cd-dir/${OSREV}/${MACHINE}
> mkdir -p ${.OBJDIR}/cd-dir/etc
> - echo "set image /${OSREV}/amd64/bsd.rd" >
> ${.OBJDIR}/cd-dir/etc/boot.conf
> - cp ${.OBJDIR}/bsd.rd ${.OBJDIR}/cd-dir/${OSREV}/amd64
> - cp ${DESTDIR}/usr/mdec/cdbr ${.OBJDIR}/cd-dir/${OSREV}/amd64
> - cp ${DESTDIR}/usr/mdec/cdboot ${.OBJDIR}/cd-dir/${OSREV}/amd64/cdboot
> + echo "set image /${OSREV}/${MACHINE}/bsd.rd" >
> ${.OBJDIR}/cd-dir/etc/boot.conf
> + cp ${.OBJDIR}/bsd.rd ${.OBJDIR}/cd-dir/${OSREV}/${MACHINE}
> + cp ${DESTDIR}/usr/mdec/cdbr ${.OBJDIR}/cd-dir/${OSREV}/${MACHINE}
> + cp ${DESTDIR}/usr/mdec/cdboot
> ${.OBJDIR}/cd-dir/${OSREV}/${MACHINE}/cdboot
> mkhybrid -a -R -T -L -l -d -D -N -o ${.OBJDIR}/${CDROM} \
> - -A "OpenBSD ${OSREV} amd64 bootonly CD" \
> + -A "OpenBSD ${OSREV} ${MACHINE} bootonly CD" \
> -P "Copyright (c) `date +%Y` Theo de Raadt, The OpenBSD project" \
> -p "Theo de Raadt " \
> - -V "OpenBSD/amd64 ${OSREV} boot-only CD" \
> - -b ${OSREV}/amd64/cdbr -c ${OSREV}/amd64/boot.catalog \
> + -V "OpenBSD/${MACHINE} ${OSREV} boot-only CD" \
> + -b ${OSREV}/${MACHINE}/cdbr -c ${OSREV}/${MACHINE}/boot.catalog \
> ${.OBJDIR}/cd-dir
>
> MRDISKTYPE= rdrootb
> Index: hppa/ramdisk/Makefile
> ===
> RCS file: /cvs/src/distrib/hppa/ramdisk/Makefile,v
> retrieving revision 1.46
> diff -u -p -r1.46 Makefile
> --- hppa/ramdisk/Makefile 17 May 2020 17:04:27 - 1.46
> +++ hppa/ramdisk/Makefile 14 Feb 2021 13:40:13 -
> @@ -20,10 +20,10 @@ ${CDROM}: bsd.rd
> rm -rf ${.OBJDIR}/cd-dir/
> mkdir -p ${.OBJDIR}/cd-dir/
> cp bsd.rd ${.OBJDIR}/cd-dir/bsd.rd
> - mkhybrid -A "OpenBSD ${OSREV} hppa bootonly CD" \
> + mkhybrid -A "OpenBSD ${OSREV} ${MACHINE} bootonly CD" \
> -P "Copyright (c) `date +%Y` Theo de Raadt, The OpenBSD project" \
> -p "Theo de Raadt " \
> - -V "OpenBSD/hppa ${OSREV} boot-only CD" \
> + -V "OpenBSD/${MACHINE} ${OSREV} boot-only CD" \
> -o ${.OBJDIR}/${CDROM} ${.OBJDIR}/cd-dir
> dd if=${DESTDIR}/usr/mdec/cdboot of=${.OBJDIR}/${CDROM} \
> bs=32k count=1 conv=notrunc
> Index: i386/ramdisk_cd/Makefile
> ===
> RCS file: /cvs/src/distrib/i386/ramdisk_cd/Makefile,v
> retrieving revision 1.22
> diff -u -p -r1.22 Makefile
> --- i386/ramdisk_cd/Makefile 13 Feb 2021 18:52:08 - 1.22
> +++ i386/ramdisk_cd/Makefile 14 Feb 2021 13:40:13 -
> @@ -35,18 +35,18 @@ ${FS}: bsd.gz
>
> ${CDROM}: bsd.rd
> rm -rf ${.OBJDIR}/cd-dir
> - mkdir -p ${.OBJDIR}/cd-dir/${OSREV}/i386
> + mkdir -p ${.OBJDIR}/cd-dir/${OSREV}/${MACHINE}
> mkdir -p ${.OBJDIR}/cd-dir/etc
> - echo "set image /${OSREV}/i386/bsd.rd" > ${.OBJDIR}/cd-dir/etc/boot.conf
> - cp ${.OBJDIR}/bsd.rd ${.OBJDIR}/cd-dir/${OSREV}/i386
> - cp ${DESTDIR}/usr/mdec/cdbr ${.OBJDIR}/cd-dir/${OSREV}/i386
> - cp ${DESTDIR}/usr/mdec/cdboot ${.OBJDIR}/cd-dir/${OSREV}/i386/cdboot
> + echo "set image /${OSREV}/${MACHINE}/bsd.rd" >
> ${.OBJDIR}/cd-dir/etc/boot.conf
> + cp ${.OBJDIR}/bsd.rd ${.OBJDIR}/cd-dir/${OSREV}/${MACHINE}
> + cp ${DESTDIR}/usr/mdec/cdbr ${.OBJDIR}/cd-dir/${OSREV}/${MACHINE}
> + cp ${DESTDIR}/usr/mdec/cdboot
> ${.OBJDIR}/cd-dir/${OSREV}/${MACHINE}/cdboot
> mkhybrid -a -R -T -L -l -d -D -N -o ${.OBJDIR}/${CDROM} \
> - -A "OpenBSD ${OSREV} i386 bootonly CD" \
> + -A "OpenBSD ${OSREV} ${MACHINE} bootonly CD" \
> -P "Copyright
Re: distrib: reduce differences between archs: use ${MACHINE} when possible
Sebastien Marie wrote:
> Please note I am unsure about sgi: disklabel -w is using
> "OpenBSD/sgi " as packid, and I changed it to "OpenBSD/${MACHINE}".
> But the packid used isn't uniform across archs, so it might not matter.
I think you mean "volid", this is the -V option. The thing to notice here
is the packid is a fixed string-length, and I have hand-padded it with spaces
to make them pretty in various tools, a long time ago. What you are doing
here doesn't harm anything.
> Comments or OK ?
ok with me.
Re: Back-out USB data toggle fix
On 2021/02/14 15:22, Marcus Glocker wrote: > Unfortunately I'm seeing more and more USB device breakages reported > the last few days related to the USB data toggle fix which we did > commit 2-3 weeks ago. Do you think this could this be implicated in a keyboard with 'stuck' keys i.e. keep repeating? I've hit it a few times recently, but didn't look that far back. (Nothing amiss in logs when it happens). > +/* > + * Workaround for OpenBSD <=6.6-current (as of 201910) bug that loses > + * sync of DATA0/DATA1 sequence bit across uhid open/close. > + * Send pings until we get a response - early pings with incorrect > + * sequence bits will be ignored as duplicate packets by the device. > + */ > +static int > +terrible_ping_kludge(struct hid_openbsd *ctx) it will need to be put back in chromium too (and port revision will need to be bumped)
Re: Back-out USB data toggle fix
On Sun, Feb 14, 2021 at 03:22:28PM +0100, Marcus Glocker wrote:
> Unfortunately I'm seeing more and more USB device breakages reported
> the last few days related to the USB data toggle fix which we did
> commit 2-3 weeks ago.
>
> Since I can't reproduce the issue here with my USB gear, it's very
> difficult for me to pin point the issue. Therefore I think we should
> back it out for now.
>
> OK?
Could ugen changes stay and just uhidev be reverted?
> Index: lib/libfido2/src/hid_openbsd.c
> ===
> RCS file: /cvs/src/lib/libfido2/src/hid_openbsd.c,v
> retrieving revision 1.6
> diff -u -p -u -p -r1.6 hid_openbsd.c
> --- lib/libfido2/src/hid_openbsd.c5 Feb 2021 14:19:21 - 1.6
> +++ lib/libfido2/src/hid_openbsd.c14 Feb 2021 13:58:22 -
> @@ -88,6 +88,62 @@ fido_hid_manifest(fido_dev_info_t *devli
> return FIDO_OK;
> }
>
> +/*
> + * Workaround for OpenBSD <=6.6-current (as of 201910) bug that loses
> + * sync of DATA0/DATA1 sequence bit across uhid open/close.
> + * Send pings until we get a response - early pings with incorrect
> + * sequence bits will be ignored as duplicate packets by the device.
> + */
> +static int
> +terrible_ping_kludge(struct hid_openbsd *ctx)
> +{
> + u_char data[256];
> + int i, n;
> + struct pollfd pfd;
> +
> + if (sizeof(data) < ctx->report_out_len + 1)
> + return -1;
> + for (i = 0; i < 4; i++) {
> + memset(data, 0, sizeof(data));
> + /* broadcast channel ID */
> + data[1] = 0xff;
> + data[2] = 0xff;
> + data[3] = 0xff;
> + data[4] = 0xff;
> + /* Ping command */
> + data[5] = 0x81;
> + /* One byte ping only, Vasili */
> + data[6] = 0;
> + data[7] = 1;
> + fido_log_debug("%s: send ping %d", __func__, i);
> + if (fido_hid_write(ctx, data, ctx->report_out_len + 1) == -1)
> + return -1;
> + fido_log_debug("%s: wait reply", __func__);
> + memset(, 0, sizeof(pfd));
> + pfd.fd = ctx->fd;
> + pfd.events = POLLIN;
> + if ((n = poll(, 1, 100)) == -1) {
> + fido_log_debug("%s: poll: %s", __func__,
> strerror(errno));
> + return -1;
> + } else if (n == 0) {
> + fido_log_debug("%s: timed out", __func__);
> + continue;
> + }
> + if (fido_hid_read(ctx, data, ctx->report_out_len, 250) == -1)
> + return -1;
> + /*
> + * Ping isn't always supported on the broadcast channel,
> + * so we might get an error, but we don't care - we're
> + * synched now.
> + */
> + fido_log_debug("%s: got reply", __func__);
> + fido_log_xxd(data, ctx->report_out_len);
> + return 0;
> + }
> + fido_log_debug("%s: no response", __func__);
> + return -1;
> +}
> +
> void *
> fido_hid_open(const char *path)
> {
> @@ -101,6 +157,16 @@ fido_hid_open(const char *path)
> ret->report_in_len = ret->report_out_len = MAX_U2FHID_LEN;
> fido_log_debug("%s: inlen = %zu outlen = %zu", __func__,
> ret->report_in_len, ret->report_out_len);
> +
> + /*
> + * OpenBSD (as of 201910) has a bug that causes it to lose
> + * track of the DATA0/DATA1 sequence toggle across uhid device
> + * open and close. This is a terrible hack to work around it.
> + */
> + if (terrible_ping_kludge(ret) != 0) {
> + fido_hid_close(ret);
> + return NULL;
> + }
>
> return (ret);
> }
> Index: sys/dev/usb/ugen.c
> ===
> RCS file: /cvs/src/sys/dev/usb/ugen.c,v
> retrieving revision 1.115
> diff -u -p -u -p -r1.115 ugen.c
> --- sys/dev/usb/ugen.c5 Feb 2021 08:17:22 - 1.115
> +++ sys/dev/usb/ugen.c14 Feb 2021 13:58:26 -
> @@ -117,7 +117,6 @@ int ugen_do_close(struct ugen_softc *, i
> int ugen_set_config(struct ugen_softc *, int);
> int ugen_set_interface(struct ugen_softc *, int, int);
> int ugen_get_alt_index(struct ugen_softc *, int);
> -void ugen_clear_iface_eps(struct ugen_softc *, struct usbd_interface *);
>
> #define UGENUNIT(n) ((minor(n) >> 4) & 0xf)
> #define UGENENDPOINT(n) (minor(n) & 0xf)
> @@ -310,8 +309,6 @@ ugenopen(dev_t dev, int flag, int mode,
> DPRINTFN(5, ("ugenopen: sc=%p, endpt=%d, dir=%d, sce=%p\n",
>sc, endpt, dir, sce));
> edesc = sce->edesc;
> - /* Clear device endpoint toggle. */
> - ugen_clear_iface_eps(sc, sce->iface);
> switch (UE_GET_XFERTYPE(edesc->bmAttributes)) {
> case UE_INTERRUPT:
> if (dir == OUT) {
> @@ -339,8
Re: distrib: make rdsetroot -x to work again
On Sun, Feb 14, 2021 at 09:54:15AM -0500, Daniel Jakots wrote: > On Sun, 14 Feb 2021 15:23:05 +0100, Sebastien Marie > wrote: > > In the alpha diff, I would put the "-R .eh_frame -R .shstrtab \" line > before the -K line so the -R things are grouped together. I put it after in order to make more obvious it is a MD part (alpha is the sole arch which remove such sections). Some investigations: -R .shstrtab was added in 2017 commit e8a1490d19dbdd7d68fc1a5e96fc7c5115e2c42a from: deraadt date: Sun Sep 17 16:33:07 2017 UTC Some further shrinking, but obviously not enough. Something unknown caused bloat about a month ago (and it wasn't purely the ctf additions since those are being stripped). Maybe the compiler generates different code when stronger debugging information is requested? -R .eh_frame was added in 2004 commit ec828d0bd39e2262e00f331f64c0a74a91cf0e0c from: miod date: Fri Nov 5 21:22:37 2004 UTC Binutils 2.15 require more aggressive stripping for installation media binaries, if we want to still fit on floppies (binaries carry one extra section now, which we don't need on installation media). ok deraadt@ I would be interested to know the bytes gained by removing these sections. We might removed them on others archs too. Thanks. -- Sebastien Marie
Re: distrib: make rdsetroot -x to work again
On Sun, 14 Feb 2021 15:23:05 +0100, Sebastien Marie wrote: > Hi, > > The following diff makes rdsetroot -x (extract the disk.fs image) to > work again for stripped bsd.rd. > > It passes options to keep rd_root_size and rd_root_image symbols while > stripping. These symbols are the ones used by rdsetroot to insert or > extract disk image into RAMDISK. > > If it matter, on my i386 test, the bsd.rd size grows to 284 bytes > before gzip and 113 bytes after gzip. > > While here, uniformize a bit the sections removed (.comment section > wasn't removed on some archs while stripping). > > Comments or OK ? In the alpha diff, I would put the "-R .eh_frame -R .shstrtab \" line before the -K line so the -R things are grouped together. Anyway, ok danj@ Cheers, Daniel
Re: uhidpp(4): logitech hid++ device driver
On Fri, Feb 12, 2021 at 03:48:51AM -0800, Anindya Mukherjee wrote: > Hi, > > Sorry for the delay. I am running the latest snapshot: > kern.version=OpenBSD 6.9-beta (GENERIC.MP) #331: Thu Feb 11 20:28:45 MST 2021 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > which seems to have the latest updates. However I still do not see battery > levels for my M570. Full dmesg below. Please let me know if I can test > anything. Could you try a kernel with revision 1.10 of dev/usb/uhidpp.c present and UHIDPP_DEBUG enabled. I have also prepared an amd64 kernel with the necessary bits available here: https://www.basename.se/tmp/bsd.uhidpp Please send me the complete dmesg from this kernel. It won't make any battery sensors appear but rather help diagnose.
distrib: make rdsetroot -x to work again
Hi,
The following diff makes rdsetroot -x (extract the disk.fs image) to
work again for stripped bsd.rd.
It passes options to keep rd_root_size and rd_root_image symbols while
stripping. These symbols are the ones used by rdsetroot to insert or
extract disk image into RAMDISK.
If it matter, on my i386 test, the bsd.rd size grows to 284 bytes
before gzip and 113 bytes after gzip.
While here, uniformize a bit the sections removed (.comment section
wasn't removed on some archs while stripping).
Comments or OK ?
--
Sebastien Marie
Index: distrib/alpha/miniroot/Makefile
===
RCS file: /cvs/src/distrib/alpha/miniroot/Makefile,v
retrieving revision 1.21
diff -u -p -r1.21 Makefile
--- distrib/alpha/miniroot/Makefile 13 Feb 2021 18:48:23 - 1.21
+++ distrib/alpha/miniroot/Makefile 14 Feb 2021 13:58:49 -
@@ -62,7 +62,10 @@ ${CDROM}: bsd.gz
rm -f vnd
bsd.gz: bsd.rd
- objcopy -S -R .comment -R .SUNW_ctf -R .eh_frame -R .shstrtab bsd.rd
bsd.strip
+ objcopy -S -R .comment -R .SUNW_ctf \
+ -K rd_root_size -K rd_root_image \
+ -R .eh_frame -R .shstrtab \
+ bsd.rd bsd.strip
gzip -9cn bsd.strip > bsd.gz
bsd.rd: mr.fs bsd
Index: distrib/amd64/ramdiskA/Makefile
===
RCS file: /cvs/src/distrib/amd64/ramdiskA/Makefile,v
retrieving revision 1.14
diff -u -p -r1.14 Makefile
--- distrib/amd64/ramdiskA/Makefile 13 Feb 2021 18:52:08 - 1.14
+++ distrib/amd64/ramdiskA/Makefile 14 Feb 2021 13:58:49 -
@@ -33,7 +33,9 @@ MRDISKTYPE= rdroot
MRMAKEFSARGS= -o disklabel=${MRDISKTYPE},minfree=0,density=4096
bsd.gz: bsd.rd
- objcopy -S -R .comment -R .SUNW_ctf bsd.rd bsd.strip
+ objcopy -S -R .comment -R .SUNW_ctf \
+ -K rd_root_size -K rd_root_image \
+ bsd.rd bsd.strip
gzip -9cn bsd.strip > bsd.gz
bsd.rd: mr.fs bsd
Index: distrib/amd64/ramdisk_cd/Makefile
===
RCS file: /cvs/src/distrib/amd64/ramdisk_cd/Makefile,v
retrieving revision 1.28
diff -u -p -r1.28 Makefile
--- distrib/amd64/ramdisk_cd/Makefile 13 Feb 2021 18:52:08 - 1.28
+++ distrib/amd64/ramdisk_cd/Makefile 14 Feb 2021 13:58:49 -
@@ -56,7 +56,9 @@ MRDISKTYPE= rdrootb
MRMAKEFSARGS= -o disklabel=${MRDISKTYPE},minfree=0,density=4096
bsd.gz: bsd.rd
- objcopy -S -R .comment -R .SUNW_ctf bsd.rd bsd.strip
+ objcopy -S -R .comment -R .SUNW_ctf \
+ -K rd_root_size -K rd_root_image \
+ bsd.rd bsd.strip
gzip -9cn bsd.strip > bsd.gz
bsd.rd: mr.fs bsd
Index: distrib/i386/ramdisk/Makefile
===
RCS file: /cvs/src/distrib/i386/ramdisk/Makefile,v
retrieving revision 1.13
diff -u -p -r1.13 Makefile
--- distrib/i386/ramdisk/Makefile 13 Feb 2021 18:52:08 - 1.13
+++ distrib/i386/ramdisk/Makefile 14 Feb 2021 13:58:49 -
@@ -34,7 +34,9 @@ MRDISKTYPE= rdroot
MRMAKEFSARGS= -o disklabel=${MRDISKTYPE},minfree=0,density=4096
bsd.gz: bsd.rd
- objcopy -S -R .comment -R .SUNW_ctf bsd.rd bsd.strip
+ objcopy -S -R .comment -R .SUNW_ctf \
+ -K rd_root_size -K rd_root_image \
+ bsd.rd bsd.strip
gzip -9cn bsd.strip > bsd.gz
bsd.rd: mr.fs bsd
Index: distrib/i386/ramdisk_cd/Makefile
===
RCS file: /cvs/src/distrib/i386/ramdisk_cd/Makefile,v
retrieving revision 1.22
diff -u -p -r1.22 Makefile
--- distrib/i386/ramdisk_cd/Makefile13 Feb 2021 18:52:08 - 1.22
+++ distrib/i386/ramdisk_cd/Makefile14 Feb 2021 13:58:49 -
@@ -53,7 +53,9 @@ MRDISKTYPE= rdrootb
MRMAKEFSARGS= -o disklabel=${MRDISKTYPE},minfree=0,density=4096
bsd.gz: bsd.rd
- objcopy -S -R .comment -R .SUNW_ctf bsd.rd bsd.strip
+ objcopy -S -R .comment -R .SUNW_ctf \
+ -K rd_root_size -K rd_root_image \
+ bsd.rd bsd.strip
gzip -9cn bsd.strip > bsd.gz
bsd.rd: mr.fs bsd
Index: distrib/macppc/ramdisk/Makefile
===
RCS file: /cvs/src/distrib/macppc/ramdisk/Makefile,v
retrieving revision 1.48
diff -u -p -r1.48 Makefile
--- distrib/macppc/ramdisk/Makefile 5 Jan 2021 15:10:43 - 1.48
+++ distrib/macppc/ramdisk/Makefile 14 Feb 2021 13:58:49 -
@@ -35,9 +35,10 @@ bsd.gz: bsd.rd
gzip -9cn bsd.rd > bsd.gz
bsd.rd: mr.fs bsd
- cp bsd bsd.rd
+ objcopy -S -R .comment -R .SUNW_ctf \
+ -K rd_root_size -K rd_root_image \
+ bsd bsd.rd
rdsetroot bsd.rd mr.fs
- strip -R .SUNW_ctf bsd.rd
bsd:
cd ${.CURDIR}/../../../sys/arch/${MACHINE}/compile/${RAMDISK} && \
Index: distrib/sparc64/miniroot/Makefile
Back-out USB data toggle fix
Unfortunately I'm seeing more and more USB device breakages reported
the last few days related to the USB data toggle fix which we did
commit 2-3 weeks ago.
Since I can't reproduce the issue here with my USB gear, it's very
difficult for me to pin point the issue. Therefore I think we should
back it out for now.
OK?
Index: lib/libfido2/src/hid_openbsd.c
===
RCS file: /cvs/src/lib/libfido2/src/hid_openbsd.c,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 hid_openbsd.c
--- lib/libfido2/src/hid_openbsd.c 5 Feb 2021 14:19:21 - 1.6
+++ lib/libfido2/src/hid_openbsd.c 14 Feb 2021 13:58:22 -
@@ -88,6 +88,62 @@ fido_hid_manifest(fido_dev_info_t *devli
return FIDO_OK;
}
+/*
+ * Workaround for OpenBSD <=6.6-current (as of 201910) bug that loses
+ * sync of DATA0/DATA1 sequence bit across uhid open/close.
+ * Send pings until we get a response - early pings with incorrect
+ * sequence bits will be ignored as duplicate packets by the device.
+ */
+static int
+terrible_ping_kludge(struct hid_openbsd *ctx)
+{
+ u_char data[256];
+ int i, n;
+ struct pollfd pfd;
+
+ if (sizeof(data) < ctx->report_out_len + 1)
+ return -1;
+ for (i = 0; i < 4; i++) {
+ memset(data, 0, sizeof(data));
+ /* broadcast channel ID */
+ data[1] = 0xff;
+ data[2] = 0xff;
+ data[3] = 0xff;
+ data[4] = 0xff;
+ /* Ping command */
+ data[5] = 0x81;
+ /* One byte ping only, Vasili */
+ data[6] = 0;
+ data[7] = 1;
+ fido_log_debug("%s: send ping %d", __func__, i);
+ if (fido_hid_write(ctx, data, ctx->report_out_len + 1) == -1)
+ return -1;
+ fido_log_debug("%s: wait reply", __func__);
+ memset(, 0, sizeof(pfd));
+ pfd.fd = ctx->fd;
+ pfd.events = POLLIN;
+ if ((n = poll(, 1, 100)) == -1) {
+ fido_log_debug("%s: poll: %s", __func__,
strerror(errno));
+ return -1;
+ } else if (n == 0) {
+ fido_log_debug("%s: timed out", __func__);
+ continue;
+ }
+ if (fido_hid_read(ctx, data, ctx->report_out_len, 250) == -1)
+ return -1;
+ /*
+* Ping isn't always supported on the broadcast channel,
+* so we might get an error, but we don't care - we're
+* synched now.
+*/
+ fido_log_debug("%s: got reply", __func__);
+ fido_log_xxd(data, ctx->report_out_len);
+ return 0;
+ }
+ fido_log_debug("%s: no response", __func__);
+ return -1;
+}
+
void *
fido_hid_open(const char *path)
{
@@ -101,6 +157,16 @@ fido_hid_open(const char *path)
ret->report_in_len = ret->report_out_len = MAX_U2FHID_LEN;
fido_log_debug("%s: inlen = %zu outlen = %zu", __func__,
ret->report_in_len, ret->report_out_len);
+
+ /*
+* OpenBSD (as of 201910) has a bug that causes it to lose
+* track of the DATA0/DATA1 sequence toggle across uhid device
+* open and close. This is a terrible hack to work around it.
+*/
+ if (terrible_ping_kludge(ret) != 0) {
+ fido_hid_close(ret);
+ return NULL;
+ }
return (ret);
}
Index: sys/dev/usb/ugen.c
===
RCS file: /cvs/src/sys/dev/usb/ugen.c,v
retrieving revision 1.115
diff -u -p -u -p -r1.115 ugen.c
--- sys/dev/usb/ugen.c 5 Feb 2021 08:17:22 - 1.115
+++ sys/dev/usb/ugen.c 14 Feb 2021 13:58:26 -
@@ -117,7 +117,6 @@ int ugen_do_close(struct ugen_softc *, i
int ugen_set_config(struct ugen_softc *, int);
int ugen_set_interface(struct ugen_softc *, int, int);
int ugen_get_alt_index(struct ugen_softc *, int);
-void ugen_clear_iface_eps(struct ugen_softc *, struct usbd_interface *);
#define UGENUNIT(n) ((minor(n) >> 4) & 0xf)
#define UGENENDPOINT(n) (minor(n) & 0xf)
@@ -310,8 +309,6 @@ ugenopen(dev_t dev, int flag, int mode,
DPRINTFN(5, ("ugenopen: sc=%p, endpt=%d, dir=%d, sce=%p\n",
sc, endpt, dir, sce));
edesc = sce->edesc;
- /* Clear device endpoint toggle. */
- ugen_clear_iface_eps(sc, sce->iface);
switch (UE_GET_XFERTYPE(edesc->bmAttributes)) {
case UE_INTERRUPT:
if (dir == OUT) {
@@ -339,8 +336,6 @@ ugenopen(dev_t dev, int flag, int mode,
clfree(>q);
return (EIO);
}
- /* Clear HC endpoint toggle. */
-
distrib: reduce differences between archs: use ${MACHINE} when possible
Hi,
The following diff makes various distrib Makefile to use ${MACHINE}
instead of hardcoded value.
Currently, some archs are using ${MACHINE} and others are using
hardcoded value.
Please note I am unsure about sgi: disklabel -w is using
"OpenBSD/sgi " as packid, and I changed it to "OpenBSD/${MACHINE}".
But the packid used isn't uniform across archs, so it might not matter.
The purpose is to reduce gradually the difference of Makefile between
archs.
Comments or OK ?
--
Sebastien Marie
Index: amd64/ramdisk_cd/Makefile
===
RCS file: /cvs/src/distrib/amd64/ramdisk_cd/Makefile,v
retrieving revision 1.28
diff -u -p -r1.28 Makefile
--- amd64/ramdisk_cd/Makefile 13 Feb 2021 18:52:08 - 1.28
+++ amd64/ramdisk_cd/Makefile 14 Feb 2021 13:40:13 -
@@ -38,18 +38,18 @@ ${FS}: bsd.gz
${CDROM}: bsd.rd
rm -rf ${.OBJDIR}/cd-dir
- mkdir -p ${.OBJDIR}/cd-dir/${OSREV}/amd64
+ mkdir -p ${.OBJDIR}/cd-dir/${OSREV}/${MACHINE}
mkdir -p ${.OBJDIR}/cd-dir/etc
- echo "set image /${OSREV}/amd64/bsd.rd" >
${.OBJDIR}/cd-dir/etc/boot.conf
- cp ${.OBJDIR}/bsd.rd ${.OBJDIR}/cd-dir/${OSREV}/amd64
- cp ${DESTDIR}/usr/mdec/cdbr ${.OBJDIR}/cd-dir/${OSREV}/amd64
- cp ${DESTDIR}/usr/mdec/cdboot ${.OBJDIR}/cd-dir/${OSREV}/amd64/cdboot
+ echo "set image /${OSREV}/${MACHINE}/bsd.rd" >
${.OBJDIR}/cd-dir/etc/boot.conf
+ cp ${.OBJDIR}/bsd.rd ${.OBJDIR}/cd-dir/${OSREV}/${MACHINE}
+ cp ${DESTDIR}/usr/mdec/cdbr ${.OBJDIR}/cd-dir/${OSREV}/${MACHINE}
+ cp ${DESTDIR}/usr/mdec/cdboot
${.OBJDIR}/cd-dir/${OSREV}/${MACHINE}/cdboot
mkhybrid -a -R -T -L -l -d -D -N -o ${.OBJDIR}/${CDROM} \
- -A "OpenBSD ${OSREV} amd64 bootonly CD" \
+ -A "OpenBSD ${OSREV} ${MACHINE} bootonly CD" \
-P "Copyright (c) `date +%Y` Theo de Raadt, The OpenBSD project" \
-p "Theo de Raadt " \
- -V "OpenBSD/amd64 ${OSREV} boot-only CD" \
- -b ${OSREV}/amd64/cdbr -c ${OSREV}/amd64/boot.catalog \
+ -V "OpenBSD/${MACHINE} ${OSREV} boot-only CD" \
+ -b ${OSREV}/${MACHINE}/cdbr -c ${OSREV}/${MACHINE}/boot.catalog \
${.OBJDIR}/cd-dir
MRDISKTYPE=rdrootb
Index: hppa/ramdisk/Makefile
===
RCS file: /cvs/src/distrib/hppa/ramdisk/Makefile,v
retrieving revision 1.46
diff -u -p -r1.46 Makefile
--- hppa/ramdisk/Makefile 17 May 2020 17:04:27 - 1.46
+++ hppa/ramdisk/Makefile 14 Feb 2021 13:40:13 -
@@ -20,10 +20,10 @@ ${CDROM}: bsd.rd
rm -rf ${.OBJDIR}/cd-dir/
mkdir -p ${.OBJDIR}/cd-dir/
cp bsd.rd ${.OBJDIR}/cd-dir/bsd.rd
- mkhybrid -A "OpenBSD ${OSREV} hppa bootonly CD" \
+ mkhybrid -A "OpenBSD ${OSREV} ${MACHINE} bootonly CD" \
-P "Copyright (c) `date +%Y` Theo de Raadt, The OpenBSD project" \
-p "Theo de Raadt " \
- -V "OpenBSD/hppa ${OSREV} boot-only CD" \
+ -V "OpenBSD/${MACHINE} ${OSREV} boot-only CD" \
-o ${.OBJDIR}/${CDROM} ${.OBJDIR}/cd-dir
dd if=${DESTDIR}/usr/mdec/cdboot of=${.OBJDIR}/${CDROM} \
bs=32k count=1 conv=notrunc
Index: i386/ramdisk_cd/Makefile
===
RCS file: /cvs/src/distrib/i386/ramdisk_cd/Makefile,v
retrieving revision 1.22
diff -u -p -r1.22 Makefile
--- i386/ramdisk_cd/Makefile13 Feb 2021 18:52:08 - 1.22
+++ i386/ramdisk_cd/Makefile14 Feb 2021 13:40:13 -
@@ -35,18 +35,18 @@ ${FS}: bsd.gz
${CDROM}: bsd.rd
rm -rf ${.OBJDIR}/cd-dir
- mkdir -p ${.OBJDIR}/cd-dir/${OSREV}/i386
+ mkdir -p ${.OBJDIR}/cd-dir/${OSREV}/${MACHINE}
mkdir -p ${.OBJDIR}/cd-dir/etc
- echo "set image /${OSREV}/i386/bsd.rd" > ${.OBJDIR}/cd-dir/etc/boot.conf
- cp ${.OBJDIR}/bsd.rd ${.OBJDIR}/cd-dir/${OSREV}/i386
- cp ${DESTDIR}/usr/mdec/cdbr ${.OBJDIR}/cd-dir/${OSREV}/i386
- cp ${DESTDIR}/usr/mdec/cdboot ${.OBJDIR}/cd-dir/${OSREV}/i386/cdboot
+ echo "set image /${OSREV}/${MACHINE}/bsd.rd" >
${.OBJDIR}/cd-dir/etc/boot.conf
+ cp ${.OBJDIR}/bsd.rd ${.OBJDIR}/cd-dir/${OSREV}/${MACHINE}
+ cp ${DESTDIR}/usr/mdec/cdbr ${.OBJDIR}/cd-dir/${OSREV}/${MACHINE}
+ cp ${DESTDIR}/usr/mdec/cdboot
${.OBJDIR}/cd-dir/${OSREV}/${MACHINE}/cdboot
mkhybrid -a -R -T -L -l -d -D -N -o ${.OBJDIR}/${CDROM} \
- -A "OpenBSD ${OSREV} i386 bootonly CD" \
+ -A "OpenBSD ${OSREV} ${MACHINE} bootonly CD" \
-P "Copyright (c) `date +%Y` Theo de Raadt, The OpenBSD project" \
-p "Theo de Raadt " \
- -V "OpenBSD/i386${OSREV} boot-only CD" \
- -b ${OSREV}/i386/cdbr -c ${OSREV}/i386/boot.catalog \
+ -V "OpenBSD/${MACHINE}${OSREV} boot-only CD" \
+ -b ${OSREV}/${MACHINE}/cdbr -c ${OSREV}/${MACHINE}/boot.catalog \
Re: "monitoring only" interfaces
On Sun, Feb 07, 2021 at 06:55:37PM +0100, Sebastian Benoit wrote:
> David Gwynne(da...@gwynne.id.au) on 2021.01.27 17:13:09 +1000:
> > some of the discussion around dup-to made me think that a diff we
> > have here at work might be more broadly useful.
> >
> > we run a box here with a bunch of ethernet ports plugged into span
> > ports on switches. basically every packet going to our firewalls gets
> > duplicated to this host. we then have code that generates flow data from
> > these ports. it's also nice to have one place to ssh to and so you can
> > tcpdump things. anyway, that flow collector watches packets on those
> > interfaces via bpf, but apart from that we don't actually want to
> > do anythign with the packets those interfaces receive. we especially
> > do not want them entering the stack. we ssh to this box over the
> > firewall, so if the span port copies those packets to the box and
> > the stack tries to process them, things dont work great.
> >
> > we could enable the fildrop stuff with bpf, but there's an annoying gap
> > between when the interfaces come up and when the flow collector starts
> > running. also, if the flow collector crashes or we restart it cos we're
> > hacking on the code, this provides more gaps for packets to enter the
> > stack.
> >
> > we prevented this by adding a "monitor" interface flag. it makes the
> > interface input code drop all the packets rather than queuing them for
> > the stack to process.
> >
> > is there any interest in having this in the tree?
> >
> > if so, i need to do some work to make sure all interfaces push
> > packets into the stack with if_input, ifiq_input, or if_vinput. a
> > bunch of them like gif and gre currently call protocol input routines
> > directly, so they skip this check.
> >
> > so, thoughts?
>
> I'd like this.
>
> Previously when i needed something similar, i put the interface into its own
> routing domain. But of course that doesnt avoid the packets entering the
> stack, just some consequences.
>
> I also think 'monitor' is the right keyword for ifconfig.
>
> ok benno, but manpage is missing
this is also missing. this lets l3 interfaces use the if_vinput
machinery by providing a p2p_input handler. for if_vinput to support
p2p interfaces, they have to be able to say what kind of bpf_mtap
handling they need rather than have the machinery assume everything
is an ethernet packet. this also lets us factor out the l3 input
handling from a lot of these drivers.
in turn, this makes it possible to use monitor on gif, gre, mgre,
mpe, and mpip. looks like it would already work on tun, but im not
sure what the point of that is.
ok?
Index: net/if.c
===
RCS file: /cvs/src/sys/net/if.c,v
retrieving revision 1.625
diff -u -p -r1.625 if.c
--- net/if.c18 Jan 2021 09:55:43 - 1.625
+++ net/if.c14 Feb 2021 12:12:21 -
@@ -847,13 +847,17 @@ if_vinput(struct ifnet *ifp, struct mbuf
m->m_pkthdr.ph_ifidx = ifp->if_index;
m->m_pkthdr.ph_rtableid = ifp->if_rdomain;
+#if NPF > 0
+ pf_pkt_addr_changed(m);
+#endif
+
counters_pkt(ifp->if_counters,
ifc_ipackets, ifc_ibytes, m->m_pkthdr.len);
#if NBPFILTER > 0
if_bpf = ifp->if_bpf;
if (if_bpf) {
- if (bpf_mtap_ether(if_bpf, m, BPF_DIRECTION_IN)) {
+ if (ifp->if_bpf_mtap(if_bpf, m, BPF_DIRECTION_IN)) {
m_freem(m);
return;
}
@@ -1497,6 +1501,42 @@ p2p_rtrequest(struct ifnet *ifp, int req
}
}
+int
+p2p_bpf_mtap(caddr_t if_bpf, const struct mbuf *m, u_int dir)
+{
+#if NBPFILTER > 0
+ return (bpf_mtap_af(if_bpf, m->m_pkthdr.ph_family, m, dir));
+#else
+ return (0);
+#endif
+}
+
+void
+p2p_input(struct ifnet *ifp, struct mbuf *m)
+{
+ void (*input)(struct ifnet *, struct mbuf *);
+
+ switch (m->m_pkthdr.ph_family) {
+ case AF_INET:
+ input = ipv4_input;
+ break;
+#ifdef INET6
+ case AF_INET6:
+ input = ipv6_input;
+ break;
+#endif
+#ifdef MPLS
+ case AF_MPLS:
+ input = mpls_input;
+ break;
+#endif
+ default:
+ m_freem(m);
+ return;
+ }
+
+ (*input)(ifp, m);
+}
/*
* Bring down all interfaces
Index: net/if_ethersubr.c
===
RCS file: /cvs/src/sys/net/if_ethersubr.c,v
retrieving revision 1.268
diff -u -p -r1.268 if_ethersubr.c
--- net/if_ethersubr.c 4 Jan 2021 21:21:41 - 1.268
+++ net/if_ethersubr.c 14 Feb 2021 12:12:21 -
@@ -680,7 +680,9 @@ ether_ifattach(struct ifnet *ifp)
if_alloc_sadl(ifp);
memcpy(LLADDR(ifp->if_sadl), ac->ac_enaddr, ifp->if_addrlen);
LIST_INIT(>ac_multiaddrs);
+
#if NBPFILTER > 0
+ ifp->if_bpf_mtap = bpf_mtap_ether;
bpfattach(>if_bpf, ifp, DLT_EN10MB,
Re: man: help pagers recognise HTML files as such
On Wed, Jan 27, 2021 at 10:51:38AM +0100, Klemens Nanni wrote:
> On Wed, Jan 27, 2021 at 01:41:52AM +0100, Ingo Schwarze wrote:
> > It's maybe just a bikeshed, but could you put the logic selecting
> > the filename extension (either "" or ".html") at the place where
> > term_tag_init() is called? That (main.c) is the module where the OUTT_
> > constants are defined, so it's the natural place to make decisions based
> > on them. Then just pass a third const char * into term_tag_init().
> Sounds good.
>
> > Or do you see any downside that approach might have?
> No.
>
> > *If* people ever request the same for PDF, it makes adding that even
> > easier.
> >
> > Also, maybe put the new argument in the middle position because it is
> > only related to the first argument and not to the second.
> >
> > Finally and KNFly, please refrain from using function calls as
> > variable initializers.
> Thanks, how about this?
Same diff reattached which accounts for schwarze's requests.
I'll commit this soon unless I hear objections or further feedback.
Index: main.c
===
RCS file: /cvs/src/usr.bin/mandoc/main.c,v
retrieving revision 1.255
diff -u -p -r1.255 main.c
--- main.c 21 Jul 2020 15:08:48 - 1.255
+++ main.c 27 Jan 2021 09:44:07 -
@@ -824,6 +824,7 @@ process_onefile(struct mparse *mp, struc
if (outst->use_pager) {
outst->use_pager = 0;
outst->tag_files = term_tag_init(conf->output.outfilename,
+ outst->outtype == OUTT_HTML ? ".html" : "",
conf->output.tagfilename);
if ((conf->output.outfilename != NULL ||
conf->output.tagfilename != NULL) &&
Index: term_tag.c
===
RCS file: /cvs/src/usr.bin/mandoc/term_tag.c,v
retrieving revision 1.5
diff -u -p -r1.5 term_tag.c
--- term_tag.c 21 Jul 2020 15:08:49 - 1.5
+++ term_tag.c 27 Jan 2021 09:44:06 -
@@ -45,7 +45,8 @@ static struct tag_files tag_files;
* but for simplicity, create it anyway.
*/
struct tag_files *
-term_tag_init(const char *outfilename, const char *tagfilename)
+term_tag_init(const char *outfilename, const char *suffix,
+const char *tagfilename)
{
struct sigaction sa;
int ofd; /* In /tmp/, dup(2)ed to stdout. */
@@ -83,9 +84,9 @@ term_tag_init(const char *outfilename, c
/* Create both temporary output files. */
if (outfilename == NULL) {
- (void)strlcpy(tag_files.ofn, "/tmp/man.XX",
- sizeof(tag_files.ofn));
- if ((ofd = mkstemp(tag_files.ofn)) == -1) {
+ (void)snprintf(tag_files.ofn, sizeof(tag_files.ofn),
+ "/tmp/man.XX%s", suffix);
+ if ((ofd = mkstemps(tag_files.ofn, strlen(suffix))) == -1) {
mandoc_msg(MANDOCERR_MKSTEMP, 0, 0,
"%s: %s", tag_files.ofn, strerror(errno));
goto fail;
Index: term_tag.h
===
RCS file: /cvs/src/usr.bin/mandoc/term_tag.h,v
retrieving revision 1.3
diff -u -p -r1.3 term_tag.h
--- term_tag.h 21 Jul 2020 15:08:49 - 1.3
+++ term_tag.h 27 Jan 2021 09:36:10 -
@@ -28,7 +28,7 @@ structtag_files {
};
-struct tag_files *term_tag_init(const char *, const char *);
+struct tag_files *term_tag_init(const char *, const char *, const char
*);
voidterm_tag_write(struct roff_node *, size_t);
int term_tag_close(void);
voidterm_tag_unlink(void);
Re: [PATCH] fixes relayd Websocket "Connection: close" header when Upgrade is requested
Another month has passed, another friendly bump... patch against -current attached, for convenience... Marcus Index: relay_http.c === RCS file: /cvs/src/usr.sbin/relayd/relay_http.c,v retrieving revision 1.80 diff -u -p -u -r1.80 relay_http.c --- relay_http.c9 Jan 2021 08:53:58 - 1.80 +++ relay_http.c14 Feb 2021 11:03:12 - @@ -527,7 +527,7 @@ relay_read_http(struct bufferevent *bev, * Ask the server to close the connection after this request * since we don't read any further request headers. */ - if (cre->toread == TOREAD_UNLIMITED) + if (cre->toread == TOREAD_UNLIMITED && upgrade == NULL) if (kv_add(>http_headers, "Connection", "close", 0) == NULL) goto fail; mcmer-open...@tor.at (Marcus MERIGHI), 2021.01.04 (Mon) 12:59 (CET): > One month has passed, this is just a friendly ping... > > Marcus > > mcmer-open...@tor.at (Marcus MERIGHI), 2020.12.04 (Fri) 14:18 (CET): > > This patch wasn't commited and not discussed (publicly). > > > > It lets me use relayd as a front-end to the mattermost-server. > > > > @franz: Thank you! > > > > fr...@bett.ag (Franz Bettag), 2020.03.04 (Wed) 17:52 (CET): > > > After migrating my home setup from nginx reverse proxying to relayd, i > > > noticed my iOS devices having issues connecting through Websockets. > > > After debugging, i noticed that relayd adds the "Connection: close" > > > regardless of upgrade being requested. > > > > > > This issue is also reported on a blog-post using relayd as a Websocket > > > Client. https://deftly.net/posts/2019-10-23-websockets-with-relayd.html > > > > > > This resulted in the response having two Connection Headers, one > > > "Connection: upgrade" and one "Connection: close", which iOS strict > > > implementation does not allow. > > > > > > I have fixed the if condition that leads to this issue. > > > > > > The fix has been tested with Apple iOS 13 and the problem can be > > > observed using Firefox and just connecting to something Websocket over > > > relayd. Both "Connection:" headers will appear. > > > > > > best regards > > > > > > Franz > > > > > > > > > diff --git usr.sbin/relayd/relay_http.c usr.sbin/relayd/relay_http.c > > > index 960d4c54a..3a6678790 100644 > > > --- usr.sbin/relayd/relay_http.c > > > +++ usr.sbin/relayd/relay_http.c > > > @@ -524,9 +524,11 @@ relay_read_http(struct bufferevent *bev, void *arg) > > > > > > /* > > >* Ask the server to close the connection after this request > > > - * since we don't read any further request headers. > > > + * since we don't read any further request headers, unless > > > + * an Upgrade is requested, in which case we do NOT want to add > > > + * this header. > > >*/ > > > - if (cre->toread == TOREAD_UNLIMITED) > > > + if (cre->toread == TOREAD_UNLIMITED && upgrade == NULL) > > > if (kv_add(>http_headers, "Connection", > > > "close", 0) == NULL) > > > goto fail; Index: relay_http.c === RCS file: /cvs/src/usr.sbin/relayd/relay_http.c,v retrieving revision 1.80 diff -u -p -u -r1.80 relay_http.c --- relay_http.c9 Jan 2021 08:53:58 - 1.80 +++ relay_http.c14 Feb 2021 11:03:12 - @@ -527,7 +527,7 @@ relay_read_http(struct bufferevent *bev, * Ask the server to close the connection after this request * since we don't read any further request headers. */ - if (cre->toread == TOREAD_UNLIMITED) + if (cre->toread == TOREAD_UNLIMITED && upgrade == NULL) if (kv_add(>http_headers, "Connection", "close", 0) == NULL) goto fail;
