Snapshot install54.iso does not boot under qemu/kvm
Hi, the 2013-12-31 snapshot iso images don't work for me under qemu 1.7.0 / linux 3.12.6. They get this far and then reboot: loadrandom: cd0a:/etc/random.seed cannot open cd0a:/etc/random.seed loadrandom: error -1 booting cd0a:/5.4/i386/bsd.rd: 6038744+426300 [72+233616+222178]=0x699c6c entry point at 0x210073 I have tried both i386 and amd64. sha256: bdb45f421d4108ebf8da6896f23a1b23e81c968782e41da5529bce4d3146e5fa install54-amd64-snapshot-2013-12-31.iso bbc58d620aff0d5f6c97c6d193c1646754c5479296b97a2ebb468729e8aa0c30 install54-i386-snapshot-2013-12-31.iso I still have snapshots isos from 2013-09-22 lying around, and those continue to work. Therefore I believe it is not a qemu/kvm problem. The last things happening before the reboot seem to be these (amd64 iso): kvm_emulate_insn: 40120:1168:67 66 0f 01 15 88 0f 00 00 (real) kvm_emulate_insn: 40120:1171:0f 20 c0 (real) kvm_emulate_insn: 40120:1174:66 83 c8 01 (real) kvm_emulate_insn: 40120:1178:0f 22 c0 (real) kvm_emulate_insn: 40120:117b:66 ea a3 12 04 00 08 00 (prot16) kvm_emulate_insn: 0:412a3:b8 10 00 00 00 (prot32) kvm_emulate_insn: 0:412a8:8e d8 (prot32) kvm_emulate_insn: 0:412aa:8e d0 (prot32) kvm_emulate_insn: 0:412ac:8e c0 (prot32) kvm_exit: reason EPT_VIOLATION rip 0x1010149 info 182 0 kvm_page_fault: address 15e8050 error_code 182 kvm_exit: reason CPUID rip 0x10101ae info 0 0 kvm_cpuid: func 0 rax 4 rbx 756e6547 rcx 6c65746e rdx 49656e69 kvm_exit: reason CPUID rip 0x10101cf info 0 0 kvm_cpuid: func 1 rax 623 rbx 800 rcx 80802001 rdx 78bfbfd kvm_exit: reason CPUID rip 0x10101e7 info 0 0 kvm_cpuid: func a rax 0 rbx 0 rcx 0 rdx 0 kvm_exit: reason CPUID rip 0x10101ff info 0 0 kvm_cpuid: func 8001 rax 623 rbx 0 rcx 1 rdx 2191abfd kvm_exit: reason CPUID rip 0x1010212 info 0 0 kvm_cpuid: func 8007 rax 0 rbx 0 rcx 0 rdx 0 kvm_exit: reason CR_ACCESS rip 0x101042b info 4 0 kvm_cr: cr_write 4 = 0x6b0 kvm_exit: reason MSR_READ rip 0x1010433 info 0 0 kvm_msr: msr_read c080 = 0x0 kvm_exit: reason MSR_WRITE rip 0x101043c info 0 0 kvm_msr: msr_write c080 = 0x101 kvm_exit: reason CR_ACCESS rip 0x1010440 info 3 0 kvm_cr: cr_write 3 = 0x1b2b000 kvm_exit: reason CR_ACCESS rip 0x101044b info 0 0 kvm_cr: cr_write 0 = 0x8001003b kvm_exit: reason TRIPLE_FAULT rip 0x101045d info 0 0 kvm_userspace_exit: reason KVM_EXIT_SHUTDOWN (8) kvm_userspace_exit: reason restart (4) Not sure if this is related to the actual problem or just the reboot after the problem happened earlier. Cheers, Stefan
Re: Snapshot install54.iso does not boot under qemu/kvm
On Thu, Jan 2, 2014 at 8:20 PM, Stefan Fritsch s...@sfritsch.de wrote: the 2013-12-31 snapshot iso images don't work for me under qemu 1.7.0 / linux 3.12.6. They get this far and then reboot: I had the same problem too and it was just fixed by jsing@ in sys/arch/i386/stand/libsa/random_i386.S rev 1.3 (confirmed working for me). The next snapshot should be good. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
Randomization from the bootblocks
Theo de Raadt deraadt at cvs.openbsd.org writes: This requires an upgrade of the bootblocks and at least /etc/rc (which saves an entropy file for future use). Some bootblocks will be able to use machine-dependent features to improve the entropy even further (for instance using random instructions or fast-running counters or such). As a result, the kernel can start using arc4random() exceedingly early on, even before interrupt entropy is collected. The randomization subsystem can hopefully become simpler due to this early entropy.. there is more work do here. I have a question. Having no interrupt (and such) entropy means less entropy. From other hand, there are lot of speculations about some hardware entropy sources are suspected (proven?) bad (or intentionally hijacked?). So question here is, does moving random generation closer to hardware paves a way to more predictable numbers? Cheers, Alexey
Re: Randomization from the bootblocks
On Thu, Jan 02, 2014 at 12:50, Alexey Suslikov wrote: I have a question. Having no interrupt (and such) entropy means less entropy. From other hand, there are lot of speculations about some hardware entropy sources are suspected (proven?) bad (or intentionally hijacked?). So question here is, does moving random generation closer to hardware paves a way to more predictable numbers? The previous random pid algorithm for early processes was previous pid + 1. Even the backdoor in your CPU can do better than that... The operation of the random number device hasn't changed, except that its initial seed has changed to not be all zero.
some error fixes in signify
Revisiting the error messages:
- pass the filenames to the low-level functions, so they can tell you
what's going on.
- FIX readall and writeall. The logic *is* wrong. Just because they
return something != len, doesn't mean they return -1.
Okay ?
Index: signify.c
===
RCS file: /build/data/openbsd/cvs/src/usr.bin/signify/signify.c,v
retrieving revision 1.6
diff -u -p -r1.6 signify.c
--- signify.c 1 Jan 2014 17:50:33 - 1.6
+++ signify.c 2 Jan 2014 13:37:38 -
@@ -92,10 +92,14 @@ xmalloc(size_t len)
}
static void
-readall(int fd, void *buf, size_t len)
+readall(int fd, void *buf, size_t len, const char *filename)
{
- if (read(fd, buf, len) != len)
- err(1, read);
+ ssize_t x = read(fd, buf, len);
+ if (x == -1) {
+ err(1, read from %s, filename);
+ } else if (x != len) {
+ errx(1, short read from %s, filename);
+ }
}
static void
@@ -108,7 +112,7 @@ readb64file(const char *filename, void *
memset(b64, 0, sizeof(b64));
rv = read(fd, b64, sizeof(b64) - 1);
if (rv == -1)
- err(1, read in %s, filename);
+ err(1, read from %s, filename);
for (i = 0; i rv; i++)
if (b64[i] == '\n')
break;
@@ -137,7 +141,7 @@ readmsg(const char *filename, unsigned l
if (msglen (1UL 30))
errx(1, msg too large in %s, filename);
msg = xmalloc(msglen);
- readall(fd, msg, msglen);
+ readall(fd, msg, msglen, filename);
close(fd);
*msglenp = msglen;
@@ -145,10 +149,14 @@ readmsg(const char *filename, unsigned l
}
static void
-writeall(int fd, const void *buf, size_t len)
+writeall(int fd, const void *buf, size_t len, const char *filename)
{
- if (write(fd, buf, len) != len)
- err(1, write);
+ ssize_t x = write(fd, buf, len);
+ if (x == -1) {
+ err(1, write to %s, filename);
+ } else if (x != len) {
+ errx(1, short write to %s, filename);
+ }
}
static void
@@ -161,10 +169,10 @@ writeb64file(const char *filename, const
fd = xopen(filename, O_CREAT|O_EXCL|O_NOFOLLOW|O_RDWR, mode);
snprintf(header, sizeof(header), signify -- %s\n, comment);
- writeall(fd, header, strlen(header));
+ writeall(fd, header, strlen(header), filename);
if ((rv = b64_ntop(buf, len, b64, sizeof(b64))) == -1)
errx(1, b64 encode failed);
- writeall(fd, b64, rv);
+ writeall(fd, b64, rv, filename);
memset(b64, 0, sizeof(b64));
close(fd);
}
MacbookAir5,1 screen goes blank during install of OpenBSD 5.4-release
While installing OpenBSD 5.4-release or OpenBSD 5.4-current on my MacbookAir5,1 my screen goes blank after a variable period of time, usually between 1 and 60 seconds. While the screen is blank, the installer is still responsive, i.e. if I was at the shell when the screen went blank and then I type reboot, the machine reboots successfully. So far the screen has never gone blank while I was at the boot prompt, even when waiting there for some time. I've also never had it go blank after the partitioning step. My workaround so far has been to move quickly--sometimes I can get through the installation fast enough and succeed before the screen goes blank. That makes custom partitioning a bit of a challenge though. ;) Once I'm through the installation the system boots just fine, the screen doesn't go blank, and the system seems stable even after days of use. Searching forums and blogs, I can find a handful of people that have similar symptoms when using Macbook Air laptops, e.g. http://marc.info/?t=13824783291r=1w=2 A couple people have said that plugging in an external monitor was a viable workaround for them, but that does not work for me. Whether I plug an external monitor in before or after boot and before or after the screen going blank, the screen still goes blank, though in the case of an external monitor plugged in before boot, the external monitor is the one showing content (instead of the internal montior) until it goes blank. My dmesg (same as dmesg.boot) follows. == dmesg == OpenBSD 5.4-current (GENERIC.MP) #211: Sun Dec 22 14:18:30 MST 2013 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP RTC BIOS diagnostic error dfclock_battery,ROM_cksum,memory_size,fixed_disk,invalid_time real mem = 8475713536 (8083MB) avail mem = 8241897472 (7860MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe (54 entries) bios0: vendor Apple Inc. version MBA51.88Z.00EF.B02.1211271028 date 11/27/2012 bios0: Apple Inc. MacBookAir5,1 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET APIC SBST ECDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT DMAR MCFG acpi0: wakeup devices P0P2(S4) PEG2(S4) EC__(S4) HDEF(S4) RP02(S4) ARPT(S4) RP05(S4) EHC1(S4) EHC2(S4) XHC1(S4) ADP1(S4) LID0(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz, 1896.01 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz, 1895.70 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz, 1895.70 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz, 1895.70 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 2 acpiec0 at acpi0 acpimcfg0 at acpi0 addr 0xe000, bus 0-153 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P2) acpiprt2 at acpi0: bus -1 (PEG2) acpiprt3 at acpi0: bus 2 (RP02) acpiprt4 at acpi0: bus 3 (RP05) acpicpu0 at acpi0: C3, C1, PSS acpicpu1 at acpi0: C3, C1, PSS acpicpu2 at acpi0: C3, C1, PSS acpicpu3 at acpi0: C3, C1, PSS acpibat0 at acpi0:
Re: some error fixes in signify
On Thu, Jan 02, 2014 at 14:40, Marc Espie wrote: Revisiting the error messages: - pass the filenames to the low-level functions, so they can tell you what's going on. - FIX readall and writeall. The logic *is* wrong. Just because they return something != len, doesn't mean they return -1. hmm. the intention was to keep the code as small as possible. a detailed dissection of every error that will never happen runs somewhat contrary to that goal. it's not like the difference between a failed write and a short write is meaningful to the user. the important thing is that it not fail silently. if you need to know why it failed, ktrace it. :)
Re: some error fixes in signify
On Thu, Jan 02, 2014 at 10:36:53AM -0500, Ted Unangst wrote: On Thu, Jan 02, 2014 at 14:40, Marc Espie wrote: Revisiting the error messages: - pass the filenames to the low-level functions, so they can tell you what's going on. - FIX readall and writeall. The logic *is* wrong. Just because they return something != len, doesn't mean they return -1. hmm. the intention was to keep the code as small as possible. a detailed dissection of every error that will never happen runs somewhat contrary to that goal. it's not like the difference between a failed write and a short write is meaningful to the user. Oh come on, that's a bug, and really poor style. You're going to call err() when there's no meaningful value in errno ? That's really a bad example, if nothing else. There's a difference between small and obnoxiously wrong. Even if it's a wee bit larger, it doesn't make it less easy to read.
Re: some error fixes in signify
On Thu, Jan 02, 2014 at 16:55, Marc Espie wrote: Oh come on, that's a bug, and really poor style. You're going to call err() when there's no meaningful value in errno ? That's really a bad example, if nothing else. ok, sure, make it errx. but next somebody is going to want to rewrite it into a loop to handle nonblocking files, and then somebody adds a timeout, and then comes a fucking progress meter...
Re: Randomization from the bootblocks
Theo de Raadt deraadt at cvs.openbsd.org writes: This requires an upgrade of the bootblocks and at least /etc/rc (which saves an entropy file for future use). Some bootblocks will be able to use machine-dependent features to improve the entropy even further (for instance using random instructions or fast-running counters or such). As a result, the kernel can start using arc4random() exceedingly early on, even before interrupt entropy is collected. The randomization subsystem can hopefully become simpler due to this early entropy.. there is more work do here. I have a question. Having no interrupt (and such) entropy means less entropy. From other hand, there are lot of speculations about some hardware entropy sources are suspected (proven?) bad (or intentionally hijacked?). So question here is, does moving random generation closer to hardware paves a way to more predictable numbers? It is clear you don't understand the code that was commited.
Re: Randomization from the bootblocks
On 01/02/14 11:50, Alexey Suslikov wrote: Theo de Raadt deraadt at cvs.openbsd.org writes: This requires an upgrade of the bootblocks and at least /etc/rc (which saves an entropy file for future use). Some bootblocks will be able to use machine-dependent features to improve the entropy even further (for instance using random instructions or fast-running counters or such). As a result, the kernel can start using arc4random() exceedingly early on, even before interrupt entropy is collected. The randomization subsystem can hopefully become simpler due to this early entropy.. there is more work do here. I have a question. Having no interrupt (and such) entropy means less entropy. From other hand, there are lot of speculations about some hardware entropy sources are suspected (proven?) bad (or intentionally hijacked?). So question here is, does moving random generation closer to hardware paves a way to more predictable numbers? The generation itself is not going anywhere. The various entropy sources adds up, so one entropy source providing bad data should leave the random quality unaffected, at worst. /Alexander Cheers, Alexey
