CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: dr...@cvs.openbsd.org 2021/05/19 22:22:33 Modified files: sys/arch/riscv64/riscv64: cpuswitch.S exception.S fpu.c machdep.c process_machdep.c sig_machdep.c syscall.c trap.c vm_machdep.c Log message: Significant overhaul of the floating point save/restore code. At this point the mechanism should closely resemble the powerpc64 save/restore points with one difference. (reload avoidance) The previous 'aggressive' fpu save code that was (mostly) implemented before and is present on arm32 and arm64. There is one piece from that other design that remains, if pcb->pcb_fpcpu == ci && ci->ci_fpuproc == p after sleep, this will automatically re-activate the FPU state without needing to reload it. To enable this, the pointer pair is not changed on FPU context save to indicate that the CPU still holds the valid content as long as both of those pointers are pointing to each other. Note that if another core steals the FPU conxtex (when we get to SMP) the pcb->pcb_fpcpu will be another cpu, and from that it will know to reload the FPU context. Also optimistically enabling this only makes sense on riscv64 because there is the notion of FPU on and clean. Other implimentations would need to 'fault on' the FPU enable, but could avoid the FPU context load if no other processor has run this FPU context and no other process has use FPU on this core. ok kettenis@ deraadt@ Prior to a couple of fixes.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: j...@cvs.openbsd.org2021/05/19 18:58:53 Modified files: share/man/man4/man4.powerpc64: intro.4 Log message: arm64 -> powerpc64
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: j...@cvs.openbsd.org2021/05/19 18:55:15 Modified files: share/man/man4 : com.4 pci.4 Log message: mention riscv64 config lines
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: j...@cvs.openbsd.org2021/05/19 18:46:34 Modified files: usr.sbin/pcidump: Makefile Log message: build pcidump on riscv64
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: j...@cvs.openbsd.org2021/05/19 17:29:42 Modified files: sys/arch/riscv64/conf: RAMDISK Log message: add pci to RAMDISK as well
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: dr...@cvs.openbsd.org 2021/05/19 17:18:40 Modified files: gnu/usr.bin/clang: Makefile.inc Log message: Revert hack to build clang with -static on riscv64. This 'requirement' was due to a bug in dtors which has been corrected. reminded by jsg@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: dr...@cvs.openbsd.org 2021/05/19 17:15:21 Modified files: distrib/riscv64/ramdisk: Makefile Log message: Correct the library path for native build of ramdisks.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: bl...@cvs.openbsd.org 2021/05/19 16:03:35 Modified files: sys/net80211 : Tag: OPENBSD_6_8 ieee80211_input.c Log message: Drop fragmented 802.11 frames. Fragmented frames were never of any practical use to us anyway, given that our net80211 stack does not (yet?) re-assemble them. Counter-measure against attacks where an arbitrary packet is injected in a fragment with attacker-controlled content (via an AP which supports fragments). See https://papers.mathyvanhoef.com/usenix2021.pdf Section 6.8 "Treating fragments as full frames" ok mpi@ Prevent frame injection via forged 802.11n A-MSDUs. This mitigates an attack where a single 802.11 frame is interpreted as an A-MSDU because of a forged AMSDU-present bit in the 802.11 QoS frame header. See https://papers.mathyvanhoef.com/usenix2021.pdf section 3.2. MAC address validation is added as an additional measure to prevent hostap clients from sending A-MSDU subframes with a spoofed source address. An earlier version of this patch was reviewed by Mathy Vanhoef, who spotted a bug in my original attempt at preventing spoofed addresses. ok mpi@ Ignore trailing data in A-MSDU frame buffers if it is smaller than the Ethernet header size. Avoids spurious "input packet decapsulations failed" errors in 'netstat -W' with A-MSDU enabled (currently disabled in-tree). Problem observed and fix verified on iwm(4) 8260 by me and 7260 by tobhe. ok phessler@ tobhe@ from stsp@ this is errata/6.8/021_net80211.patch.sig
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: bl...@cvs.openbsd.org 2021/05/19 15:57:31 Modified files: sys/net80211 : Tag: OPENBSD_6_9 ieee80211_input.c Log message: Drop fragmented 802.11 frames. Fragmented frames were never of any practical use to us anyway, given that our net80211 stack does not (yet?) re-assemble them. Counter-measure against attacks where an arbitrary packet is injected in a fragment with attacker-controlled content (via an AP which supports fragments). See https://papers.mathyvanhoef.com/usenix2021.pdf Section 6.8 "Treating fragments as full frames" ok mpi@ Prevent frame injection via forged 802.11n A-MSDUs. This mitigates an attack where a single 802.11 frame is interpreted as an A-MSDU because of a forged AMSDU-present bit in the 802.11 QoS frame header. See https://papers.mathyvanhoef.com/usenix2021.pdf section 3.2. MAC address validation is added as an additional measure to prevent hostap clients from sending A-MSDU subframes with a spoofed source address. An earlier version of this patch was reviewed by Mathy Vanhoef, who spotted a bug in my original attempt at preventing spoofed addresses. ok mpi@ from stsp@ this is errata/6.9/004_net80211.patch.sig
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: k...@cvs.openbsd.org2021/05/19 15:49:07 Modified files: sbin/fdisk : gpt.c gpt.h Log message: No need to pass the location of the partition table to GPT_get_partition_table() since the global 'gh' knows where it is. Fixes a couple of missing letoh64() calls by eliminating the need for them.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: kette...@cvs.openbsd.org2021/05/19 15:23:20 Modified files: sys/arch/riscv64/riscv64: machdep.c Log message: Get rid of the do-nothing cache setup code. The RISC-V architecture has no architecturally defined caches (yet) so there is nothing to set up here. Gets rid of some more useless XXX.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: dera...@cvs.openbsd.org 2021/05/19 14:37:17 Modified files: sys/arch/riscv64/riscv64: conf.c Log message: delete useless XXX
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: dera...@cvs.openbsd.org 2021/05/19 14:35:02 Modified files: sys/arch/riscv64/riscv64: mem.c Log message: delete useless XXX
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: kette...@cvs.openbsd.org2021/05/19 14:10:38 Modified files: sys/dev/fdt: pciecam.c Log message: Only advertise MSI support if there is an MSI controller of some sort. ok patrick@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: flor...@cvs.openbsd.org 2021/05/19 13:42:53 Modified files: usr.sbin/httpd : server_fcgi.c Log message: When we disable "Transfer-Encoding: chunked" in the fastcgi backend because we are going to send an empty body we have to provide "Content-Length: 0" otherwise some browsers (Firefox, Safari) just hang until httpd(8) closes the connection. Problem reported by Matthias Pressfreund, debugged with weerd@ who pointed out that the problem is browser dependent. OK tracey
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: kette...@cvs.openbsd.org2021/05/19 13:32:25 Modified files: sys/arch/riscv64/conf: GENERIC files.riscv64 Added files: sys/arch/riscv64/dev: pci_machdep.c sys/arch/riscv64/include: pci_machdep.h Log message: Add PCI support. ok deraadt@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: bl...@cvs.openbsd.org 2021/05/19 12:42:59 Modified files: sys/arch/powerpc64/include: vmparam.h Log message: Double the maximum data size limit on powerpc64. Now it is 32 GB and the same as amd64. The machines have large amounts of memory. discussed with kettenis@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: kette...@cvs.openbsd.org2021/05/19 12:10:45 Modified files: sys/kern : tty.c Log message: In ttyinfo() check that ps_vmspace isn't NULL before calculating the resident set size. This replicates what the sysctl code does and fixes a kernel crash reported by robert@ ok deraadt@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: patr...@cvs.openbsd.org 2021/05/19 11:46:36 Modified files: sys/arch/amd64/amd64: pmap.c Log message: Disable global mappings when using PCID. Page table mappings are frequently created and destroyed in the kernel address space. Traditionally, these mappings have been marked as "global" mappings which means that a TLB flush via %cr3 load does not invalidate them. This is ok as these mappings are the same for all processes. With the advent of MELTDOWN, global mappings were disabled for CPUs that are affected by rogue data cache load (RDCL aka MELTDOWN). To compensate for this we started using PCID and the kernel got its own process context identifier. Thus the hardware is allowed to cache kernel mappings again. However, a CPU that supports PCID but is _not_ affected by MELTDOWN (i.e. ARCH_CAPABILTIES.RDCL_NO=1) will now use both: global PTE mappings and PCID. This is a problem if range based TLB invalidations are used to update/ flush cached TLBs after a change to the kernel page tables. The reason is that the invpcid instruction (function 0) that is used to remove the cached TLBs will not remove global mappings. In the non-PCID case invlpg is used instead which does remove global mappings. In the MELTDOWN case, global mappings are not used at all. The solution is to not use global mappings if PCID is active, as the latter should already by enough to let the hardware cache kernel address translations across address space switches and the global flag is not required. >From Christian Ehrhardt ok bluhm@ guenther@ mlarkin@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: kette...@cvs.openbsd.org2021/05/19 11:39:50 Modified files: sys/arch/riscv64/dev: plic.c sys/arch/riscv64/include: fdt.h intr.h sys/arch/riscv64/riscv64: intr.c Log message: Bring riscv64 intr.c code in sync with arm64. This brings us: - MSI support - Interfaces to route interrupts to specific CPUs - Proper interrupt barriers - s/riscv_intr_handler/machine_intr_handler/ ok mlarkin@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: dera...@cvs.openbsd.org 2021/05/19 11:25:10 Modified files: distrib/special: Makefile Log message: enter new dirs
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: dera...@cvs.openbsd.org 2021/05/19 11:22:58 Modified files: distrib/special/resolvd: Makefile Log message: correct .PATH
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: dera...@cvs.openbsd.org 2021/05/19 11:16:51 Added files: distrib/special/dhcpleased: Makefile distrib/special/resolvd: Makefile Log message: resolvd and dhcpleased if ramdisks need them
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: dera...@cvs.openbsd.org 2021/05/19 11:16:12 src/distrib/special/dhcpleased Update of /cvs/src/distrib/special/dhcpleased In directory cvs.openbsd.org:/tmp/cvs-serv98654/dhcpleased Log Message: Directory /cvs/src/distrib/special/dhcpleased added to the repository
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: dera...@cvs.openbsd.org 2021/05/19 11:16:12 src/distrib/special/resolvd Update of /cvs/src/distrib/special/resolvd In directory cvs.openbsd.org:/tmp/cvs-serv98654/resolvd Log Message: Directory /cvs/src/distrib/special/resolvd added to the repository
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: dera...@cvs.openbsd.org 2021/05/19 10:57:04 Modified files: etc/etc.armv7 : disktab sys/arch/armv7/conf: RAMDISK Log message: Please sir, I want some more (ramdisk miniroot space)
CVS: cvs.openbsd.org: www
CVSROOT:/cvs Module name:www Changes by: j...@cvs.openbsd.org2021/05/19 06:04:32 Modified files: rpki-client: index.html Log message: Point to 7.1 release
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: inogu...@cvs.openbsd.org2021/05/19 04:12:56 Modified files: lib/libcrypto/objects: obj_xref.txt Log message: Adjust libcrypto obj_xref.txt to obj_xref.h To generate current obj_xref.h, third item of lines id_tc26_signwithdigest_gost3410_2012_256/512 should be id_GostR3410_2001. obj_xref.txt r1.2 and obj_xref.h r1.3 were committed at the same time, and these third item were coded different value each other. This adjusts obj_xref.txt to current obj_xref.h. ok tb@
