[Bug 239894] security.bsd.stack_guard_page default causes Java to crash
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894 Shawn Webb changed: What|Removed |Added CC||shawn.w...@hardenedbsd.org --- Comment #12 from Shawn Webb --- HardenedBSD has noticed spurious issues when setting security.bsd.stack_guard_page greater than 1, especially when building packages. As such, we prevent it from being set to values other than 0 or 1. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 239894] security.bsd.stack_guard_page default causes Java to crash
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894 --- Comment #13 from Kurt Miller --- (In reply to Shawn Webb from comment #12) The authors of the Stack Clash advisory indicate a 4096 byte guard region is not difficult to jump over and avoid. Their recommendation is a 1MB guard region. Restricting the value at 1 leaves this issue unaddressed. https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt I think the security.bsd.stack_guard_page mechanism needs a hard look at how it is implemented. I see the following problems with the current approach. The kernel placed guard pages are placed *within* the stack space requested by mmap(MAP_STACK). This is the primary reason setting this value high causes the issues I pointed out. Currently it not possible for libthr or the JVM to know the number of pages the kernel placed due to TOCTOU and since these pages are kernel placed, userland should not have to do this. The kernel placed guard region should be additional pages outside of the the requested stack size. mmap on top of a MAP_STACK region causes the kernel to move the kernel managed guard pages into the stack region further. I believe it uses the current value of security.bsd.stack_guard_page for that but would need to test this to be sure. Nevertheless, moving the kernel managed guard pages means mmap on top of the MAP_STACK region as a precursor to using mprotect means that both libthr and the JVM do not have a way to set their guard pages predictably. The kernel circumvents this by placing additional guard pages that interfere with userland guard pages as described in previous comments and test programs. Simply using mprotect on top of MAP_STACK pages currently fails to work as well. It appears that for this work the pages need to be previously accessed. IMO, to address the needs of system security and pthreads guard pages and the JVM some changes need to be made to make things work that consistent with how mmap and mprotect are expected to work. At a minimum, kernel placed guard pages need to be additional pages that do not invade the space returned from mmap(MAP_STACK). Ideally mprotect on the usable MAP_STACK space would be made to work. This is most straightforward way libthr and the JVM can place their guard pages and is consistent with how these interferences are generally expected to work. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 240035] freebsd32: sysv IPC broken on non-i386
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240035 Bug ID: 240035 Summary: freebsd32: sysv IPC broken on non-i386 Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: bro...@freebsd.org In the COMPAT_FREEBSD32 code the definitions of struct msqid_ds32, struct msqid_ds32_old, struct semid_ds32, struct semid_ds32_old, struct shmid_ds32, and struct shmid_ds32_old assume time_t is an int32_t when that's only true on i386. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 239894] security.bsd.stack_guard_page default causes Java to crash
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894 --- Comment #14 from Shawn Webb --- (In reply to Kurt Miller from comment #13) > The authors of the Stack Clash advisory indicate a 4096 byte guard region is > not difficult to jump over and avoid. Their recommendation is a 1MB guard > region. Restricting the value at 1 leaves this issue unaddressed. Fully agreed. However, the implementation in FreeBSD has shown to be unstable at values greater than 1. For extra fun, set it to a negative value. :) -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 240039] Setting a mixer device with an empty string (`mixer pcm ""`) does not return
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240039 Bug ID: 240039 Summary: Setting a mixer device with an empty string (`mixer pcm ""`) does not return Product: Base System Version: 11.2-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: 0...@freebsd.org The mixer(8) command does not return if I use it to set a value of one of mixer devices to an empty string, for example `mixer pcm ""`. It does not make much sense to set the value to an empty string, but I should get at least an error message. Tested on FreeBSD 10.4-RELEASE and FreeBSD 13.0-CURRENT. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 229616] bin/dd: add conv=fsync, handle errors in close(2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229616 --- Comment #7 from Jilles Tjoelker --- I agree with checking close() and conv=fsync/fdatasync but not implicit fsync(). Implicit fsync might cause unexpected poor performance. For conv=fsync see review https://reviews.freebsd.org/D21370 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 229616] bin/dd: add conv=fsync, handle errors in close(2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229616 --- Comment #8 from Warner Losh --- This patch looks better than the code review posted. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 240047] more and more processes get stuck waiting for ufs and zfs until system is rendered inaccessible
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240047 Bug ID: 240047 Summary: more and more processes get stuck waiting for ufs and zfs until system is rendered inaccessible Product: Base System Version: 12.0-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: f...@fuz.su I'm on a conference running an open FTP server. Files are served by FTP via ftpd(8), NFS via nfsd(8), and HTTP via Apache 2.4. The server has its root on UFS and remaining files spread over three ZFS pools, one currently replacing a (working) disk: $ zpool list -v NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAGCAP DEDUP HEALTH ALTROOT disk12 18.1T 14.0T 4.16T- - 3%77% 1.00x ONLINE - da3 9.06T 6.98T 2.08T- - 3%77% diskid/DISK-7JG9E40C%20%20%20%20%20%20%20%20%20%20%20%20 9.06T 6.98T 2.08T - - 3%77% cache - - - - - - ada0p2 170G 3.98G 166G- - 0% 2% disk34 18.1T 14.8T 3.33T- - 4%81% 1.00x ONLINE - da2 9.06T 7.39T 1.67T- - 4%81% da1 9.06T 7.41T 1.66T- - 4%81% cache - - - - - - ada0p5 170G 5.14G 165G- - 0% 3% disk56 18.1T 14.0T 4.15T- - 1%77% 1.00x ONLINE - replacing 9.06T 6.97T 2.10T- - 1%76% da0 - - -- - - - da4 - - -- - - - diskid/DISK-7PGVBGZC%20%20%20%20%20%20%20%20%20%20%20%20 9.06T 7.01T 2.06T - - 1%77% cache - - - - - - ada0p6 170G 6.03G 164G- - 0% 3% $ df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/ada0p4375G 68G278G20%/ devfs 1.0K1.0K 0B 100%/dev tmpfs 33G 76K 33G 0%/var/run tmpfs 33G4.0K 33G 0%/tmp tmpfs 33G156K 33G 0%/var/log fdescfs1.0K1.0K 0B 100%/dev/fd procfs 4.0K4.0K 0B 100%/proc disk12 18T 14T3.6T80%/disk12 disk34 17T 14T2.8T83%/disk34 disk56 18T 14T3.6T80%/disk56 disk34/zeug3.6T864G2.8T23%/usr/home/fuz/zeug :/disk12 18T 14T3.6T80%/export :/disk34 35T 32T2.8T92%/export :/disk56 52T 49T3.6T93%/export Files are served over a 10 GBe connection with an average bandwith of around 200 MB/s, the limit seems to be in the number of IOP/s: $ zpool iostat capacity operationsbandwidth poolalloc free read write read write -- - - - - - - disk12 14.0T 4.16T254 0 34.8M 6.16K disk34 14.8T 3.33T261 29 35.0M 1.20M disk56 14.0T 4.15T882 29 118M 191K -- - - - - - - RAM is about half used and nothing seems to indicate any resource exhaustion. $ vmstat procs memory pagedisks faults cpu r b w avm fre flt re pi pofr sr ad0 da0 insycs us sy id 0 0 0 1.0T 666M 451 1197 436 0 64834 14532 0 0 28631 18084 93822 0 17 83 The only sysctl set is kern.racct.enable=1 After a while, more and more httpd and ftpd processes get stuck in an ufs or zfs wait state. They cannot be killed. I have since rebooted the server a bunch of times and the problem keeps appearing. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 238550] Touchpad (via SMBus) not working: Synaptics (SYN1B7F), Elantech - Acer Aspire V3-371
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238550 Kubilay Kocak changed: What|Removed |Added Keywords||feature, needs-patch Summary|Touchpad not working - |Touchpad (via SMBus) not |Synaptics, Elantech - Acer |working: Synaptics |Aspire V3-371 |(SYN1B7F), Elantech - Acer ||Aspire V3-371 Severity|Affects Only Me |Affects Some People -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 238550] Touchpad (via SMBus) not working: Synaptics (SYN1B7F), Elantech - Acer Aspire V3-371
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238550 Jung-uk Kim changed: What|Removed |Added CC||j...@freebsd.org --- Comment #15 from Jung-uk Kim --- FYI, some people are working on it. https://reviews.freebsd.org/D16698 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 240051] top Reports Incorrect Swap File Size
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240051 Bug ID: 240051 Summary: top Reports Incorrect Swap File Size Product: Base System Version: 11.3-STABLE Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: jlma...@gmail.com Created attachment 206811 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=206811&action=edit Full examples of CLI results of top, htop, swapinfo top reports incorrectly swap file size of: "Swap: 30G Total". swapinfo correctly reports swap file size of: "/dev/ada0s1b 503316440 50331644 0%" htop correctly reports swap file size of: "Swp [ 0K/48.0G]" top -v top: version 3.5beta12 htop --version htop 2.2.0 - (C) 2004-2019 Hisham Muhammad Released under the GNU GPL. uname -a FreeBSD h440nndytpo3mqsdvcmtoeu3tppdnchwt85snd 11.3-STABLE FreeBSD 11.3-STABLE #0 r349903: Thu Jul 11 16:13:47 UTC 2019 r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 240047] more and more processes get stuck waiting for ufs and zfs until system is rendered inaccessible
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240047 Kubilay Kocak changed: What|Removed |Added CC||ko...@freebsd.org Keywords||needs-qa Status|New |Open --- Comment #1 from Kubilay Kocak --- Thank you for the repoyrt Robert Can you provide the exact system information (uname -a), and include - pkg version -v output (as an attachment) - /var/run/dmesg.boot output (as an attachment) And when the symptoms are observable: - ps (-aux at least) output (as an attachment ) - vmstat -z output (as an attachment) -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
