i386: i8254_initclocks: set IPL_MPSAFE for clock, rtc IRQs
pOn amd64 we lie about the interrupts established during
i8254_initclocks(). We claim they are MP-safe in order to mollify a
KASSERT in intr_establish() and continue booting.
See amd64/isa/clock.c:
279 void
280 i8254_initclocks(void)
281 {
282 i8254_inittimecounter();/* hook the interrupt-based
i8254 tc */
283
284 stathz = 128;
285 profhz = 1024; /* XXX does not divide into 1 billion */
286 clockintr_init(0);
287
288 clockintr_cpu_init(NULL);
289
290 /*
291 * While the clock interrupt handler isn't really MPSAFE, the
292 * i8254 can't really be used as a clock on a true MP system.
293 */
294 isa_intr_establish(NULL, 0, IST_PULSE, IPL_CLOCK | IPL_MPSAFE,
295 clockintr, 0, "clock");
296 isa_intr_establish(NULL, 8, IST_PULSE, IPL_STATCLOCK |
IPL_MPSAFE,
297 rtcintr, 0, "rtc");
and amd64/amd64/intr.c:
332 void *
333 intr_establish(int legacy_irq, struct pic *pic, int pin, int type, int
level,
334 struct cpu_info *ci, int (*handler)(void *), void *arg, const char
*what)
335 {
336 struct intrhand **p, *q, *ih;
337 int slot, error, idt_vec;
338 struct intrsource *source;
339 struct intrstub *stubp;
340 int flags;
341
342 #ifdef DIAGNOSTIC
343 if (legacy_irq != -1 && (legacy_irq < 0 || legacy_irq > 15))
344 panic("intr_establish: bad legacy IRQ value");
345
346 if (legacy_irq == -1 && pic == _pic)
347 panic("intr_establish: non-legacy IRQ on i8259");
348 #endif
349
350 flags = level & IPL_MPSAFE;
351 level &= ~IPL_MPSAFE;
352
353 KASSERT(level <= IPL_TTY || level >= IPL_CLOCK || flags &
IPL_MPSAFE);
Can we do the same on i386? I'm trying to test the i8254 path on
modern hardware and I'm tripping the equivalent KASSERT in
apic_intr_establish().
See i386/i386/ioapic.c:
661 void *
662 apic_intr_establish(int irq, int type, int level, int (*ih_fun)(void *),
663 void *ih_arg, const char *ih_what)
664 {
665 unsigned int ioapic = APIC_IRQ_APIC(irq);
666 unsigned int intr = APIC_IRQ_PIN(irq);
667 struct ioapic_softc *sc = ioapic_find(ioapic);
668 struct ioapic_pin *pin;
669 struct intrhand **p, *q, *ih;
670 extern int cold;
671 int minlevel, maxlevel;
672 extern void intr_calculatemasks(void); /* XXX */
673 int flags;
674
675 flags = level & IPL_MPSAFE;
676 level &= ~IPL_MPSAFE;
677
678 KASSERT(level <= IPL_TTY || flags & IPL_MPSAFE);
The patch below lets me test the i8254 clockintr path on modern
hardware in 32-bit mode without needing to rototill the GENERIC
config to delete all the things that implicitly depend upon the
ioapic.
I don't think lying in this case is harmful. We can only get to
i8254_initclocks() if we have no local APIC, or if
lapic_calibrate_timer() fails.
ok?
Index: clock.c
===
RCS file: /cvs/src/sys/arch/i386/isa/clock.c,v
retrieving revision 1.65
diff -u -p -r1.65 clock.c
--- clock.c 25 Jul 2023 18:16:20 - 1.65
+++ clock.c 21 Aug 2023 03:26:39 -
@@ -431,9 +431,9 @@ i8254_initclocks(void)
clockintr_cpu_init(NULL);
/* When using i8254 for clock, we also use the rtc for profclock */
- (void)isa_intr_establish(NULL, 0, IST_PULSE, IPL_CLOCK,
+ (void)isa_intr_establish(NULL, 0, IST_PULSE, IPL_CLOCK | IPL_MPSAFE,
clockintr, 0, "clock");
- (void)isa_intr_establish(NULL, 8, IST_PULSE, IPL_STATCLOCK,
+ (void)isa_intr_establish(NULL, 8, IST_PULSE, IPL_STATCLOCK | IPL_MPSAFE,
rtcintr, 0, "rtc");
rtcstart(); /* start the mc146818 clock */
Re: Have sysupgrade run fw_update -vv
On Sat, Aug 19, 2023 at 03:11:46PM -0700, Andrew Hewus Fresh wrote: > On Sun, Aug 13, 2023 at 04:42:49PM -0600, Theo de Raadt wrote: > > Stuart Henderson wrote: > > > > > On 2023/08/13 11:44, Andrew Hewus Fresh wrote: > > > > My laptop doesn't have the fastest wifi and sysupgrade already uses a > > > > progress bar to show what it's doing, so I'd really like to provide more > > > > feedback on what it is doing: > > > > > > Does a single -v give enough feedback? > > > > As shown below, -vv is ridiculously verbose. > > > > I think -v is also too verbose. > > That makes sense to me. Here's a fairly intrusive patch that in the > normal case prints the status line "as we go" so you can see that it is > doing something. Errors from ftp are not super friendly, although I'm > not entirely sure what it should do yet, so right now I do nothing. Some additional detail on this. One example is if the ftp process fails to download a file, for example it is killed or times out or something which results in (in the case of a SIGTERM): $ doas ksh ./fw_update.sh fw_update.sh: add intel /Terminated Terminated ,inteldrm,iwm,uvideo,vmm; update none Cannot fetch http://firmware.openbsd.org/firmware/snapshots/intel-firmware-20230808v0.tgz Would it be an improvement to provide more detail? $ doas ksh ./fw_update.sh fw_update.sh: add intel /Terminated Terminated (intel-firmware-20230808v0.tgz download failed),inteldrm,iwm,uvideo,vmm; update none Cannot fetch http://firmware.openbsd.org/firmware/snapshots/intel-firmware-20230808v0.tgz Since I don't know what, if anything, was printed by the failure, it's hard to know how much would be helpful. > In the normal and single -v case, it also adds a spinner while it is > downloading if there STDOUT is a tty. > > We now go in two phases for install/update where we first detect what > needs to be done and then do it so we can separate install from > download. > > In any case, I think this is ready for wider testing. > > Comments, suggestions, OK? > -- andrew Full-time system administration is a delicate balance between proactiveness and laziness. -- jhorwitz from use.perl.org
Add Intel Optane P1600X to pcidevs
Hi, Intel Optane P1600X Series SSDs are not yet identified in CURRENT (e.g., https://www.intel.com/content/www/us/en/products/sku/211867/intel-optane-ssd-p1600x-series-118gb-m-2-80mm-pcie-3-0-x4-3d-xpoint/specifications.html ). The following patch adds a suitable description (tested with 118GB model). Index: src/sys/dev/pci/pcidevs === RCS file: /cvs/src/sys/dev/pci/pcidevs,v retrieving revision 1.2045 diff -u -p -r1.2045 pcidevs --- src/sys/dev/pci/pcidevs 9 Aug 2023 21:27:47 - 1.2045 +++ src/sys/dev/pci/pcidevs 20 Aug 2023 11:53:01 - @@ -4566,6 +4566,7 @@ product INTEL WL_8265_1 0x24fd Dual Ban product INTEL 82820_HB 0x2501 82820 Host product INTEL 82820_AGP0x250f 82820 AGP product INTEL OPTANE 0x2522 Optane +product INTEL P1600X 0x2525 P1600X product INTEL WL_9260_10x2526 Dual Band Wireless-AC 9260 product INTEL 82850_HB 0x2530 82850 Host product INTEL 82860_HB 0x2531 82860 Host
Re: Virtio fix for testing
Am 13.08.23 um 17:38 schrieb Tobias Heider: On Sun, Aug 13, 2023 at 08:33:54AM -0400, Andrew Cagney wrote: Hi Andrew, can you share the qemu cmd you are using in your tests? I'd like to see if I can reproduce this. Here's pretty much everything. Thanks for looking at it. Thank you, I managed to reproduce your crash. I am not yet sure what the exact problem is but you could try using install73.img > instead of install73.iso. It looks like only the iso triggers the bug for me. -cdrom makes qemu add an ATA cdrom drive. This issue has nothing to do with the virtio scsi issue / fix from May. The "wdc_atapi_start" here >> --:-- ETAwdc_atapi_start: not ready, st = 50 also points to the problem being related to ATA. You could try something like -device virtio-scsi-pci,id=scsi -drive file=install73.iso,format=raw,id=cdinst,if=none -device scsi-cd,drive=cdinst That depends on your seabios having support for virtio cdroms. Not sure if that is the default by now. Or maybe try a SATA cdrom, but you would need to figure out the qemu options for that yourself. Oh, and the exact qemu version you used may be interesting for people trying to debug this. Cheers, Stefan virt-install \ --connect=qemu:///system \ --check=path_in_use=off \ --graphics=none \ --virt-type=kvm \ --noreboot \ --console=pty,target_type=serial \ --cpu=host-passthrough \ --network=network:swandefault,model=virtio \ --rng=type=random,device=/dev/random \ --security=type=static,model=dac,label='1000:107',relabel=yes \ --vcpus=1 \ --memory=2048 \ --name=w.openbsd-base \ --os-variant=openbsd7.3 \ --disk=path=/home/libreswan/pool/w.openbsd-base.qcow2,size=10,bus=virtio,format=qcow2 \ --filesystem=target=pool,type=mount,accessmode=squash,source=/home/libreswan/pool \ --cdrom=/home/libreswan/pool/w.openbsd-base.iso base.conf which gets added to the iso looks like: #install.conf file for OpenBSD Terminal type? = com0 System hostname = openbsd Which network interface do you wish to configure? = vio0 IPv4 address for = dhcp DNS Domain name = testing.libreswan.org Password for root account? = $2a$12$YZ8bMn19IHPQpBoD6Xf/re/4pp2kbJtVkIl/Mc4G3WA96qyG7/6qW Start sshd(8) by default = yes Start ntpd(8) by default? = no NTP server? (hostname or 'default') = default Do you expect to run the X Window System? = no Do you want the X Window System to be started by xdm(1)? = no Which speed should com0 use? (or 'done') = 19200 What timezone are you in? = EST Change the default console to com0? = yes Setup a user? = no Allow root ssh login = yes Use (W)hole disk or (E)dit the MBR? = W URL to autopartitioning template for disklabel? = file:/base.disk Which disk is the root disk? = sd0 Use DUIDs rather than device names in fstab? = yes Which disk do you wish to initialize? = done Set name(s)? = all Location of sets? = cd0 oPathname to the sets = 7.1/amd64 Directory does not contain SHA256.sig. Continue without verification? = yes this is the console log, part way through pexpect feeds the VM commands to start the installer: cannot open cd0a:/etc/random.seed: No such file or directory booting cd0a:/7.3/amd64/bsd.rd: 3973828+1655808+3882568+0+708608 [109+444720+297256]=0xa76648 entry point at 0x81001000 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2023 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 7.3-current (RAMDISK_CD) #1262: Sat Aug 12 11:54:24 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 2130542592 (2031MB) avail mem = 2062016512 (1966MB) random: good seed from bootblocks mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf59a0 (9 entries) bios0: vendor SeaBIOS version "1.16.2-1.fc38" date 04/01/2014 bios0: QEMU Standard PC (i440FX + PIIX, 1996) acpi0 at bios0: ACPI 1.0 acpi0: tables DSDT FACP APIC WAET acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Ryzen 9 3950X 16-Core Processor, 3500.43 MHz, 17-71-00 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,CPCTR,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,STIBP,SSBD,IBPB,STIBP,SSBD,VIRTSSBD,XSAVEOPT,XSAVEC,XGETBV1 cpu0: 64KB 64b/line 2-way D-cache, 64KB 64b/line 2-way I-cache cpu0: 512KB 64b/line 16-way L2 cache cpu0: apic clock running at 1000MHz ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) "ACPI0006" at acpi0 not configured acpipci0 at acpi0 PCI0 "PNP0A06" at acpi0 not configured "PNP0A06" at acpi0 not configured "PNP0A06" at acpi0 not configured "QEMU0002" at acpi0 not configured com0 at acpi0 COM1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte
Re: sshd: reduce preauth log verbosity
On Fri, 18 Aug 2023, Tobias Heider wrote:
> Hi,
>
> I was looking at my authlog today and as expected on a server exposed on the
> public internet it is filled with random scanners and brute force attacks.
> One thing I noticed is that there is a lot of information we log multiple
> times for a each failed connection.
>
> Some examples below:
>
> sshd[6216]: error: kex_exchange_identification: banner line contains invalid
> characters
> sshd[6216]: banner exchange: Connection from xx.97.73.149 port 64744: invalid
> format
> sshd[68416]: error: kex_exchange_identification: banner line contains invalid
> characters
> sshd[68416]: banner exchange: Connection from xx.97.73.149 port 63955:
> invalid format
>
> There are a few more parsing errors like this that result in a print of the
> exact
> issue error followed by 'goto invalid' which causes the more general "invalid
> format"
> message. I think "invalid format" is enough information in most cases.
>
> sshd[50752]: error: kex_exchange_identification: Connection closed by remote
> host
> sshd[50752]: Connection closed by xx.94.81.243 port 61000
>
> Same as above, the kex_exchange_identification doesn't really add anything.
>
> sshd[51579]: Invalid user tom from xx.134.191.142 port 35480
> sshd[51579]: Received disconnect from xx.134.191.142 port 35480:11: Bye Bye
> [preauth]
> sshd[51579]: Disconnected from invalid user tom xx.134.191.142 port 35480
> [preauth]
> sshd[94857]: Invalid user long from xx.97.173.1 port 51140
> sshd[94857]: Received disconnect from xx.97.173.1 port 51140:11: Bye Bye
> [preauth]
> sshd[94857]: Disconnected from invalid user long xx.97.173.1 port 51140
> [preauth]
>
> Here the "Disconnected" line contains all the info from "Invalid user" line.
> Those invalid user messages make up the largest part of my log file,
> so deduplicating them makes a huge difference.
>
> Below is a diff to make some of those log to debug if the same information
> is also logged elsewhere.
> Is there some general interest in diffs to clean this up a bit?
ok to the kex.c ones, but no to the auth.c one. There are other exit
paths that sshd can take that might lose the "Invalid user" message and
then that information would be lost.
> Index: auth.c
> ===
> RCS file: /cvs/src/usr.bin/ssh/auth.c,v
> retrieving revision 1.160
> diff -u -p -r1.160 auth.c
> --- auth.c5 Mar 2023 05:34:09 - 1.160
> +++ auth.c18 Aug 2023 14:22:55 -
> @@ -431,7 +431,7 @@ getpwnamallow(struct ssh *ssh, const cha
>
> pw = getpwnam(user);
> if (pw == NULL) {
> - logit("Invalid user %.100s from %.100s port %d",
> + debug("Invalid user %.100s from %.100s port %d",
> user, ssh_remote_ipaddr(ssh), ssh_remote_port(ssh));
> return (NULL);
> }
> Index: kex.c
> ===
> RCS file: /cvs/src/usr.bin/ssh/kex.c,v
> retrieving revision 1.179
> diff -u -p -r1.179 kex.c
> --- kex.c 18 Aug 2023 01:37:41 - 1.179
> +++ kex.c 18 Aug 2023 14:22:55 -
> @@ -1336,7 +1336,7 @@ kex_exchange_identification(struct ssh *
> len = atomicio(read, ssh_packet_get_connection_in(ssh),
> , 1);
> if (len != 1 && errno == EPIPE) {
> - error_f("Connection closed by remote host");
> + debug_f("Connection closed by remote host");
> r = SSH_ERR_CONN_CLOSED;
> goto out;
> } else if (len != 1) {
> @@ -1352,7 +1352,7 @@ kex_exchange_identification(struct ssh *
> if (c == '\n')
> break;
> if (c == '\0' || expect_nl) {
> - error_f("banner line contains invalid "
> + debug_f("banner line contains invalid "
> "characters");
> goto invalid;
> }
> @@ -1362,7 +1362,7 @@ kex_exchange_identification(struct ssh *
> goto out;
> }
> if (sshbuf_len(peer_version) > SSH_MAX_BANNER_LEN) {
> - error_f("banner line too long");
> + debug_f("banner line too long");
> goto invalid;
> }
> }
> @@ -1378,7 +1378,7 @@ kex_exchange_identification(struct ssh *
> }
> /* Do not accept lines before the SSH ident from a client */
> if (ssh->kex->server) {
> - error_f("client sent invalid protocol identifier "
> + debug_f("client sent invalid protocol identifier "
> "\"%.256s\"",
