Disklabel Spoofing and the GPT "Required" Partition Attribute
Hi, So I was using OpenBSD on a USB thumb drive to have a look at the EFI system partition of two laptops (one Windows 10, one Windows 11) when I realized that I couldn't mount the EFI system partition of the Windows 11 laptop at all because there simply wasn't any partition letter defined for it. Here's the (partial) output of fdisk -v on that laptop: Primary GPT: Disk: sd0 Usable LBA: 34 to 2000409230 [2000409264 Sectors] GUID: da4367e3-0319-487a-a475-79535378e9ef #: type [ start: size ] guid name 0: EFI Sys [2048: 532480 ] 10aaba25-0b31-4784-a742-47744e0d1e95 EFI system partition Attributes: (0x8001) Required MSNoAutoMount 1: e3c9e316-0b5c-4db8-817d-f92df00215ae [ 534528:32768 ] ec2ce10b-f72e-49a4-abac-9cb519913748 Microsoft reserved partition 2: Microsoft basic data [ 567296: 1995745280 ] 9422ea37-94b2-4692-89c1-0d4e28b28acb Basic data partition 3: Win Recovery [ 1996312576: 4096000 ] ceffc3ac-538e-42c7-b5fc-23200927e300 Basic data partition Attributes: (0x8001) Required MSNoAutoMount and the (partial) output of disklabel: 16 partitions: #size offset fstype [fsize bsize cpg] c: 20004092640 unused i:32768 534528 unknown j: 1995745280 567296 MSDOS As you can see, the EFI system partition of that laptop has the "Required" attribute. Digging some more, I found these slides by Ken Westerback: https://www.openbsd.org/papers/eurobsdcon2022-krw-blockstobooting.pdf which confirm (slide 22) that the OpenBSD kernel doesn't "spoof GPT partitions with 'Required' attribute" anymore. That's also confirmed by the cvs log message for revision 1.261 of src/sys/kern/subr_disk.c: Add #define's for GPT partition attribute bits REQUIRED, IGNORE and BOOTABLE, set BOOTABLE attribute bit instead of using the incorrect GPTDOSACTIVE value, have 'fdisk -v' print out GPT partition attributes if any of the 64 bits are set, don't spoof any partition with REQUIRED bit set. Prompted by kettenis@ stumbling across a machine with 40+ (!!) REQUIRED GPT partitions. So... now what? I'm in a situation where I can't mount a FAT partition, and as far as I know there's no OpenBSD tool to manually edit GPT partition attributes either, so I'm stuck. The explanation from the cvs log is clear but would it be possible to not spoof "Required" partitions only on arm64 rather than all platforms (arm64 being the "machine" described in the cvs log message, according to the video of Ken Westerback's presentation)? Or maybe use the MSNoAutoMount attribute to undo the effects of the Required one with regard to spoofing? Philippe
Re: execve -1 errno 12 Cannot allocate memory
Theo de Raadt wrote: >Otto Moerbeek wrote: >> Fixing a particluar issue is fine, but more important is an assessment >> it does not break other things. In particular, does this limit the VM >> for data available to any program (which is already quite limited on >> i386)? MAXTSIZ is used in one and only one place in the whole CVS tree, in the file sys/kern/kern_exec.c: int check_exec(struct proc *p, struct exec_package *epp) { [...] /* check limits */ if ((epp->ep_tsize > MAXTSIZ) || (epp->ep_dsize > lim_cur(RLIMIT_DATA))) error = ENOMEM; [...] So doubling MAXTSIZ won't increase or decrease any other kernel limit, and won't drastically change the placement of anything in virtual memory. >I am concerned about the impact this might have on binaries and shared >libraries fitting, because of the i386 line-in-the-sand code and data >seperation model for pre-NX W^X, binaries and libraries are intended >to fit into 512MB seperation, and if they cannot, then the X line ends up >being very high. I guess you're referring to I386_MAX_EXE_ADDR in sys/arch/i386/include/vmparam.h? I'm not knowledgeable enough to meaningfully comment on that. The only extra thing I can say in favor of bumping up MAXTSIZ to 256 MB is that NetBSD increased MAXTSIZ from 64 MB straight to 256 MB more than eight years ago (see Revision 1.74): http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/i386/include/vmparam.h?only_with_tag=MAIN (MAXTSIZ currently is 128 MB on FreeBSD.) Philippe
Re: execve -1 errno 12 Cannot allocate memory
Anyone? Philippe Philippe Meunier wrote: >Jonathan Gray wrote: >>MAXTSIZ is 128 MB on i386 >>see sys/arch/i386/include/vmparam.h > >Mark Kettenis wrote: >>sys/arch/i386/include/vmparam.h has: >>#define MAXTSIZ (128*1024*1024) /* max text size */ > >Thanks to both of you for the pointer! > >So what about the patch below? I've checked with a new kernel that it >fixes the problem with chrome (even when using the default limits in >/etc/login.conf). > >Philippe > > >Index: sys/arch/i386/include/vmparam.h >=== >RCS file: /cvs/src/sys/arch/i386/include/vmparam.h,v >retrieving revision 1.56 >diff -u -r1.56 vmparam.h >--- sys/arch/i386/include/vmparam.h17 Apr 2018 15:50:05 - 1.56 >+++ sys/arch/i386/include/vmparam.h31 Jan 2021 09:41:00 - >@@ -46,7 +46,7 @@ > /* > * Virtual memory related constants, all in bytes > */ >-#define MAXTSIZ (128*1024*1024) /* max text size */ >+#define MAXTSIZ (256*1024*1024) /* max text size */ > #ifndef DFLDSIZ > #define DFLDSIZ (64*1024*1024) /* initial data size > limit */ > #endif > >
Re: execve -1 errno 12 Cannot allocate memory
Jonathan Gray wrote: >MAXTSIZ is 128 MB on i386 >see sys/arch/i386/include/vmparam.h Mark Kettenis wrote: >sys/arch/i386/include/vmparam.h has: >#define MAXTSIZ (128*1024*1024) /* max text size */ Thanks to both of you for the pointer! So what about the patch below? I've checked with a new kernel that it fixes the problem with chrome (even when using the default limits in /etc/login.conf). Philippe Index: sys/arch/i386/include/vmparam.h === RCS file: /cvs/src/sys/arch/i386/include/vmparam.h,v retrieving revision 1.56 diff -u -r1.56 vmparam.h --- sys/arch/i386/include/vmparam.h 17 Apr 2018 15:50:05 - 1.56 +++ sys/arch/i386/include/vmparam.h 31 Jan 2021 09:41:00 - @@ -46,7 +46,7 @@ /* * Virtual memory related constants, all in bytes */ -#defineMAXTSIZ (128*1024*1024) /* max text size */ +#defineMAXTSIZ (256*1024*1024) /* max text size */ #ifndef DFLDSIZ #defineDFLDSIZ (64*1024*1024) /* initial data size limit */ #endif
Re: execve -1 errno 12 Cannot allocate memory
Philippe Meunier wrote: >Is there some kind of limitation on the size of an ELF executable that can >be executed on i386? I mean, in addition to the limits in /etc/login.conf? When using readelf(1) on the chrome executable from chromium-81.0.4044.138.tgz from OpenBSD 6.7-release i386 packages, I get: Section Headers: [Nr] Name TypeAddr OffSize ES Flg Lk Inf Al [...] [15] .text PROGBITS0230d000 230d000 7bda799 00 AX 0 0 64 7bda799 is 129869721 which is 123.8 MB. On the chrome executable from chromium-85.0.4183.121.tgz from OpenBSD 6.8-release i386 packages, I get: Section Headers: [Nr] Name TypeAddr OffSize ES Flg Lk Inf Al [...] [15] .text PROGBITS02412c00 2411c00 83b048b 00 AX 0 0 64 83b048b is 138085515 which is 131.7 MB. Is there somewhere a 128 MB limit for ELF sections on i386, or something along those lines? Philippe
execve -1 errno 12 Cannot allocate memory
Hello, Is there some kind of limitation on the size of an ELF executable that can be executed on i386? I mean, in addition to the limits in /etc/login.conf? Here's why I'm asking: $ uname -a OpenBSD t43.my.domain 6.8 GENERIC#4 i386 $ cat /etc/login.conf [...] default:\ :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/local/sbin:\ :umask=022:\ :datasize-max=infinity:\ :datasize-cur=infinity:\ :memoryuse-max=infinity:\ :memoryuse-cur=infinity:\ :memorylocked-max=infinity:\ :memorylocked-cur=infinity:\ :vmemoryuse-max=infinity:\ :vmemoryuse-cur=infinity:\ :maxproc-max=256:\ :maxproc-cur=128:\ :openfiles-max=1024:\ :openfiles-cur=512:\ :stacksize-max=infinity:\ :stacksize-cur=infinity:\ :localcipher=blowfish,a:\ :tc=auth-defaults:\ :tc=auth-ftp-defaults: [...] (/etc/login.conf is that way just for testing purposes...) $ ulimit -a time(cpu-seconds)unlimited file(blocks) unlimited coredump(blocks) unlimited data(kbytes) 3145728 stack(kbytes)32768 lockedmem(kbytes)unlimited memory(kbytes) unlimited nofiles(descriptors) 512 processes128 $ /usr/local/chrome/chrome /bin/ksh: /usr/local/chrome/chrome: Cannot allocate memory $ ktrace -d -i /usr/local/chrome/chrome ktrace: exec of '/usr/local/chrome/chrome' failed: Cannot allocate memory $ kdump -X 23578 ktrace RET ktrace 0 23578 ktrace CALL execve(0xcf7ebfc1,0xcf7ebf10,0xcf7ebf18) 23578 ktrace NAMI "/usr/local/chrome/chrome" 23578 ktrace RET execve -1 errno 12 Cannot allocate memory 23578 ktrace CALL mprotect(0x58b08000,0x1000,0x3) 23578 ktrace RET mprotect 0 23578 ktrace CALL mprotect(0x58b08000,0x1000,0x1) 23578 ktrace RET mprotect 0 23578 ktrace CALL write(2,0xcf7eb818,0x8) 23578 ktrace GIO fd 2 wrote 8 bytes : 6b 74 72 61 63 65 3a 20 ktrace: 23578 ktrace RET write 8 23578 ktrace CALL write(2,0xcf7eb838,0x29) 23578 ktrace GIO fd 2 wrote 41 bytes : 65 78 65 63 20 6f 66 20 27 2f 75 73 72 2f 6c 6f exec of '/usr/lo 0010: 63 61 6c 2f 63 68 72 6f 6d 65 2f 63 68 72 6f 6d cal/chrome/chrom 0020: 65 27 20 66 61 69 6c 65 64 e' failed 23578 ktrace RET write 41/0x29 23578 ktrace CALL write(2,0xcf7eb820,0x2) 23578 ktrace GIO fd 2 wrote 2 bytes : 3a 20: 23578 ktrace RET write 2 23578 ktrace CALL write(2,0xcf7eb818,0x17) 23578 ktrace GIO fd 2 wrote 23 bytes : 43 61 6e 6e 6f 74 20 61 6c 6c 6f 63 61 74 65 20 Cannot allocate 0010: 6d 65 6d 6f 72 79 0a memory. 23578 ktrace RET write 23/0x17 23578 ktrace CALL mprotect(0x58b08000,0x1000,0x3) 23578 ktrace RET mprotect 0 23578 ktrace CALL mprotect(0x58b08000,0x1000,0x1) 23578 ktrace RET mprotect 0 23578 ktrace CALL mprotect(0x58b08000,0x1000,0x3) 23578 ktrace RET mprotect 0 23578 ktrace CALL mprotect(0x58b08000,0x1000,0x1) 23578 ktrace RET mprotect 0 23578 ktrace CALL munmap(0x58b08000,0x1000) 23578 ktrace RET munmap 0 23578 ktrace CALL exit(1) $ file /usr/local/chrome/chrome /usr/local/chrome/chrome: ELF 32-bit LSB shared object, Intel 80386, version 1 $ ls -l /usr/local/chrome/chrome -rwxr-xr-x 1 root bin 179649140 Oct 2 12:45 /usr/local/chrome/chrome It looks like execve simply refuses to execute that file but I cannot find which limit is being hit. The next biggest executable I can find on my system is /usr/bin/cc which is 62177052 bytes on the hard disk, and I have no problem executing it. This is using OpenBSD 6.8-release (with syspatches applied; dmesg below). I just upgraded from 6.7-release which is when I found out about this problem with chrome. On 6.7 I had datasize-max, datasize-cur, and memoryuse set to 1024M in /etc/login.conf and never had any problem using chrome. Any idea what the problem might be? Best, Philippe OpenBSD 6.8 (GENERIC) #4: Mon Jan 11 10:34:49 MST 2021 r...@syspatch-68-i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC real mem = 1063600128 (1014MB) avail mem = 1027911680 (980MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: date 05/29/07, BIOS32 rev. 0 @ 0xfd740, SMBIOS rev. 2.33 @ 0xe0010 (64 entries) bios0: vendor IBM version "70ET69WW (1.29 )" date 05/29/2007 bios0: IBM 1875E5U acpi0 at bios0: ACPI 3.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG BOOT acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB3(S3) USB7(S3) AC9M(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT c
Re: inteldrm(4) regression from 6.1 to 6.2: wrong console resolution
Mark Kettenis wrote: >I have to think through the consequences of simply doing a delay >without checking the condition here though. Ping? Philippe
Re: inteldrm(4) regression from 6.1 to 6.2: wrong console resolution
Mark Kettenis wrote: >I have to think through the consequences of simply doing a delay >without checking the condition here though. Right now __wait_event_intr_timeout has a KASSERT(!cold), so, if its code is changed to have an "if (cold) { delay(tick); ret = 1; }" then we know that this new code is only going to be called from drm_wait_one_vblank because that's the only place where a corresponding "if (... || cold) return;" is removed. So we always know exactly what the condition is going to be in __wait_event_intr_timeout when "cold" is 1: the condition from drm_wait_one_vblank, which we know we can ignore because it was never used before in drm_wait_one_vblank when "cold" is 1 anyway (because drm_wait_one_vblank simply directly returns in that case). Doing it this way might be a problem in the future though: if code somewhere else is changed to call __wait_event_intr_timeout when "cold" is 1 and with a different condition then the condition will be silently ignored, which is not great. I still think the patch ought to be directly in drm_wait_one_vblank in drm_irq.c, because that's the function that promises to wait for one vblank but does not when "cold" is 1. So that's where I think "if (cold) { delay(tick); return; }" ought to be, and then there would be no need to worry about __wait_event_intr_timeout's condition or about vblank interrupts. I'm not the one who has to merge that code with the Linux code though :-) Philippe
Re: inteldrm(4) regression from 6.1 to 6.2: wrong console resolution
Mark Kettenis wrote: >Maybe you can add some printf's to figure out why the timeout is >happening? Is it actually doing a delay? Is the delay too long? Or >too short? Yes, the delay is okay. The problem is that when "cold" is 1, the vblank counter never changes during a call to drm_wait_one_vblank, so the condition inside __wait_event_intr_timeout is never true and there is a timeout. In fact the vblank counter does not even change across multiple calls to drm_wait_one_vblank, unless there is in-between a call to vblank_disable_and_save followed by a call to drm_vblank_enable. It looks like this when timing every iteration of the delay(tick) loop in the patch you proposed (delays are computed using nanouptime(9); see the dmesg at the end of this email for the complete output): XXX [drm_vblank_on] XXX [drm_vblank_on] XXX [drm_vblank_enable] XXX [drm_wait_one_vblank] drm_vblank_count before wait_event_timeout: 1, cold: 1 XXX [__wait_event_intr_timeout] delay(tick): 0 10004065, ret: 10, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1154, ret: 9, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1154, ret: 8, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1154, ret: 7, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1154, ret: 6, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1154, ret: 5, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1154, ret: 4, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 875, ret: 3, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1154, ret: 2, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 875, ret: 1, (condition): 0 XXX [__wait_event_intr_timeout] (condition) after loop: 0 XXX [drm_wait_one_vblank] drm_vblank_count after wait_event_timeout: 1 vblank wait timed out on crtc 0 XXX [drm_wait_one_vblank] drm_vblank_count before wait_event_timeout: 1, cold: 1 XXX [__wait_event_intr_timeout] delay(tick): 0 1153, ret: 10, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1153, ret: 9, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1153, ret: 8, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1153, ret: 7, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1153, ret: 6, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1153, ret: 5, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1153, ret: 4, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1153, ret: 3, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1153, ret: 2, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1154, ret: 1, (condition): 0 XXX [__wait_event_intr_timeout] (condition) after loop: 0 XXX [drm_wait_one_vblank] drm_vblank_count after wait_event_timeout: 1 vblank wait timed out on crtc 0 (repeat the same thing three more times) XXX [drm_wait_one_vblank] drm_vblank_count after wait_event_timeout: 1 vblank wait timed out on crtc 0 XXX [drm_vblank_off] XXX [vblank_disable_and_save] XXX [drm_vblank_on] XXX [drm_vblank_enable] XXX [drm_wait_one_vblank] drm_vblank_count before wait_event_timeout: 46, cold: 1 XXX [__wait_event_intr_timeout] delay(tick): 0 1154, ret: 10, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 875, ret: 9, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1154, ret: 8, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1155, ret: 7, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1154, ret: 6, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1154, ret: 5, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1155, ret: 4, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1155, ret: 3, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1155, ret: 2, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1154, ret: 1, (condition): 0 XXX [__wait_event_intr_timeout] (condition) after loop: 0 XXX [drm_wait_one_vblank] drm_vblank_count after wait_event_timeout: 46 vblank wait timed out on crtc 0 XXX [drm_wait_one_vblank] drm_vblank_count before wait_event_timeout: 46, cold: 1 XXX [__wait_event_intr_timeout] delay(tick): 0 874, ret: 10, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1153, ret: 9, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1153, ret: 8, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1153, ret: 7, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1153, ret: 6, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1154, ret: 5, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1153, ret: 4, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1153, ret: 3, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick
Re: inteldrm(4) regression from 6.1 to 6.2: wrong console resolution
Philippe Meunier wrote: >Mark Kettenis wrote: >>Does the diff below fix things? > >Yes, it fixes the console resolution problem, although a bunch of "vblank >wait timed out on crtc 0" messages now show up (see dmesg's output below). How about the patch below? It does essentially the same thing as yours but directly inside drm_wait_one_vblank where "cold" was already tested, and without testing "condition" in __wait_event_intr_timeout wich was never tested anyway when "cold" is 1. Philippe Index: sys/dev/pci/drm/drm_irq.c === RCS file: /cvs/src/sys/dev/pci/drm/drm_irq.c,v retrieving revision 1.70 diff -u -p -u -p -r1.70 drm_irq.c --- sys/dev/pci/drm/drm_irq.c 28 Mar 2018 05:27:28 - 1.70 +++ sys/dev/pci/drm/drm_irq.c 15 Aug 2018 05:45:18 - @@ -1316,10 +1316,17 @@ void drm_wait_one_vblank(struct drm_devi struct drm_vblank_crtc *vblank = &dev->vblank[pipe]; int ret; u32 last; + int timo = msecs_to_jiffies(100); - if (WARN_ON(pipe >= dev->num_crtcs) || cold) + if (WARN_ON(pipe >= dev->num_crtcs)) return; + if (cold) { + for (ret = timo; ret > 0; ret--) + delay(tick); + return; + } + ret = drm_vblank_get(dev, pipe); if (WARN(ret, "vblank not available on crtc %i, ret=%i\n", pipe, ret)) return; @@ -1328,7 +1335,7 @@ void drm_wait_one_vblank(struct drm_devi ret = wait_event_timeout(vblank->queue, last != drm_vblank_count(dev, pipe), -msecs_to_jiffies(100)); +timo); WARN(ret == 0, "vblank wait timed out on crtc %i\n", pipe);
Re: inteldrm(4) regression from 6.1 to 6.2: wrong console resolution
Mark Kettenis wrote: >Does the diff below fix things? Yes, it fixes the console resolution problem, although a bunch of "vblank wait timed out on crtc 0" messages now show up (see dmesg's output below). Philippe OpenBSD 6.4-beta (GENERIC) #5: Tue Aug 14 22:20:08 CST 2018 r...@usb.my.domain:/usr/src/sys/arch/i386/compile/GENERIC real mem = 1063600128 (1014MB) avail mem = 1029201920 (981MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: date 05/29/07, BIOS32 rev. 0 @ 0xfd740, SMBIOS rev. 2.33 @ 0xe0010 (64 entries) bios0: vendor IBM version "70ET69WW (1.29 )" date 05/29/2007 bios0: IBM 1875E5U acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG BOOT acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB3(S3) USB7(S3) AC9M(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) Pentium(R) M processor 1.60GHz ("GenuineIntel" 686-class) 1.60 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE,NXE,EST,TM2,PERF,MELTDOWN mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 133MHz ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins , remapped to apid 1 acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 2 (EXP0) acpiprt2 at acpi0: bus -1 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus -1 (EXP3) acpiprt5 at acpi0: bus 4 (PCI1) acpicpu0 at acpi0: C1 (unknown FFH class 0): !C3(250@85 io@0x1015), !C2(500@1 io@0x1014), C1(@1 halt!), PSS acpipwrres0 at acpi0: PUBS, resource for USB0, USB1, USB7 acpitz0 at acpi0: critical temperature is 99 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpicmos0 at acpi0 "IBM0057" at acpi0 not configured "NSC1100" at acpi0 not configured acpibat0 at acpi0: BAT0 model "IBM-92P1091" serial 1313 type LION oem "Panasonic" acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 acpidock0 at acpi0: DOCK not docked (0) acpivideo0 at acpi0: VID_ bios0: ROM list: 0xc/0xf600! 0xcf800/0x1600 0xd1000/0x1000 0xdc000/0x4000! 0xe/0x1 cpu0: Enhanced SpeedStep 1597 MHz: speeds: 1600, 1333, 1066, 800 MHz pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 "Intel 82915GM Host" rev 0x03 inteldrm0 at pci0 dev 2 function 0 "Intel 82915GM Video" rev 0x03 drm0 at inteldrm0 intagp0 at inteldrm0 agp0 at intagp0: aperture at 0xb000, size 0x1000 inteldrm0: apic 1 int 16 vblank wait timed out on crtc 0 vblank wait timed out on crtc 0 vblank wait timed out on crtc 0 vblank wait timed out on crtc 0 vblank wait timed out on crtc 0 vblank wait timed out on crtc 0 vblank wait timed out on crtc 0 vblank wait timed out on crtc 0 vblank wait timed out on crtc 0 vblank wait timed out on crtc 0 vblank wait timed out on crtc 0 vblank wait timed out on crtc 0 inteldrm0: 1024x768, 32bpp vblank wait timed out on crtc 1 vblank wait timed out on crtc 1 wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) "Intel 82915GM Video" rev 0x03 at pci0 dev 2 function 1 not configured ppb0 at pci0 dev 28 function 0 "Intel 82801FB PCIE" rev 0x03: apic 1 int 20 pci1 at ppb0 bus 2 bge0 at pci1 dev 0 function 0 "Broadcom BCM5751M" rev 0x11, BCM5750 B1 (0x4101): apic 1 int 16, address 00:10:c6:e1:f8:03 brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0 ppb1 at pci0 dev 28 function 2 "Intel 82801FB PCIE" rev 0x03: apic 1 int 22 pci2 at ppb1 bus 3 uhci0 at pci0 dev 29 function 0 "Intel 82801FB USB" rev 0x03: apic 1 int 16 uhci1 at pci0 dev 29 function 1 "Intel 82801FB USB" rev 0x03: apic 1 int 17 uhci2 at pci0 dev 29 function 2 "Intel 82801FB USB" rev 0x03: apic 1 int 18 uhci3 at pci0 dev 29 function 3 "Intel 82801FB USB" rev 0x03: apic 1 int 19 ehci0 at pci0 dev 29 function 7 "Intel 82801FB USB" rev 0x03: apic 1 int 19 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb2 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xd3 pci3 at ppb2 bus 4 cbb0 at pci3 dev 0 function 0 "TI PCI1510 CardBus" rev 0x00: apic 1 int 16 ath0 at pci3 dev 2 function 0 "Atheros AR5212" rev 0x01: apic 1 int 21 ath0: AR5213A 5.9 phy 4.3 rf5112a 3.6 eeprom 4.8, WOR01W, address 00:14:a4:72:72:c6 cardslot0 at cbb0 slot 0 flags 0 cardbus0 at cardslot0: bus 5 device 0 cacheline 0x8, lattimer 0xb0 pcmcia0 at cardslot0 auich0 at pci0 dev 30 function 2 "Intel 82801FB AC97" rev 0x03: apic 1 int 22, ICH6 ac97: codec id 0x41445374 (Analog Devices AD1981B) ac97: codec features headphone, 20 bit DAC, No 3D Stereo audio0 at auich0 ichpcib0 at pci0 dev 31 function 0 "Intel 82801FBM LPC" rev 0x03: PM disabled pciide0 at pci0 dev 31 function 2
Re: dc(1); fix 0Z
kshe wrote: >If the number `002' is said to have only one digit because the zeros in [...] >the integer logarithm, thus being nothing but arbitrary, and as such of >little practical value. Yes, yes, but "number of digits" and "integer logarithm" are two different things. You sound suspiciously like a mathematician who's trying to redefine the word "cow" to mean "sphere" simply because he's got a neat formula to compute the volume of a sphere :-) 0 *is* a digit, and not all leading zeroes are superfluous. If all leading zeroes were superfluous then would be a number, which it is not, neither in mathematics nor in everyday life. I'm not interested in getting into a food fight over this, and I'm not the one writing the code anyway, but I think trying to twist the rather plain meaning of "number of digits" into the shape of a mathematical pretzel is not helpful. If anything, it's GNU dc that needs to be changed. Anyway, I'm done with this topic. Philippe
Re: dc(1); fix 0Z
kshe wrote: >Also, the manual defines the length of a number as its number of digits, >so perhaps it should be precised that zero is considered to have no >digits, which might not be obvious to everyone. Am I the only who thinks this is not just not obvious, but actually wrong? On a related note, is this: $ dc 16o16i FFZp supposed to print 2 or 3? Philippe
Re: Remove accents from fortunes
Anthony J. Bentley wrote: >And since nobody's complained in the past few years that they couldn't >see the accents in Jabberwocky... But then some Frenchman might suddenly complain about René Descartes's name being misspelt (not that I had ever noticed that the accent didn't show up before reading your patch...) Philippe
Re: [patch 1/2] doas(1): Moved some parsing from env.c into parse.y
Ted Unangst wrote: >Did I get it backwards? If you have setenv { HERE= there }, your diff >changes behavior. Speaking from the peanut gallery here, but I find this syntax rather confusing and error-prone, especially for a security-related file such as doas.conf. How about making the list of variables comma-separated instead of space-separated, so that the intent is clearer from the syntax? Cheers, Philippe
Re: [patch] which(1): out of bounds read
Max Fillinger wrote: >If PATH starts with "/:", which(1) reads outside of allocated memory. >Maybe that caused the non-reproduceable coredump mentioned in [0]? I think you're right as I did have / at the beginning of my PATH when which(1) coredumped on me. I was planning to look at it today but you beat me to it :-) Philippe
ntpd.conf and Google
Hello, $ fgrep constraint /etc/ntpd.conf constraints from "https://www.google.com"; $ www.google.com and other Google services are not accessible from countries like China or Vietnam. It's easy enough for people to change their ntpd.conf if necessary but how about using a default value that is more likely to work for everyone? Something like https://www.un.org/ for example. Cheers, Philippe
Re: dhclient ignore
Ted Unangst wrote: >[...] I just want to say "pretend this option did not arrive." > >Diff below adds a little support for an ignore keyword. Like >supersede, except don't actually use the supplied value. Put another way, dhclient has a "default permit" policy (it will use any nameserver information sent by the dhcp server even when you didn't ask the server for that information in the first place), and you want to add a blacklist on top of that (in other words, manually enumerate badness in /etc/dhclient.conf). I think it would be much better for dhclient to have a "default deny" policy (always ignore any information coming from the server that you didn't ask for) and use what is actually requested by dhclient from the server as a whitelist. See here http://marc.info/?l=openbsd-tech&m=131302612614702&w=2 for a previous message of mine on that topic, and here http://marc.info/?l=openbsd-misc&m=131914644924795&w=2 for another discussion. Brynet wrote: >I was under the impression that if you added an "request" statement >excluding the 'domain-name-servers' option the server would honour that and >only offer the options you've explictly requested.. No, in practice many dhcp servers will send you nameserver information even when you don't ask for it (I guess it's ISPs' way of saying they think they know better than their users what's good for them...) >Does something like this work for you? > >interface "em0" { > request subnet-mask, broadcast-address, routers, domain-name-servers; >} > >interface "em1" { > request subnet-mask, broadcast-address, routers; >} This would work if dhclient were using a "default deny" policy. Unfortunately it doesn't, so your suggestion doesn't work. Philippe
dhclient, DHCP options, and some opinions
Hello, FYI: 1) The OPTION MODIFIERS section of dhclient.conf(5) indicates that the default client configuration script processes only options 1 (subnet mask), 3 (routers), 6 (domain name servers), and 15 (domain-name). In fact /sbin/dhclient-script also uses option 28 (broadcast address). 2) dhclient-script(8) mentions several times static routes but in fact the static-routes option is not used by /sbin/dhclient-script 3) When /etc/dhclient.conf is empty, the default requested options in the read_client_conf function of /usr/src/sbin/dhclient/clparse.c include option 2 (time offset) and option 12 (host name) which are never processed by /sbin/dhclient-script. I guess it doesn't really hurt to request them in clparse.c just to ignore them later in /sbin/dhclient-script (if they are actually supplied by the DHCP server) but I found it a bit confusing when reading the code... // On a related note, I couldn't find in /usr/src/sbin/dhclient/dhclient.c any code that explicitly removes from a DHCP server's reply any option that was not explicitly requested (or required) by dhclient. Unrequested options sent by a DHCP server seem to always end up in dhclient-script's environment and the system then relies on dhclient-script implicitly ignoring what it does not know about in its environment. This looks to me a lot like a "default allow" policy that relies on dhclient-script doing the Right Thing. When the user later discovers a problem (for example when dhclient-script messes up the /etc/resolv.conf of people who run their own DNS server) the user then has to use "supersede" as some sort of after-the-fact blacklist for unwanted options. IMHO, it would be better if dhclient.c used the list of options requested by the user as a whitelist and then put in dhclient-script's environment only strictly what the user wanted dhclient-script to know about. I.e. the policy for unrequested options would in essence switch to "default deny". This would also have the nice side effect that, if the user didn't ask for the domain-name and domain-name-servers options, then dhclient-script would never change /etc/resolv.conf regardless of what the DHCP server included in its reply. Then people who run their own DNS server (like me, which is why I started looking into this whole thing) wouldn't have to use "supersede" and /etc/resolv.conf.tail (which works but leads to the duplication of information between /etc/resolv.conf, /etc/resolv.conf.tail, and /etc/dhclient.conf, and thus has the feel of curing the /etc/resolv.conf symptom instead of curing the dhclient-script disease :-)). While I'm on the topic, I also think that it would be nicer to completely remove all the default requested options from clparse.c and instead have the default /etc/dhclient.conf request subnet-mask, broadcast-address, routers, domain-name, and domain-name-servers explicitly. This means that it would no longer be "sufficient to just create an empty dhclient.conf file" (from the EXAMPLES section of dhclient.conf(5)) for things to "magically" work, and such a change would also require existing users who currently have an empty /etc/dhclient.conf to change it to explicitly request all the basic options (though sysmerge could easily take care of that one-time change) but I think it just would be cleaner and clearer to have the default requested options listed explicitly in the default /etc/dhclient.conf rather than to have them hard coded and buried in clparse.c. Maybe it's just me :-) Anyway, food for thoughts. Philippe
RLIMIT_AS missing
Hello, I just tried to compile some software on OpenBSD and it failed because OpenBSD does not provide RLIMIT_AS: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/sys/resource.h?rev=1.8;content-type=text%2Fplain even though RLIMIT_AS seems to be part of POSIX: http://www.opengroup.org/onlinepubs/009695399/functions/getrlimit.html I assume this is well known, so I just have two quick questions: 1) Is there a chance of having RLIMIT_AS be added in the future? I noticed that someone submitted a patch for that a few years ago but obviously it wasn't added: http://marc.info/?t=10918210842&r=1&w=2 http://marc.info/?l=openbsd-tech&m=109190100529561&w=2 (alas I don't know enough about OpenBSD's internals to update that patch for the current version of OpenBSD). 2) I patched the software I was trying to compile to replace RLIMIT_AS with the sum of RLIMIT_DATA and RLIMIT_STACK. Is there a better way to approximate RLIMIT_AS? Thanks a lot, Philippe