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
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]
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 = >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
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] 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-techm=131302612614702w=2 for a
previous message of mine on that topic, and here
http://marc.info/?l=openbsd-miscm=131914644924795w=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
