Change vfork() to posix_spawn()?
Hello hackers, I'm looking through the Clang Analyzer scans on http://scan.freebsd.your.org/freebsd-head looking for false positives to report back to LLVM. There are quite a list of reports suggesting to change vfork() calls to posix_spawn(). Example from /bin/rpc: http://scan.freebsd.your.org/freebsd-head/bin.rcp/2012-09-12-amd64/report-nsOV80.html#EndPath I know nothing about this but I can see fork and posix_spawn have been discussed on this list previously. Is this a legitimate warning (in this case and in general in FreeBSD base)? Thanks, Erik___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Change vfork() to posix_spawn()?
On 14/09/2012 09:49, Erik Cederstrand wrote: Hello hackers, I'm looking through the Clang Analyzer scans on http://scan.freebsd.your.org/freebsd-head looking for false positives to report back to LLVM. There are quite a list of reports suggesting to change vfork() calls to posix_spawn(). Example from /bin/rpc: http://scan.freebsd.your.org/freebsd-head/bin.rcp/2012-09-12-amd64/report-nsOV80.html#EndPath I know nothing about this but I can see fork and posix_spawn have been discussed on this list previously. Is this a legitimate warning (in this case and in general in FreeBSD base)? Currently (on 9-stable at least), posix_spawn() is implemented as a wrapper around vfork(), so I doubt replacing one with the other would do much. signature.asc Description: OpenPGP digital signature
Re: Change vfork() to posix_spawn()?
Den 14/09/2012 kl. 13.03 skrev Ivan Voras ivo...@freebsd.org: On 14/09/2012 09:49, Erik Cederstrand wrote: Hello hackers, I'm looking through the Clang Analyzer scans on http://scan.freebsd.your.org/freebsd-head looking for false positives to report back to LLVM. There are quite a list of reports suggesting to change vfork() calls to posix_spawn(). Example from /bin/rpc: http://scan.freebsd.your.org/freebsd-head/bin.rcp/2012-09-12-amd64/report-nsOV80.html#EndPath I know nothing about this but I can see fork and posix_spawn have been discussed on this list previously. Is this a legitimate warning (in this case and in general in FreeBSD base)? Currently (on 9-stable at least), posix_spawn() is implemented as a wrapper around vfork(), so I doubt replacing one with the other would do much. The analyzer added this warning in January. The release notes link to this explanation: https://www.securecoding.cert.org/confluence/display/seccode/POS33-C.+Do+not+use+vfork() I guess this is the important part: Because of the implementation of the vfork() function, the parent process is suspended while the child process executes. If a user sends a signal to the child process, delaying its execution, the parent process (which is privileged) is also blocked. This means that an unprivileged process can cause a privileged process to halt, which is a privilege inversion resulting in a denial of service. Erik___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
Hi Mark, Here's the output of our VMs running on ESXi 4.1u1 FreeBSD 7.4: # sysctl kern.timecounter.choice kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) dummy(-100) # sysctl kern.timecounter.hardware kern.timecounter.hardware: ACPI-safe FreeBSD 8.3: # sysctl kern.timecounter.choice kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) dummy(-100) # sysctl kern.timecounter.hardware kern.timecounter.hardware: ACPI-safe FreeBSD 9.0: # sysctl kern.timecounter.choice kern.timecounter.choice: TSC(1000) i8254(0) ACPI-fast(900) dummy(-100) # sysctl kern.timecounter.hardware kern.timecounter.hardware: TSC Note that both 8.3 and 9.0 crash, while 7.4 does not. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Change vfork() to posix_spawn()?
On Fri, Sep 14, 2012 at 4:45 AM, Erik Cederstrand e...@cederstrand.dk wrote: Den 14/09/2012 kl. 13.03 skrev Ivan Voras ivo...@freebsd.org: On 14/09/2012 09:49, Erik Cederstrand wrote: Hello hackers, I'm looking through the Clang Analyzer scans on http://scan.freebsd.your.org/freebsd-head looking for false positives to report back to LLVM. There are quite a list of reports suggesting to change vfork() calls to posix_spawn(). Example from /bin/rpc: http://scan.freebsd.your.org/freebsd-head/bin.rcp/2012-09-12-amd64/report-nsOV80.html#EndPath I know nothing about this but I can see fork and posix_spawn have been discussed on this list previously. Is this a legitimate warning (in this case and in general in FreeBSD base)? Currently (on 9-stable at least), posix_spawn() is implemented as a wrapper around vfork(), so I doubt replacing one with the other would do much. The analyzer added this warning in January. The release notes link to this explanation: https://www.securecoding.cert.org/confluence/display/seccode/POS33-C.+Do+not+use+vfork() I guess this is the important part: Because of the implementation of the vfork() function, the parent process is suspended while the child process executes. If a user sends a signal to the child process, delaying its execution, the parent process (which is privileged) is also blocked. This means that an unprivileged process can cause a privileged process to halt, which is a privilege inversion resulting in a denial of service. Isn't the important part the previous paragraph, which said that some older versions of Linux had the problem? The entire thing reads that the issue comes from an idiom of vfork(), setuid(), then exec, which is both undefined and would be specific to only some *uses* of vfork(), not the implementation. The whole thing isn't worded terribly usefully; e.g. it doesn't explain if it was only Linux that had an issue, which version of Linux is fixed, whether normal code that went straight from vfork() to exec() was fine, etc. Cheers, matthew ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: vm info from a hung system
Are errors in /var/log/messages? I think, you ran out of memory. With top you can see, how many swap is avaible. On 09/14/12 07:32, Vijay Singh wrote: Need some expert help. I have a system that is hung hard, and I was able to get it into gdb. From show_vmstat I see: (kgdb-amd64-7.4-95) show_vmstat SYSTEM MEMORY INFORMATION: mem_wire: 285970432 (272MB) Wired: disabled for paging out mem_active: +400105472 (381MB) Active: recently referenced mem_inactive:+ 56840192 ( 54MB) Inactive: recently not referenced mem_cache: +0 ( 0MB) Cached: almost avail. for allocation mem_free:+0 ( 0MB) Free: fully available for allocation mem_gap_vm: + 753664 ( 0MB) Memory gap: vm ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Change vfork() to posix_spawn()?
On Fri, Sep 14, 2012 at 01:45:49PM +0200, Erik Cederstrand wrote: Den 14/09/2012 kl. 13.03 skrev Ivan Voras ivo...@freebsd.org: On 14/09/2012 09:49, Erik Cederstrand wrote: I'm looking through the Clang Analyzer scans on http://scan.freebsd.your.org/freebsd-head looking for false positives to report back to LLVM. There are quite a list of reports suggesting to change vfork() calls to posix_spawn(). Example from /bin/rpc: http://scan.freebsd.your.org/freebsd-head/bin.rcp/2012-09-12-amd64/report-nsOV80.html#EndPath I know nothing about this but I can see fork and posix_spawn have been discussed on this list previously. Is this a legitimate warning (in this case and in general in FreeBSD base)? Currently (on 9-stable at least), posix_spawn() is implemented as a wrapper around vfork(), so I doubt replacing one with the other would do much. vfork() returns twice, possibly reanimating variables from the dead. Calling posix_spawn() limits this issue to the posix_spawn() implementation only. For example, in case of unwilling compiler developers, the optimization level for that file might be lowered or more volatile keywords might be added. I think it makes more sense to disable various optimizations in the compiler automatically in functions that call vfork(), longjmp() and similar functions, but I do not decide what compiler developers do. The analyzer added this warning in January. The release notes link to this explanation: https://www.securecoding.cert.org/confluence/display/seccode/POS33-C.+Do+not+use+vfork() I guess this is the important part: Because of the implementation of the vfork() function, the parent process is suspended while the child process executes. If a user sends a signal to the child process, delaying its execution, the parent process (which is privileged) is also blocked. This means that an unprivileged process can cause a privileged process to halt, which is a privilege inversion resulting in a denial of service. This problem only occurs if privileges are dropped between vfork and exec, which is uncommon. If no privileges are dropped, the user can affect the parent directly. Furthermore, this exact problem does not happen in FreeBSD because child processes between vfork and exec/exit are not affected by stop signals (this is stronger than the vfork(2) man page documents). However, related issues are still present. If there is a signal handler that blocks for a long time (many functions which do this are async-signal-safe) for a signal permitted by security.bsd.conservative_signals, an unprivileged user will be able to trigger it and delay the thread calling vfork(). A function may also be async-signal-safe but not suitable for a vforked child (for example, libthr makes many functions async-signal-safe by postponing signal handlers which is not good enough if a vforked child is SIGKILL'ed). An unprivileged user may also trigger priority inversion by lowering the priority of the child process and consuming CPU time at a higher priority. Obviously, the child process should not lower its priority voluntarily either. These problems can be fixed in various ways. The direct priority inversion problem can be fixed by using fork() instead in that case or by adding a priority inheritance scheme in the kernel for vforked children (but only for the static priority; the parent's dynamic priority will increase because it is sleeping). The privilege manipulation available via POSIX_SPAWN_RESETIDS seems safe enough. Since it only affects the effective UID/GID, it does not affect the ability to modify scheduling parameters (real UID) or to send signals (real or saved UID). Since the seteuid() call itself will set the issetugid flag to true if it changed anything, it does not affect the ability to debug before exec. More general privilege dropping frequently involves frameworks such as PAM which are not async-signal-safe and certainly not vfork-safe. -- Jilles Tjoelker ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Why fdisk can't open root disk with MBR for writing?
I am trying to change the active partition in MBR. This should be a matter of changing only two bits (clearing one in one byte and setting another one in another byte). However, fdisk complains: fdisk: Failed to write MBR. Try to use gpart(8). truss reveals that fdisk failed to open the root disk for writing: open(/dev/ad4,O_RDWR,00) ERR#1 'Operation not permitted' open(/dev/ad4,O_RDONLY,00) = 3 (0x3) ... ... pwrite(0x3,0x34048200,0x200,0x0,0x0,0x0) ERR#9 'Bad file descriptor' Failed to write MBR. Try to use gpart(8) The question is: why the disk can't be open RW under root? The secondary issue is the bug in fdisk: once -a option is supplied and it can't open it RW it should just say so, and not suggest using gpart because gpart will probably have the same issue. Yuri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why fdisk can't open root disk with MBR for writing?
On Fri, Sep 14, 2012 at 5:19 PM, Yuri y...@rawbw.com wrote: I am trying to change the active partition in MBR. This should be a matter of changing only two bits (clearing one in one byte and setting another one in another byte). However, fdisk complains: fdisk: Failed to write MBR. Try to use gpart(8). truss reveals that fdisk failed to open the root disk for writing: open(/dev/ad4,O_RDWR,00) ERR#1 'Operation not permitted' open(/dev/ad4,O_RDONLY,00) = 3 (0x3) ... ... pwrite(0x3,0x34048200,0x200,0x0,0x0,0x0) ERR#9 'Bad file descriptor' Failed to write MBR. Try to use gpart(8) The question is: why the disk can't be open RW under root? The secondary issue is the bug in fdisk: once -a option is supplied and it can't open it RW it should just say so, and not suggest using gpart because gpart will probably have the same issue. 1. What version of FreeBSD? 2. What do you have set for kern.geom.debug_flags? 3. Is /dev/ad4 (or any partitions / slices under it) currently in use? Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Sep 14, 2012, at 8:48 AM, Mark Felder f...@feld.me wrote: Hi Mark, Here's the output of our VMs running on ESXi 4.1u1 FreeBSD 7.4: # sysctl kern.timecounter.choice kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) dummy(-100) # sysctl kern.timecounter.hardware kern.timecounter.hardware: ACPI-safe FreeBSD 8.3: # sysctl kern.timecounter.choice kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) dummy(-100) # sysctl kern.timecounter.hardware kern.timecounter.hardware: ACPI-safe FreeBSD 9.0: # sysctl kern.timecounter.choice kern.timecounter.choice: TSC(1000) i8254(0) ACPI-fast(900) dummy(-100) # sysctl kern.timecounter.hardware kern.timecounter.hardware: TSC Note that both 8.3 and 9.0 crash, while 7.4 does not. How do you have suj on 8.3 ? Are you using a patch ? Also can you retest 9 with the following sysctl kern.timecounter.hardware=Acpi-fast Also in esxi what setup options do you have for the vm's ? Lastly do you have esxi setup to talk to a ntp server ? If so can you confirm that it's working ? I mean the esxi host not the vm . --- Mark saad | mark.s...@longcount.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why fdisk can't open root disk with MBR for writing?
On Fri, 14 Sep 2012, Yuri wrote: I am trying to change the active partition in MBR. This should be a matter of changing only two bits (clearing one in one byte and setting another one in another byte). However, fdisk complains: fdisk: Failed to write MBR. Try to use gpart(8). truss reveals that fdisk failed to open the root disk for writing: open(/dev/ad4,O_RDWR,00) ERR#1 'Operation not permitted' open(/dev/ad4,O_RDONLY,00) = 3 (0x3) ... ... pwrite(0x3,0x34048200,0x200,0x0,0x0,0x0) ERR#9 'Bad file descriptor' Failed to write MBR. Try to use gpart(8) The question is: why the disk can't be open RW under root? The secondary issue is the bug in fdisk: once -a option is supplied and it can't open it RW it should just say so, and not suggest using gpart because gpart will probably have the same issue. Did you actually try gpart? GEOM prevents writes to providers that are in use, but gpart should handle it correctly if the problem is just that fdisk doesn't understand GEOM. # gpart set -a active -i 1 ada0 If that fails, the provider is in use, usually mounted. The safety can be disabled, but it's better to figure out what has it in use. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why fdisk can't open root disk with MBR for writing?
On 09/14/2012 19:23, Warren Block wrote: Did you actually try gpart? GEOM prevents writes to providers that are in use, but gpart should handle it correctly if the problem is just that fdisk doesn't understand GEOM. # gpart set -a active -i 1 ada0 If that fails, the provider is in use, usually mounted. The safety can be disabled, but it's better to figure out what has it in use. Yes it is the hard drive with mounted /. But changing the active slice should be safe in any case. gpart worked. This safety feature is protecting people from themselves. Sounds very familiar. Thanks! Yuri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
