F16 - random shutdown delays
Hi, I experience random shutdown delays of ca. 2 min (testing F16 RC1 thru RC4, hd installation with LXDE). To debug it I removed "quiet" and added "systemd.log_level=debug" in /etc/defaults/grub (kernel boot params). This are the only messages logged since shutdown command (regardless whether delay occurred or not): /var/log/messages: ... Nov 2 11:16:24 localhost dbus[852]: [system] Activating service name='org.freedesktop.UPower' (using servicehelper) Nov 2 11:16:24 localhost dbus-daemon[852]: dbus[852]: [system] Activating service name='org.freedesktop.UPower' (using servicehelper) Nov 2 11:16:24 localhost dbus[852]: [system] Successfully activated service 'org.freedesktop.UPower' Nov 2 11:16:24 localhost dbus-daemon[852]: dbus[852]: [system] Successfully activated service 'org.freedesktop.UPower' Nov 2 11:16:30 localhost kernel: Kernel logging (proc) stopped. Nov 2 11:16:30 localhost rsyslogd: [origin software="rsyslogd" swVersion="5.8.5" x-pid="873" x-info="http://www.rsyslog.com";] exiting on signal 15. What else can I look at or debug and how ? JB -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Security release criterion proposal
Josh Bressers bressers at redhat.com Thu May 19 12:57:46 UTC 2011 wrote: > Perhaps the correct answer is to have firstboot update the system > for a user (do it in the background so they can still login do things). Should we do that ? I mean an update in the background without user's knowledge, control, and acceptance ? I would even question that if it was net installation. What if you were installing locally and you want to have an isolated (for a reason) environment ? In a situation like that I would rather opt for a security alert tmessage displayed at time of login (thru GUI or text), present until explicitly canceled by the user. JB -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Security release criterion proposal
Hi, > I don't know if anyone > would want to go as far as making DoS vulns release blocking, but speak > up if you would! (Of course there is again the local/remote distinction > to consider there: 'all DoS vulns' would be a much tighter standard than > 'remote DoS vulns'). I think the "use of a live image shipped with the release" scenario is worth rethinking due to the following: you talk about a *local* DoS - that's technically true. But you know it can be triggered remotely e.g. if you are exposed to Internet (nowadays almost everybody is), and the attacker knows the nature of vulnerability, and what OS area can be hit to do the maximum damage (the price can be very attractive - e.g. the issue raised today by me regarding /run/user and /dev/shm and systemd, which is perhaps the most important system program after kernel itself). So, even a local DoS could qualify for a security blocker. > * We have a system whereby the criteria get more onerous from Alpha to > Beta to Final, so it could be the case that we accept worse security > issues in Alpha than in Beta and so on; we could have a loose criterion > for Alpha and a tighter one for Beta. In this case it felt sensible to > me to just go with one criterion, but please say if you disagree. I would suggest to go for the same criteria for all stages. Advantages: - it gives everybody (Dev, Sec, and QA teams) early warning; otherwise any team may be tempted to implement delay tactics and then force rules relaxation as a stage (alpha, beta, rc, final) release nears and everybody is tired, panicked, etc and "just wants it to be over". Where have we seen that already ? - it gives everybody more time to understand, plan, respond, coordinate - to compensate for early and strict application of security criteria for all stages, you may elect to be more judicious with selection of security blockers. JB -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
2.6.35.4-28.fc14.i686.PAE tainted ?
Hi, can anybody explain it ? After fresh Fedora install (from Fedora repo only) I found in "/var/log/messages" records as: Oct 1 07:08:26 ns kernel: [ cut here ] Oct 1 07:08:26 ns kernel: WARNING: at lib/dma-debug.c:791 check_unmap+0x7a/0x59b() Oct 1 07:08:26 ns kernel: Hardware name: EP45-DQ6 Oct 1 07:08:26 ns kernel: dl2k :09:00.0: DMA-API: device driver tries to free an invalid DMA memory address Oct 1 07:08:26 ns kernel: Modules linked in: bluetooth rfkill nf_nat_ftp nf_conntrack_ftp iptable_nat nf_nat xt_u32 ipt_LOG xt_limit uinput iTCO_wdt i2c_i801 iTCO_vendor_support r8169 mii i2c_core dl2k microcode raid1 [last unloaded: hwmon_vid] Oct 1 07:08:26 ns kernel: Pid: 2454, comm: ip Tainted: GW 2.6.35.4-28.fc14.i686.PAE #1 Oct 1 07:08:26 ns kernel: Call Trace: Oct 1 07:08:26 ns kernel: [] warn_slowpath_common+0x6a/0x7f Oct 1 07:08:26 ns kernel: [] ? check_unmap+0x7a/0x59b Oct 1 07:08:26 ns kernel: [] warn_slowpath_fmt+0x2b/0x2f Oct 1 07:08:26 ns kernel: [] check_unmap+0x7a/0x59b Oct 1 07:08:26 ns kernel: [] ? print_lock_contention_bug+0x11/0xa8 Oct 1 07:08:26 ns kernel: [] ? lock_acquired+0x235/0x23d Oct 1 07:08:26 ns kernel: [] ? debug_object_deactivate+0x28/0x92 Oct 1 07:08:26 ns kernel: [] debug_dma_unmap_page+0x5a/0x62 Oct 1 07:08:26 ns kernel: [] pci_unmap_single+0x58/0x63 [dl2k] Oct 1 07:08:26 ns kernel: [] rio_close+0x9e/0x114 [dl2k] Oct 1 07:08:26 ns kernel: [] __dev_close+0x70/0x85 Oct 1 07:08:26 ns kernel: [] __dev_change_flags+0x98/0x10d Oct 1 07:08:26 ns kernel: [] dev_change_flags+0x18/0x44 Oct 1 07:08:26 ns kernel: [] do_setlink+0x253/0x52e Oct 1 07:08:26 ns kernel: [] ? print_lock_contention_bug+0x11/0xa8 Oct 1 07:08:26 ns kernel: [] ? lock_acquired+0x235/0x23d Oct 1 07:08:26 ns kernel: [] ? handle_mm_fault+0x342/0x8f4 Oct 1 07:08:26 ns kernel: [] rtnl_newlink+0x218/0x3a6 Oct 1 07:08:26 ns kernel: [] ? rtnl_newlink+0xb6/0x3a6 Oct 1 07:08:26 ns kernel: [] ? lock_acquired+0x235/0x23d Oct 1 07:08:26 ns kernel: [] ? rtnl_lock+0x14/0x16 Oct 1 07:08:26 ns kernel: [] ? rtnl_lock+0x14/0x16 Oct 1 07:08:26 ns kernel: [] ? __mutex_lock_common+0x2d0/0x2da Oct 1 07:08:26 ns kernel: [] ? lock_acquired+0x235/0x23d Oct 1 07:08:26 ns kernel: [] ? rtnl_newlink+0x0/0x3a6 Oct 1 07:08:26 ns kernel: [] rtnetlink_rcv_msg+0x19c/0x1ab Oct 1 07:08:26 ns kernel: [] ? rtnetlink_rcv_msg+0x0/0x1ab Oct 1 07:08:26 ns kernel: [] netlink_rcv_skb+0x37/0x78 Oct 1 07:08:26 ns kernel: [] rtnetlink_rcv+0x20/0x27 Oct 1 07:08:26 ns kernel: [] netlink_unicast+0xc6/0x121 Oct 1 07:08:26 ns kernel: [] netlink_sendmsg+0x22e/0x23b Oct 1 07:08:26 ns kernel: [] __sock_sendmsg+0x56/0x5f Oct 1 07:08:26 ns kernel: [] sock_sendmsg+0x98/0xac Oct 1 07:08:26 ns kernel: [] ? might_fault+0x4c/0x86 Oct 1 07:08:26 ns kernel: [] ? lock_release+0x17f/0x186 Oct 1 07:08:26 ns kernel: [] ? copy_from_user+0xd/0xf Oct 1 07:08:26 ns kernel: [] ? verify_iovec+0x43/0x70 Oct 1 07:08:26 ns kernel: [] sys_sendmsg+0x182/0x1e6 Oct 1 07:08:26 ns kernel: [] ? print_lock_contention_bug+0x11/0xa8 Oct 1 07:08:26 ns kernel: [] ? lock_acquired+0x235/0x23d Oct 1 07:08:26 ns kernel: [] ? __do_fault+0x206/0x396 Oct 1 07:08:26 ns kernel: [] ? __do_fault+0x36a/0x396 Oct 1 07:08:26 ns kernel: [] ? lock_acquire+0xb1/0xbc Oct 1 07:08:26 ns kernel: [] ? might_fault+0x4c/0x86 Oct 1 07:08:26 ns kernel: [] ? lock_release+0x17f/0x186 Oct 1 07:08:26 ns kernel: [] sys_socketcall+0x168/0x1a8 Oct 1 07:08:26 ns kernel: [] ? trace_hardirqs_on_thunk+0xc/0x10 Oct 1 07:08:26 ns kernel: [] sysenter_do_call+0x12/0x38 Oct 1 07:08:26 ns kernel: ---[ end trace a70d91368aa35943 ]--- Oops itself is probably suited for bug report, but what isn't clear for me is line Oct 1 07:08:26 ns kernel: Pid: 2454, comm: ip Tainted: GW 2.6.35.4-28.fc14.i686.PAE #1 Which module caused that kernel is tainted? I suppose Fedora contains only open SW including kernel modules, isn't then there something wrong? JB -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
