Re: Change top's notion of idle processes / threads
On 24/05/2014 7:22 AM, Allan Jude wrote: On 2014-05-23 16:05, John Baldwin wrote: Right now, when top is set to not display idle processes or threads, it only displays processes or threads that are currently in a runnable state or have a non-zero %cpu. However, our %cpu is quite imprecise. I have patch to change top to instead compare the thread or processes runtime (ki_runtime in kinfo_proc) against the runtime of the thread or process the last time data was fetched. In essence, top will consider any thread that has run on a CPU since the last update as non-idle. The end result is that mostly-idle threads and processes will now be visible in top's idle display. Personally, I find this more useful (and find the current implementation completely useless). The patch is at http://people.freebsd.org/~jhb/patches/top_idle.patch Comments? I think this makes good sense. I would definitely prefer it. Would it make sense to maybe preserve the old behaviour behind a command line flag? And an update to top(8) reflecting the algo :) I know these little esoteric things could always do with more obvious breadcrumbs (like load average calcs, etc) for our future selves and others. +1 on the behavior change, not sure about retaining the old under a flag. Who might benefit from it? How do other OS top implementations calculate their idle? If there's other examples out there with the same (current) algo, then retaining compat might be worth it, such as for newly converted users -- Koobs ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on i386/pc98
TB --- 2014-05-25 13:16:19 - tinderbox 2.22 running on freebsd-current.sentex.ca TB --- 2014-05-25 13:16:19 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-25 13:16:19 - starting HEAD tinderbox run for i386/pc98 TB --- 2014-05-25 13:16:19 - cleaning the object tree TB --- 2014-05-25 13:16:19 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-25 13:16:52 - At svn revision 266645 TB --- 2014-05-25 13:16:53 - building world TB --- 2014-05-25 13:16:53 - CROSS_BUILD_TESTING=YES TB --- 2014-05-25 13:16:53 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-25 13:16:53 - MAKESYSPATH=/src/share/mk TB --- 2014-05-25 13:16:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-25 13:16:53 - SRCCONF=/dev/null TB --- 2014-05-25 13:16:53 - TARGET=pc98 TB --- 2014-05-25 13:16:53 - TARGET_ARCH=i386 TB --- 2014-05-25 13:16:53 - TZ=UTC TB --- 2014-05-25 13:16:53 - __MAKE_CONF=/dev/null TB --- 2014-05-25 13:16:53 - cd /src TB --- 2014-05-25 13:16:53 - /usr/bin/make -B buildworld Building an up-to-date bmake(1) World build started on Sun May 25 13:17:02 UTC 2014 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools [...] c++ -O2 -pipe -I/src/lib/clang/libclangsema/../../../contrib/llvm/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema -I. -I/src/lib/clang/libclangsema/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\i386-unknown-freebsd11.0\ -DLLVM_HOST_TRIPLE=\x86_64-unknown-freebsd11.0\ -DDEFAULT_SYSROOT=\/obj/pc98.i386/src/tmp\ -I/obj/pc98.i386/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaLambda.cpp -o SemaLambda.o c++ -O2 -pipe -I/src/lib/clang/libclangsema/../../../contrib/llvm/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema -I. -I/src/lib/clang/libclangsema/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\i386-unknown-freebsd11.0\ -DLLVM_HOST_TRIPLE=\x86_64-unknown-freebsd11.0\ -DDEFAULT_SYSROOT=\/obj/pc98.i386/src/tmp\ -I/obj/pc98.i386/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaLookup.cpp -o SemaLookup.o c++ -O2 -pipe -I/src/lib/clang/libclangsema/../../../contrib/llvm/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema -I. -I/src/lib/clang/libclangsema/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\i386-unknown-freebsd11.0\ -DLLVM_HOST_TRIPLE=\x86_64-unknown-freebsd11.0\ -DDEFAULT_SYSROOT=\/obj/pc98.i386/src/tmp\ -I/obj/pc98.i386/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaObjCProperty.cpp -o SemaObjCProperty.o c++ -O2 -pipe -I/src/lib/clang/libclangsema/../../../contrib/llvm/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema -I. -I/src/lib/clang/libclangsema/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\i386-unknown-freebsd11.0\ -DLLVM_HOST_TRIPLE=\x86_64-unknown-freebsd11.0\ -DDEFAULT_SYSROOT=\/obj/pc98.i386/src/tmp\ -I/obj/pc98.i386/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaOpenMP.cpp -o SemaOpenMP.o c++ -O2 -pipe -I/src/lib/clang/libclangsema/../../../contrib/llvm/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema -I. -I/src/lib/clang/libclangsema/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\i386-unknown-freebsd11.0\ -DLLVM_HOST_TRIPLE=\x86_64-unknown-freebsd11.0\ -DDEFAULT_SYSROOT=\/obj/pc98.i386/src/tmp\ -I/obj/pc98.i386/src/tmp/legacy/usr/include
Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable
Oliver Pinter oliver.p...@gmail.com writes: Two idea here: a) create a tunable security.pax.expert_mode, and create sysctls at boot time depending from expert mode b) just add CTLFLAG_SKIP and hide the sysctl from normal user The cost of an unused sysctl is about a hundred bytes of kernel memory. What is the cost of the code required to turn it on and off, keeping in mind that most of the contents of the struct sysctl_oid must be present anyway so you can fill in the malloc()ed node? DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable
Oliver Pinter oliver.p...@gmail.com writes: PAX LOG: implement new logging subsystem PAX LOG: fix pax_ulog_segvguard PAX LOG: added sysctl's and tunables PAX ASLR: use PAX LOG PAX LOG: fix pax_ulog_##name() PAX LOG: fix prison init PAX LOG: fixed log and ulog sysctl What exactly is the purpose of PAX LOG? Have you considered using ktrace instead? PAX: blacklist clang and related binaries from PIE support Why? Performance, or do they actually break? PAX ASLR: Blacklist the applications that don't support being built as a position-independent executable don't support as in you have tested them and confirmed that they break in some way? Could you post your test methodology so people can replicate the failures and look into fixing them? PAX ASLR: Use a full kernel config for LATT-ASLR What is the difference between LATT-ASLR and OP-ASLR, and why not just include GENERIC? You know about nooptions, right? Revert PAX: blacklist clang and related binaries from PIE support Revert Revert PAX: blacklist clang and related binaries from PIE support Hmm... DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable
On 5/25/14, Dag-Erling Smørgrav d...@des.no wrote: Oliver Pinter oliver.p...@gmail.com writes: PAX LOG: implement new logging subsystem PAX LOG: fix pax_ulog_segvguard PAX LOG: added sysctl's and tunables PAX ASLR: use PAX LOG PAX LOG: fix pax_ulog_##name() PAX LOG: fix prison init PAX LOG: fixed log and ulog sysctl What exactly is the purpose of PAX LOG? Have you considered using ktrace instead? pax_log will be in future a generic pax related logging framework, with ratelimiting and other features. It will log user, IP, binary name, path, checksum, and others. PAX: blacklist clang and related binaries from PIE support Why? Performance, or do they actually break? No. If you definded WITH_CLANG_EXTRAS= in src.conf, the breaked the build. (added dim@ to CC) --- usr.bin.all__D --- /usr/obj/usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/clang/bugpoint/../../../lib/clang/libllvmirreader/libllvmirreader.a: could not read symbols: Bad value c++: error: linker command failed with exit code 1 (use -v to see invocation) *** [bugpoint] Error code 1 bmake[5]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/clang/bugpoint 1 error bmake[5]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/clang/bugpoint *** [all_subdir_bugpoint] Error code 2 bmake[4]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/clang --- usr.sbin.all__D --- A failure has been detected in another branch of the parallel make bmake[5]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.sbin/acpi/iasl *** [all] Error code 2 bmake[4]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.sbin/acpi 1 error bmake[4]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.sbin/acpi *** [all_subdir_acpi] Error code 2 bmake[3]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.sbin 1 error bmake[3]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.sbin *** [usr.sbin.all__D] Error code 2 bmake[2]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git --- usr.bin.all__D --- --- all_subdir_tblgen --- A failure has been detected in another branch of the parallel make bmake[5]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/clang/tblgen *** [all_subdir_tblgen] Error code 2 bmake[4]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/clang 2 errors bmake[4]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/clang *** [all_subdir_clang] Error code 2 bmake[3]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.bin PAX ASLR: Blacklist the applications that don't support being built as a position-independent executable don't support as in you have tested them and confirmed that they break in some way? Could you post your test methodology so people can replicate the failures and look into fixing them? PAX ASLR: Use a full kernel config for LATT-ASLR What is the difference between LATT-ASLR and OP-ASLR, and why not just include GENERIC? You know about nooptions, right? In upstreamed patch will be removed this kernel configs. These are Shawn's and my kernel config. Revert PAX: blacklist clang and related binaries from PIE support Revert Revert PAX: blacklist clang and related binaries from PIE support Hmm... See above. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable
On 25 May 2014, at 19:42, Oliver Pinter oliver.p...@gmail.com wrote: On 5/25/14, Dag-Erling Smørgrav d...@des.no wrote: Oliver Pinter oliver.p...@gmail.com writes: ... PAX: blacklist clang and related binaries from PIE support Why? Performance, or do they actually break? No. If you definded WITH_CLANG_EXTRAS= in src.conf, the breaked the build. (added dim@ to CC) --- usr.bin.all__D --- /usr/obj/usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/clang/bugpoint/../../../lib/clang/libllvmirreader/libllvmirreader.a: could not read symbols: Bad value c++: error: linker command failed with exit code 1 (use -v to see invocation) *** [bugpoint] Error code 1 I assume you only get this with your ASLR patches applied? Maybe this is because the clang binary itself gets built statically (and so will definitely not be PIE), but the rest of the 'extras', such as bugpoint, are regular dynamic executables. And note that none of the libraries built under lib/libclang are built with -fPIC, at the moment. So that might cause trouble with your PIE patches. In any case, the interesting thing is what the actual linker error was. Do you have more of the preceding build log, including the rest of the settings that were used to build world? And also, what does file /usr/obj/usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/clang/bugpoint/../../../lib/clang/libllvmirreader/libllvmirreader.a say? -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable
Oliver Pinter oliver.p...@gmail.com writes: pax_log will be in future a generic pax related logging framework, with ratelimiting and other features. It will log user, IP, binary name, path, checksum, and others. What are you using this for? Are you sure you can't use ktrace? It's a lot more flexible and powerful than you probably realize. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable
On 5/25/14, Dag-Erling Smørgrav d...@des.no wrote: Oliver Pinter oliver.p...@gmail.com writes: pax_log will be in future a generic pax related logging framework, with ratelimiting and other features. It will log user, IP, binary name, path, checksum, and others. What are you using this for? Are you sure you can't use ktrace? It's a lot more flexible and powerful than you probably realize. Logging to system log, The feature will similar to this in grsecurity: http://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Kernel_Auditing DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable
On 25 May 2014, at 21:31, Oliver Pinter oliver.p...@gmail.com wrote: On 5/25/14, Dag-Erling Smørgrav d...@des.no wrote: Oliver Pinter oliver.p...@gmail.com writes: pax_log will be in future a generic pax related logging framework, with ratelimiting and other features. It will log user, IP, binary name, path, checksum, and others. What are you using this for? Are you sure you can't use ktrace? It's a lot more flexible and powerful than you probably realize. Logging to system log, The feature will similar to this in grsecurity: http://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Kernel_Auditing It sounds like you actually want to be writing audit events then. See audit(4). David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable
On 5/26/14, 5:18 AM, David Chisnall wrote: On 25 May 2014, at 21:31, Oliver Pinter oliver.p...@gmail.com wrote: On 5/25/14, Dag-Erling Smørgrav d...@des.no wrote: Oliver Pinter oliver.p...@gmail.com writes: pax_log will be in future a generic pax related logging framework, with ratelimiting and other features. It will log user, IP, binary name, path, checksum, and others. What are you using this for? Are you sure you can't use ktrace? It's a lot more flexible and powerful than you probably realize. Logging to system log, The feature will similar to this in grsecurity: http://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Kernel_Auditing It sounds like you actually want to be writing audit events then. See audit(4). yeah I think the point is not use ktrace but use and/or possibly extend one of the several already existing methods. we don't need *another* logging facility. David ___ freebsd-secur...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
