Re: httpd rewrite and REQUEST_URI value
Hi Scott. If you or your framework uses REQUEST_URI you don't need request rewrite feature. Using REQUEST_URI and request rewrite feature are two oposite solutions for the same problem. To mimic nginx's try_files do something like this: location match "/hello/.*" { root "/index.php" } It is not obvious from man page but file can act as document root :) Then in that file, index.php in this case, you can route requests by parsing $_SERVER['REQUEST_URI'] what your framework probably does. Ve.
Re: How to copy n bytes from stdin to stdout?
On Thu, 21 Jun 2018 00:56:04 +0200 Tomasz Rola wrote: > On Thu, Jun 21, 2018 at 12:44:14AM +0200, Tomasz Rola wrote: > [...] > > => (591 60): cat nread > > #!/bin/sh > > > > # nread n - read up to n bytes from stdio, put them on to stdout > > > > N=$1 > > > > dd bs=512 count=$((N / 512)) iflag=fullblock 2>/dev/null > > dd bs=1 count=$((N % 512)) iflag=fullblock 2>/dev/null > > Craps. I have consulted OpenBSD's manpage for dd and there is no > mention of iflag. So this will not work on OpenBSD. I will have to > rethink this, sorry. > Untested... int main(int argc, char* argv[]){ long l = atod(argv[1]); while(l--){ if (c = getc(STDIN) != EOF) putc(c, STDOUT); else break; } return 0; } I haven't tested it so it might not be exactly right, and of course error handling would need to be added, but you know what I mean. IIRC getc() and putc() are very well buffered so it will be fast. In my youth I wrote similar functions using low level read() and write() and doing my own buffering, and those things were *really* fast, but I think that's overkill in this century. As far as finding command line tools that do it, if that's becoming hard to do, why not just write a 10 line program? -- SteveT Steve Litt June 2018 featured book: Twenty Eight Tales of Troubleshooting http://www.troubleshooters.com/28
Re: VMs not booting (was: How to build with VMM_DEBUG)
On Sun, Jun 24, 2018 at 01:41:47AM -0500, Ax0n wrote: > On Sat, Jun 23, 2018 at 3:54 PM, Ax0n wrote: > > > > > FWIW, that patch didn't apply cleanly to a fresh pull of the tree from > > GitHub. I know it's not OFFICIALLY -CURRENT for realsies but it's what I > > have been using on this laptop for months. It sounds like it was probably > > patched against -STABLE? I didn't read the entire thread on bugs@. I have > > tried with 3 daily snapshots in a row and I'm having the same problem. I > > haven't actually fired up vmm in a few weeks, so I'm not sure exactly when > > it quit working. I'm re-building with VMM_DEBUG first. > > > > Mike, I'll send all relevant info (dmesg, vmd -dvvv, vm.conf) to bugs@ > > once I have it, unless this sounds like an ongoing thing you probably have > > on your radar already. I'm not in a huge rush, so I can wait a bit if you > > think you have something that'll make it into -CURRENT in a while. > > > > Following up and cc bugs@ I built the system with VMM_DEBUG enabled. > This does not look like the output from a kernel with VMM_DEBUG enabled. You'll be seeing all sorts of debug output to dmesg as the VM starts, runs, and ultimately in your case aborts. -ml > >Synopsis: vmm(4) VMs fail to start: ioctl failed: Invalid argument > >Category: amd64 > >Environment: > System : OpenBSD 6.3 > Details : OpenBSD 6.3-current (GENERIC.MP) #49: Sat Jun 23 > 09:32:05 MDT 2018 > dera...@amd64.openbsd.org: > /usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > >Description: > VMs fail to boot. > [axon@transient ~]$ doas vmd -dvvv > startup > /etc/vm.conf:4: switch "local" registered > /etc/vm.conf:8: switch "internal" registered > /etc/vm.conf:12: switch "wired" registered > vm_register: registering vm 1 > /etc/vm.conf:28: vm "OBSD-Stable.vm" registered (disabled) > vm_register: registering vm 2 > /etc/vm.conf:41: vm "OBSD-Stable-alt.vm" registered (disabled) > vm_register: registering vm 3 > /etc/vm.conf:53: vm "OBSDSnap64.vm" registered (disabled) > config_setconfig: setting config > vm_priv_brconfig: interface bridge0 description switch1-local > vm_priv_brconfig: interface bridge1 description switch2-internal > vm_priv_brconfig: interface bridge0 description switch3-wired > vmd_configure: not creating vm OBSD-Stable.vm (disabled) > vmd_configure: not creating vm OBSD-Stable-alt.vm (disabled) > vmd_configure: not creating vm OBSDSnap64.vm (disabled) > config_getconfig: priv retrieving config > config_getconfig: control retrieving config > config_getconfig: vmm retrieving config > vm_opentty: vm OBSDSnap64.vm tty /dev/ttyp3 uid 1000 gid 4 mode 620 > vm_register: registering vm 3 > vm_priv_ifconfig: interface tap0 description vm3-if0-OBSDSnap64.vm > vm_priv_ifconfig: switch "local" interface bridge0 add tap0 > OBSDSnap64.vm: started vm 3 successfully, tty /dev/ttyp3 > loadfile_bios: loaded BIOS image > run_vm: initializing hardware for vm OBSDSnap64.vm > pic_set_elcr: setting level triggered mode for irq 3 > pic_set_elcr: setting level triggered mode for irq 5 > pic_set_elcr: setting level triggered mode for irq 6 > virtio_init: vm "OBSDSnap64.vm" vio0 lladdr fe:e1:ba:d0:eb:ac > pic_set_elcr: setting level triggered mode for irq 7 > run_vm: starting vcpu threads for vm OBSDSnap64.vm > vcpu_reset: resetting vcpu 0 for vm 2 > run_vm: waiting on events for VM OBSDSnap64.vm > vcpu_run_loop: vm 2 / vcpu 0 run ioctl failed: Invalid argument > vmm_sighdlr: handling signal 20 > vmm_sighdlr: attempting to terminate vm 3 > terminate_vm: terminating vmid 2 > vmm_sighdlr: calling vm_remove > vm_remove: removing vm id 3 from running config > vm_remove: calling vm_stop > vm_stop: stopping vm 3 > vmd_dispatch_vmm: handling TERMINATE_EVENT for vm id 3 ret 22 > vmd_dispatch_vmm: about to stop vm id 3 > vm_stop: stopping vm 3 > vm_opentty: vm OBSDSnap64.vm tty /dev/ttyp4 uid 1000 gid 4 mode 620 > vm_register: registering vm 3 > vm_priv_ifconfig: interface tap0 description vm3-if0-OBSDSnap64.vm > vm_priv_ifconfig: switch "local" interface bridge0 add tap0 > OBSDSnap64.vm: started vm 3 successfully, tty /dev/ttyp4 > loadfile_bios: loaded BIOS image > run_vm: initializing hardware for vm OBSDSnap64.vm > pic_set_elcr: setting level triggered mode for irq 3 > pic_set_elcr: setting level triggered mode for irq 5 > pic_set_elcr: setting level triggered mode for irq 6 > virtio_init: vm "OBSDSnap64.vm" vio0 lladdr fe:e1:ba:d0:eb:ac > pic_set_elcr: setting level triggered mode for irq 7 > run_vm: starting vcpu threads for vm OBSDSnap64.vm > vcpu_reset: resetting vcpu 0 for vm 3 > run_vm: waiting on events for VM OBSDSnap64.vm > vcpu_run_loop: vm 3 / vcpu 0 run ioctl failed: Invalid argument > vmm_sighdlr: handling signal 20 > vmm_sighdlr: attempting to terminate vm 3 > terminate_vm: terminating vmid 3 > vmm_sighdlr: calling vm_remove > vm_remove: removing vm id 3 from running config >
Re: How to build with VMM_DEBUG
On Sat, Jun 23, 2018 at 03:54:40PM -0500, Ax0n wrote: > On Sat, Jun 23, 2018 at 6:10 AM, Stefan Sperling wrote: > > > See https://marc.info/?l=openbsd-bugs=152960299009667=2 for > > a patch you could test. > > (raw patch: https://marc.info/?l=openbsd-bugs=152960299009667=raw) > > > > FWIW, that patch didn't apply cleanly to a fresh pull of the tree from > GitHub. I know it's not OFFICIALLY -CURRENT for realsies but it's what I > have been using on this laptop for months. It sounds like it was probably > patched against -STABLE? I didn't read the entire thread on bugs@. I have > tried with 3 daily snapshots in a row and I'm having the same problem. I > haven't actually fired up vmm in a few weeks, so I'm not sure exactly when > it quit working. I'm re-building with VMM_DEBUG first. > > Mike, I'll send all relevant info (dmesg, vmd -dvvv, vm.conf) to bugs@ once > I have it, unless this sounds like an ongoing thing you probably have on > your radar already. I'm not in a huge rush, so I can wait a bit if you > think you have something that'll make it into -CURRENT in a while. -current already has the patch. -stable is what that link above could be applied to. if -current is failing for you, the output of VMM_DEBUG at the time of crash would be useful. -ml
Re: kernel panic while reproducing video with mpv
Hi Visa, On Sun, Jun 24, 2018 at 05:54:15PM +, Visa Hankala wrote: > On Sun, Jun 24, 2018 at 12:37:45PM +0200, Walter Alejandro Iglesias wrote: > > panic: mtx 0x81c86470: locking against myself > > Stopped at db_enter+0x12: popq%r11 > > TIDPIDUID PRFLAGS PFLAGS CPU COMMAND > > 104021 96401 1000 0x3 0x4002 mpv > > *402610 50624 10000x32 00K Xorg > > > > db_enter() at db_enter+0x12 > > panic() at panic+0x138 > > __mtx_enter_try(53b9235709d40154) at __mtx_enter_try+0xb5 > > _mtx_enter(81cf3e60,81a5d6a2,0) at _mtx_enter+0x5a > > printf(c9ef1007dec621e0) at printf+0x70 > > witness_checkorder(2e4447d1b3cbb9af,81c2ac7c,32a,0,81da6d00) > > at > > witness_checkorder+0x943 > > ___mp_lock(8000330cd760,d,7) at ___mp_lock+0x70 > > selwakeup(e80faaebded7c1a2) at selwakeup+0x9c > > ptsstart(8ce5939828d5e23) at ptsstart+0x79 > > tputchar(174549bf676e909c,80afa400) at tputchar+0x85 > > kputchar(75d50501b895e9e4,0,81a5d6a2) at kputchar+0x91 > > kprintf() at kprintf+0xe8 > > printf(c9ef1007dec621e0) at printf+0x85 > > witness_checkorder(2e4447d1b3cba2fe,81af9df1,298,81c8a678,ff > > ff81c8a688) at witness_checkorder+0x943 > > end trace frame: 0x80003302e978, count: 0 > > If the panic happens again, please run the following commands in ddb(4) > and post the output: > > show locks > show all locks The true is it happend twice. On the first one fsck(8) couldn't recover my root file system. After rebooting I couldn't even log in (as user or root) and I had to reinstall. That's way I'm not confident about "voluntary" reproducing the bug. :-) But if it happens again take for sure I'll send you the output of those commands (and per cpu traces). > > It is not clear from the stack trace why the system begins to report > a lock order problem in the first place (the first witness_checkorder > and the printf at the end of the stack trace). > > The panic itself is related to the problem of using other kernel > subsystems from WITNESS. I will try to make a fix that should prevent > the panic in most cases. Thanks! Walter
Re: kernel panic while reproducing video with mpv
On Sun, Jun 24, 2018 at 12:37:45PM +0200, Walter Alejandro Iglesias wrote: > panic: mtx 0x81c86470: locking against myself > Stopped at db_enter+0x12: popq%r11 > TIDPIDUID PRFLAGS PFLAGS CPU COMMAND > 104021 96401 1000 0x3 0x4002 mpv > *402610 50624 10000x32 00K Xorg > > db_enter() at db_enter+0x12 > panic() at panic+0x138 > __mtx_enter_try(53b9235709d40154) at __mtx_enter_try+0xb5 > _mtx_enter(81cf3e60,81a5d6a2,0) at _mtx_enter+0x5a > printf(c9ef1007dec621e0) at printf+0x70 > witness_checkorder(2e4447d1b3cbb9af,81c2ac7c,32a,0,81da6d00) > at > witness_checkorder+0x943 > ___mp_lock(8000330cd760,d,7) at ___mp_lock+0x70 > selwakeup(e80faaebded7c1a2) at selwakeup+0x9c > ptsstart(8ce5939828d5e23) at ptsstart+0x79 > tputchar(174549bf676e909c,80afa400) at tputchar+0x85 > kputchar(75d50501b895e9e4,0,81a5d6a2) at kputchar+0x91 > kprintf() at kprintf+0xe8 > printf(c9ef1007dec621e0) at printf+0x85 > witness_checkorder(2e4447d1b3cba2fe,81af9df1,298,81c8a678,ff > ff81c8a688) at witness_checkorder+0x943 > end trace frame: 0x80003302e978, count: 0 If the panic happens again, please run the following commands in ddb(4) and post the output: show locks show all locks It is not clear from the stack trace why the system begins to report a lock order problem in the first place (the first witness_checkorder and the printf at the end of the stack trace). The panic itself is related to the problem of using other kernel subsystems from WITNESS. I will try to make a fix that should prevent the panic in most cases.
Re: Anybody have any experience with Fujitsu PRIMERGY TX1310 M3?
On 2018-06-24, John Long wrote: > There are two variants of the Fujitsu PRIMERGY TX1310 M3 available here > for about the same price I was paying for the Lenovo m710q. Does > anybody have any comments about these Fujitsu boxes running OpenBSD? > > Also, I remember there was a section in the FAQ about setting up an ftp > server on OpenBSD. I can't find it on the website any more. Is there an > archive and why was it removed? cvsweb.openbsd.org, see www/faq/faq10.html revision 1.212 for the last version before it was removed. But everything you need should be in ftpd(8); if that isn't enough for you, say what you think is missing, maybe it can be improved. Lots of things were removed from the faq, some I felt could have been updated rather than removed, but in this case I think removing it is the right decision, it's very far from being a frequently asked question.
Re: WHere to put certificates for IKEDv2?
On Sun, Jun 24, 2018 at 12:42:15PM +0200, C. L. Martinez wrote: > On Sun, Jun 24, 2018 at 08:43:32AM +, Stuart Henderson wrote: > > On 2018-06-23, C. L. Martinez wrote: > > > Hi all, > > > > > > I am using Easy-RSA to manage my home's CA (using elliptic curve > > > certificates). I have created a certificate for my OpenBSD gw for IKEv2 > > > connections (using strongswan mainly). My question is where do I need to > > > put OpenBSD certs under /etc/iked? > > > > > > I have installed myhost.crt in /etc/iked/pubkeys/fqdn/myhost.crt and > > > myhost.key in /etc/iked/private/myhost.key, but running "iked -dvv" > > > returns me the following error: > > > > The CA cert needs to go in /etc/iked/ca, do you have that? > > > > > > Yes, it is there: -rw-r--r-- 1 root wheel 1326 Jun 24 10:12 > /etc/iked/ca/ca.crt > > But when I start iked using "-dvv" and client tries to connect, I see the following error: sa_stateflags: 0x0024 -> 0x0024 certreq,sa (required 0x ) config_free_proposals: free 0x177c81779900 config_free_proposals: free 0x177c81773080 config_free_proposals: free 0x177c81773400 config_free_proposals: free 0x177c81773580 ca_getreq: found CA /C=ES/ST=Barcelona/ ca_getreq: no valid local certificate found ca_setauth: auth length 256 ikev2_getimsgdata: imsg 20 rspi 0xf4b5f385469a92a5 ispi 0xd7906e9f68bda52b initiator 0 sa valid type 0 data length 0 ikev2_dispatch_cert: cert type NONE length 0, ignored ikev2_getimsgdata: imsg 25 rspi 0xf4b5f385469a92a5 ispi 0xd7906e9f68bda52b initiator 0 sa valid type 1 data length 256 ikev2_dispatch_cert: AUTH type 1 len 256 sa_stateflags: 0x0024 -> 0x002c certreq,auth,sa (required 0x ) But CA cert is loaded: ikev2 "ipseccli" passive esp inet from 0.0.0.0/0 to 0.0.0.0/0 local 0.0.0.0/0 peer 0.0.0.0/0 ikesa enc aes-256,aes-192,aes-128,3des prf hmac-sha2-256,hmac-sha1 auth hmac-sha2-256,hmac-sha1 group modp2048,modp1536,modp1024 childsa enc aes-256,aes-192,aes-128 auth hmac-sha2-256,hmac-sha1 lifetime 10800 bytes 536870912 signature /etc/iked.conf: loaded 2 configuration rules ca_privkey_serialize: type RSA_KEY length 1191 ca_pubkey_serialize: type RSA_KEY length 270 config_new_user: inserting new user testusr ca_privkey_to_method: type RSA_KEY method RSA_SIG config_getpolicy: received policy ca_getkey: received private key type RSA_KEY length 1191 config_getpfkey: received pfkey fd 3 config_getcompile: compilation done config_getsocket: received socket fd 4 config_getsocket: received socket fd 5 config_getsocket: received socket fd 6 config_getsocket: received socket fd 7 config_getmobike: mobike ca_getkey: received public key type RSA_KEY length 270 ca_dispatch_parent: config reset ca_reload: loaded ca file ca.crt ca_reload: /C=ES/ST=Barcelona/ ca_reload: loaded 1 ca certificate ca_reload: local cert type X509_CERT config_getocsp: ocsp_url none ikev2_dispatch_cert: updated local CERTREQ type X509_CERT length 20 ikev2_dispatch_cert: updated local CERTREQ type X509_CERT length 20 But I am thinking that maybe exist some problems: - First, I am using strongswan for Android as a client, do I need to use some specific crypto algorithms on iked side? - Second, maybe is it best option to use EAP user auth instead of certificates? - I am using ECDSA certs, any problem with that? Thanks -- Greetings, C. L. Martinez
Anybody have any experience with Fujitsu PRIMERGY TX1310 M3?
There are two variants of the Fujitsu PRIMERGY TX1310 M3 available here for about the same price I was paying for the Lenovo m710q. Does anybody have any comments about these Fujitsu boxes running OpenBSD? Also, I remember there was a section in the FAQ about setting up an ftp server on OpenBSD. I can't find it on the website any more. Is there an archive and why was it removed? Thanks, /jl
Re: WHere to put certificates for IKEDv2?
On Sun, Jun 24, 2018 at 08:43:32AM +, Stuart Henderson wrote: > On 2018-06-23, C. L. Martinez wrote: > > Hi all, > > > > I am using Easy-RSA to manage my home's CA (using elliptic curve > > certificates). I have created a certificate for my OpenBSD gw for IKEv2 > > connections (using strongswan mainly). My question is where do I need to > > put OpenBSD certs under /etc/iked? > > > > I have installed myhost.crt in /etc/iked/pubkeys/fqdn/myhost.crt and > > myhost.key in /etc/iked/private/myhost.key, but running "iked -dvv" returns > > me the following error: > > The CA cert needs to go in /etc/iked/ca, do you have that? > > Yes, it is there: -rw-r--r-- 1 root wheel 1326 Jun 24 10:12 /etc/iked/ca/ca.crt -- Greetings, C. L. Martinez
kernel panic while reproducing video with mpv
Hello, I had a kernel panic while reproducing a video with mpv. It's my first kernel panic with OpenBSD, so I didn't know how to use ddb(4). Since I'm running my http and smtp server in this machine I cannot entertain myself too much reproducing the panic to get more info. That's why I don't include the per cpu trace and other additonal info as explained in ddb.html, sorry! But, if you need it let me knonw and I'll try my best. Message automatically dumped: === panic: mtx 0x81c86470: locking against myself Stopped at db_enter+0x12: popq%r11 TIDPIDUID PRFLAGS PFLAGS CPU COMMAND 104021 96401 1000 0x3 0x4002 mpv *402610 50624 10000x32 00K Xorg db_enter() at db_enter+0x12 panic() at panic+0x138 __mtx_enter_try(53b9235709d40154) at __mtx_enter_try+0xb5 _mtx_enter(81cf3e60,81a5d6a2,0) at _mtx_enter+0x5a printf(c9ef1007dec621e0) at printf+0x70 witness_checkorder(2e4447d1b3cbb9af,81c2ac7c,32a,0,81da6d00) at witness_checkorder+0x943 ___mp_lock(8000330cd760,d,7) at ___mp_lock+0x70 selwakeup(e80faaebded7c1a2) at selwakeup+0x9c ptsstart(8ce5939828d5e23) at ptsstart+0x79 tputchar(174549bf676e909c,80afa400) at tputchar+0x85 kputchar(75d50501b895e9e4,0,81a5d6a2) at kputchar+0x91 kprintf() at kprintf+0xe8 printf(c9ef1007dec621e0) at printf+0x85 witness_checkorder(2e4447d1b3cba2fe,81af9df1,298,81c8a678,ff ff81c8a688) at witness_checkorder+0x943 end trace frame: 0x80003302e978, count: 0 dmesg: === OpenBSD 6.3-current (GENERIC.MP) #48: Fri Jun 22 14:11:27 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 6210174976 (5922MB) avail mem = 5960577024 (5684MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe0010 (78 entries) bios0: vendor LENOVO version "6IET85WW (1.45 )" date 02/14/2013 bios0: LENOVO 2537EY8 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET ASF! SLIC BOOT SSDT TCPA SSDT S SDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP1(S4) EXP2(S4) EXP3(S4) EXP4 (S4) EXP5(S4) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz, 2793.56 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF LUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,RDTSCP,LONG,LAHF, PERF,ITSC,SENSOR,ARAT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 132MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz, 2793.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF LUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,RDTSCP,LONG,LAHF, PERF,ITSC,SENSOR,ARAT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz, 2793.00 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF LUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,RDTSCP,LONG,LAHF, PERF,ITSC,SENSOR,ARAT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 5 (application processor) cpu3: Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz, 2793.00 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF LUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,RDTSCP,LONG,LAHF, PERF,ITSC,SENSOR,ARAT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 2, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins , remapped to apid 1 acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus -1 (EXP3) acpiprt5 at acpi0: bus 5 (EXP4) acpiprt6 at acpi0: bus 13 (EXP5) acpicpu0 at acpi0: C3(350@245 mwait.3@0x20), C2(500@205 mwait.3@0x10), C1(1000@3 mwait.1), PSS acpicpu1 at
Re: Restoring MIPS32 support as a private project
On 2018-06-22, wrote: > So, I have a mipsel-none-elf32 bare-metal Clang/LLVM cross-compiler (and the > corresponding bare-metal GNU cross-binutils), and the platform-specific code > ('sys/mips/mips' and 'sys/mips/broadcom') from the FreeBSD source tree as a > starting point. > > Are there any other specific considerations to bootstrapping OpenBSD using > the cross-compiler? The target is a router (128MB flash, 128MB RAM), so a > native build is probably impractical, I plan to attach urndis(4) devices to > its lone USB port primarily. > > (Yes, I plan to do the porting myself, just wanted to ask about any build > system specifics. There isn't much in the way of documentation re: porting > OpenBSD to a "new" architecture.) > > Thanks > R > > > > Some starter URLs: https://www.openbsd.org/papers/mips32-openbsd.pdf https://news.ycombinator.com/item?id=10140219 It's up to you of course, but I think looking at some of the arm-based designs showing up in cheap routers would be a better use of time and more likely to be successful tbh. There is minimal infrastructure for cross-builds in OpenBSD (and what is there is only for base, not ports) as they are only really used for initial porting, the aim being to switch to native builds as soon as possible.
Re: hyper-threading...
On 2018-06-22, Dan Campbell wrote: > Just saw the news about you disabling hyper-threading by default on Intel > CPUs for security reasons, which I agree with. It would be nice to be able > to do this on systems that don't have a toggle for it in the BIOS, as it > increases single-threaded performance. So just wondering when your latest > distro will be coming out with this change, as I see your current version > came out in April? I would like to create a Linux live DVD/flash drive that > I could boot to toggle hyper-threading off on Intel systems running Windows, > or to create a dual-boot situation for those who want to use Linux part-time. > It could also be useful for updating processor microcode, which can't be > done under Windows. Thanks, It doesn't exactly _disable_ hyperthreading, it prevents the scheduler from using more than one "smt cpu" per core. It's not something you can do to affect other OS running on the machine. On Linux you should be able to achieve similar results with the script in https://serverfault.com/a/797534 Seems you might be able to do something similar on Windows using a tool called "process lasso". BTW OpenBSD isn't a Linux distro, it is a completely different operating system.
Re: WHere to put certificates for IKEDv2?
On 2018-06-23, C. L. Martinez wrote: > Hi all, > > I am using Easy-RSA to manage my home's CA (using elliptic curve > certificates). I have created a certificate for my OpenBSD gw for IKEv2 > connections (using strongswan mainly). My question is where do I need to put > OpenBSD certs under /etc/iked? > > I have installed myhost.crt in /etc/iked/pubkeys/fqdn/myhost.crt and > myhost.key in /etc/iked/private/myhost.key, but running "iked -dvv" returns > me the following error: The CA cert needs to go in /etc/iked/ca, do you have that? > ikev2_msg_auth: initiator auth data length 960 > ikev2_msg_authverify: method SIG keylen 962 type X509_CERT > _dsa_verify_init: signature scheme 4 selected > ikev2_msg_authverify: authentication successful > sa_state: AUTH_REQUEST -> AUTH_SUCCESS > sa_stateflags: 0x0024 -> 0x0034 certreq,authvalid,sa (required 0x003b > cert,certvalid,auth,authvalid,sa) > ikev2_sa_negotiate: score 0 > ikev2_sa_negotiate: score 10 > ikev2_sa_negotiate: score 0 > ikev2_sa_negotiate: score 4 > sa_stateflags: 0x0034 -> 0x0034 certreq,authvalid,sa (required 0x003b > cert,certvalid,auth,authvalid,sa) > sa_stateok: VALID flags 0x0030, require 0x003b > cert,certvalid,auth,authvalid,sa > sa_state: cannot switch: AUTH_SUCCESS -> VALID > config_free_proposals: free 0xb9bb7e8a80 > config_free_proposals: free 0xb9bb7e8700 > config_free_proposals: free 0xb965e22400 > config_free_proposals: free 0xba238e1e80 > ca_getreq: found CA /C=ES/ST=Barcelona.. > ca_getreq: no valid local certificate found > ca_setauth: auth length 256 > ca_validate_pubkey: unsupported public key type ASN1_DN > ca_validate_cert: /C=ES/... ok > > Do i need to install user certificates also in OpenBSD gw? > > thanks
VMs not booting (was: How to build with VMM_DEBUG)
On Sat, Jun 23, 2018 at 3:54 PM, Ax0n wrote: > > FWIW, that patch didn't apply cleanly to a fresh pull of the tree from > GitHub. I know it's not OFFICIALLY -CURRENT for realsies but it's what I > have been using on this laptop for months. It sounds like it was probably > patched against -STABLE? I didn't read the entire thread on bugs@. I have > tried with 3 daily snapshots in a row and I'm having the same problem. I > haven't actually fired up vmm in a few weeks, so I'm not sure exactly when > it quit working. I'm re-building with VMM_DEBUG first. > > Mike, I'll send all relevant info (dmesg, vmd -dvvv, vm.conf) to bugs@ > once I have it, unless this sounds like an ongoing thing you probably have > on your radar already. I'm not in a huge rush, so I can wait a bit if you > think you have something that'll make it into -CURRENT in a while. > Following up and cc bugs@ I built the system with VMM_DEBUG enabled. >Synopsis: vmm(4) VMs fail to start: ioctl failed: Invalid argument >Category: amd64 >Environment: System : OpenBSD 6.3 Details : OpenBSD 6.3-current (GENERIC.MP) #49: Sat Jun 23 09:32:05 MDT 2018 dera...@amd64.openbsd.org: /usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: VMs fail to boot. [axon@transient ~]$ doas vmd -dvvv startup /etc/vm.conf:4: switch "local" registered /etc/vm.conf:8: switch "internal" registered /etc/vm.conf:12: switch "wired" registered vm_register: registering vm 1 /etc/vm.conf:28: vm "OBSD-Stable.vm" registered (disabled) vm_register: registering vm 2 /etc/vm.conf:41: vm "OBSD-Stable-alt.vm" registered (disabled) vm_register: registering vm 3 /etc/vm.conf:53: vm "OBSDSnap64.vm" registered (disabled) config_setconfig: setting config vm_priv_brconfig: interface bridge0 description switch1-local vm_priv_brconfig: interface bridge1 description switch2-internal vm_priv_brconfig: interface bridge0 description switch3-wired vmd_configure: not creating vm OBSD-Stable.vm (disabled) vmd_configure: not creating vm OBSD-Stable-alt.vm (disabled) vmd_configure: not creating vm OBSDSnap64.vm (disabled) config_getconfig: priv retrieving config config_getconfig: control retrieving config config_getconfig: vmm retrieving config vm_opentty: vm OBSDSnap64.vm tty /dev/ttyp3 uid 1000 gid 4 mode 620 vm_register: registering vm 3 vm_priv_ifconfig: interface tap0 description vm3-if0-OBSDSnap64.vm vm_priv_ifconfig: switch "local" interface bridge0 add tap0 OBSDSnap64.vm: started vm 3 successfully, tty /dev/ttyp3 loadfile_bios: loaded BIOS image run_vm: initializing hardware for vm OBSDSnap64.vm pic_set_elcr: setting level triggered mode for irq 3 pic_set_elcr: setting level triggered mode for irq 5 pic_set_elcr: setting level triggered mode for irq 6 virtio_init: vm "OBSDSnap64.vm" vio0 lladdr fe:e1:ba:d0:eb:ac pic_set_elcr: setting level triggered mode for irq 7 run_vm: starting vcpu threads for vm OBSDSnap64.vm vcpu_reset: resetting vcpu 0 for vm 2 run_vm: waiting on events for VM OBSDSnap64.vm vcpu_run_loop: vm 2 / vcpu 0 run ioctl failed: Invalid argument vmm_sighdlr: handling signal 20 vmm_sighdlr: attempting to terminate vm 3 terminate_vm: terminating vmid 2 vmm_sighdlr: calling vm_remove vm_remove: removing vm id 3 from running config vm_remove: calling vm_stop vm_stop: stopping vm 3 vmd_dispatch_vmm: handling TERMINATE_EVENT for vm id 3 ret 22 vmd_dispatch_vmm: about to stop vm id 3 vm_stop: stopping vm 3 vm_opentty: vm OBSDSnap64.vm tty /dev/ttyp4 uid 1000 gid 4 mode 620 vm_register: registering vm 3 vm_priv_ifconfig: interface tap0 description vm3-if0-OBSDSnap64.vm vm_priv_ifconfig: switch "local" interface bridge0 add tap0 OBSDSnap64.vm: started vm 3 successfully, tty /dev/ttyp4 loadfile_bios: loaded BIOS image run_vm: initializing hardware for vm OBSDSnap64.vm pic_set_elcr: setting level triggered mode for irq 3 pic_set_elcr: setting level triggered mode for irq 5 pic_set_elcr: setting level triggered mode for irq 6 virtio_init: vm "OBSDSnap64.vm" vio0 lladdr fe:e1:ba:d0:eb:ac pic_set_elcr: setting level triggered mode for irq 7 run_vm: starting vcpu threads for vm OBSDSnap64.vm vcpu_reset: resetting vcpu 0 for vm 3 run_vm: waiting on events for VM OBSDSnap64.vm vcpu_run_loop: vm 3 / vcpu 0 run ioctl failed: Invalid argument vmm_sighdlr: handling signal 20 vmm_sighdlr: attempting to terminate vm 3 terminate_vm: terminating vmid 3 vmm_sighdlr: calling vm_remove vm_remove: removing vm id 3 from running config vm_remove: calling vm_stop vm_stop: stopping vm 3 vmd_dispatch_vmm: handling TERMINATE_EVENT for vm id 3 ret 22 vmd_dispatch_vmm: about to stop vm id 3 vm_stop: stopping vm 3 Contents of vm.conf: switch "local" { interface bridge0 } switch "internal" { interface bridge1 } switch "wired" { interface bridge0 } # OpenBSD Stable vm "OBSD-Stable.vm" {