Re: weekly periodic security status
On Sat, Aug 24, 2013 at 06:03:37PM -0400, Eitan Adler wrote: On Sat, Aug 24, 2013 at 4:47 PM, Jeremie Le Hen j...@freebsd.org wrote: On Sat, Aug 24, 2013 at 10:41:56AM -0400, Eitan Adler wrote: On Thu, Aug 22, 2013 at 4:49 PM, Jeremie Le Hen j...@freebsd.org wrote: Well, whatever, if you have any concerns, objections or comments, please speak now :). This LGTM but please include a comment above the warning with a date / release number when this compatibility can be removed. If the old variable names are deprecated in releng/10, they can be removed in releng/11, can't they? Yes, and this should be indicated in a comment. When I see deprecated or old hack or similar terms in code it takes some archaeology to figure out when it was added and when it could be removed. It would be nice to help the future reader a bit. The purpose of my question was to know what to put in the comment ;-). Thanks for pointing this out. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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: weekly periodic security status
On Sat, Aug 24, 2013 at 06:57:04PM +0200, Jeremie Le Hen wrote: On Fri, Aug 23, 2013 at 08:35:55PM -0800, Royce Williams wrote: On Fri, Aug 23, 2013 at 10:44 AM, Darren Pilgrim list_free...@bluerosetech.com wrote: Thank you for this, but if I may make one suggestion: don't combine all the security report settings--keep both daily_* and weekly_*. This makes possible running some security tasks on a daily basis and others on a weekly basis. For example, daily pkg/portaudit checks, but weekly filesystem scans. Agreed. I welcome and would use the weekly option at this level of granularity, but would like to retain daily for many checks, and so would not use weekly if was an all-or-nothing option. Sounds like a good idea. However I don't know how to implement this because, in the current state of the periodic security scripts, there is no way to know whether a script had been called from daily or weekly periodic scripts, so no way to know which variable to check. The easy way to work around this would be to declare an environment variable from 450.status-security, but it sounds like a hackish way because you create an additional dependency for the periodic security scripts. I've modified periodic(8) to set the $PERIODIC environment variable in r254829. The attached patch does more or less what you requested, but slightly differently. We now have the following variables to control daily/weekly security runs: daily_status_security_enable=YES daily_status_security_inline=NO daily_status_security_output=root weekly_status_security_enable=YES weekly_status_security_inline=NO weekly_status_security_output=root And the following variables to control whether you want each check to run daily, weekly or directly from crontab (the default, backward compatible values are shown): security_status_chksetuid_enable=daily security_status_neggrpperm_enable=daily security_status_chkmounts_enable=daily security_status_chkuid0_enable=daily security_status_passwdless_enable=daily security_status_logincheck_enable=daily security_status_chkportsum_enable=NO security_status_ipfwdenied_enable=daily security_status_ipfdenied_enable=daily security_status_pfdenied_enable=daily security_status_ipfwlimit_enable=daily security_status_ipf6denied_enable=daily security_status_kernelmsg_enable=daily security_status_loginfail_enable=daily security_status_tcpwrap_enable=daily The periodic.conf(5) manpage and default/periodic.conf have been updated accordingly, but I plan to further rework them after the patch is committed (especially, grouping security related variable into their own section). That way the modification done by the patch remain clear. Patch available here: http://people.freebsd.org/~jlh/daily_or_weekly_status_security.diff -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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: svn commit: r254853 - head/sys/dev/drm2
Hi!
I'd just like to publicly thank you for all your hard work on improving the
DRM2 support. This is something that's been sorely lacking lately.
So, thank you!
-adrian
On 25 August 2013 05:27, Jean-Sebastien Pedron dumbb...@freebsd.org wrote:
Author: dumbbell
Date: Sun Aug 25 12:27:15 2013
New Revision: 254853
URL: http://svnweb.freebsd.org/changeset/base/254853
Log:
drm: Import drm_fixed.h from Linux 3.8
Added:
head/sys/dev/drm2/drm_fixed.h (contents, props changed)
Added: head/sys/dev/drm2/drm_fixed.h
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/sys/dev/drm2/drm_fixed.h Sun Aug 25 12:27:15 2013
(r254853)
@@ -0,0 +1,72 @@
+/*
+ * Copyright 2009 Red Hat Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
Software),
+ * to deal in the Software without restriction, including without
limitation
+ * the rights to use, copy, modify, merge, publish, distribute,
sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be
included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES
OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors: Dave Airlie
+ */
+
+#include sys/cdefs.h
+__FBSDID($FreeBSD$);
+
+#ifndef DRM_FIXED_H
+#define DRM_FIXED_H
+
+typedef union dfixed {
+ u32 full;
+} fixed20_12;
+
+
+#define dfixed_const(A) (u32)(((A) 12))/* + ((B + 0.000122)*4096)) */
+#define dfixed_const_half(A) (u32)(((A) 12) + 2048)
+#define dfixed_const_666(A) (u32)(((A) 12) + 2731)
+#define dfixed_const_8(A) (u32)(((A) 12) + 3277)
+#define dfixed_mul(A, B) ((u64)((u64)(A).full * (B).full + 2048) 12)
+#define dfixed_init(A) { .full = dfixed_const((A)) }
+#define dfixed_init_half(A) { .full = dfixed_const_half((A)) }
+#define dfixed_trunc(A) ((A).full 12)
+#define dfixed_frac(A) ((A).full ((1 12) - 1))
+
+static inline u32 dfixed_floor(fixed20_12 A)
+{
+ u32 non_frac = dfixed_trunc(A);
+
+ return dfixed_const(non_frac);
+}
+
+static inline u32 dfixed_ceil(fixed20_12 A)
+{
+ u32 non_frac = dfixed_trunc(A);
+
+ if (A.full dfixed_const(non_frac))
+ return dfixed_const(non_frac + 1);
+ else
+ return dfixed_const(non_frac);
+}
+
+static inline u32 dfixed_div(fixed20_12 A, fixed20_12 B)
+{
+ u64 tmp = ((u64)A.full 13);
+
+ do_div(tmp, B.full);
+ tmp += 1;
+ tmp /= 2;
+ return lower_32_bits(tmp);
+}
+#endif
___
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: svn commit: r254853 - head/sys/dev/drm2
On 25.08.2013 14:51, Adrian Chadd wrote: I'd just like to publicly thank you for all your hard work on improving the DRM2 support. This is something that's been sorely lacking lately. So, thank you! Hello! Thank you very much for the kind words! There's still a long way to go until we have an up-to-date graphic stack. Several people (the FreeBSD X11 team, contributors, etc.), not just me, are really motivated to achieve this goal. They all deserve a thank you! -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: weekly periodic security status
On Sun, Aug 25, 2013 at 3:05 AM, Jeremie Le Hen j...@freebsd.org wrote: On Sat, Aug 24, 2013 at 06:57:04PM +0200, Jeremie Le Hen wrote: On Fri, Aug 23, 2013 at 08:35:55PM -0800, Royce Williams wrote: On Fri, Aug 23, 2013 at 10:44 AM, Darren Pilgrim list_free...@bluerosetech.com wrote: Thank you for this, but if I may make one suggestion: don't combine all the security report settings--keep both daily_* and weekly_*. This makes possible running some security tasks on a daily basis and others on a weekly basis. For example, daily pkg/portaudit checks, but weekly filesystem scans. Agreed. I welcome and would use the weekly option at this level of granularity, but would like to retain daily for many checks, and so would not use weekly if was an all-or-nothing option. Sounds like a good idea. However I don't know how to implement this because, in the current state of the periodic security scripts, there is no way to know whether a script had been called from daily or weekly periodic scripts, so no way to know which variable to check. The easy way to work around this would be to declare an environment variable from 450.status-security, but it sounds like a hackish way because you create an additional dependency for the periodic security scripts. I've modified periodic(8) to set the $PERIODIC environment variable in r254829. The attached patch does more or less what you requested, but slightly differently. We now have the following variables to control daily/weekly security runs: daily_status_security_enable=YES daily_status_security_inline=NO daily_status_security_output=root weekly_status_security_enable=YES weekly_status_security_inline=NO weekly_status_security_output=root And the following variables to control whether you want each check to run daily, weekly or directly from crontab (the default, backward compatible values are shown): security_status_chksetuid_enable=daily security_status_neggrpperm_enable=daily security_status_chkmounts_enable=daily security_status_chkuid0_enable=daily security_status_passwdless_enable=daily security_status_logincheck_enable=daily security_status_chkportsum_enable=NO security_status_ipfwdenied_enable=daily security_status_ipfdenied_enable=daily security_status_pfdenied_enable=daily security_status_ipfwlimit_enable=daily security_status_ipf6denied_enable=daily security_status_kernelmsg_enable=daily security_status_loginfail_enable=daily security_status_tcpwrap_enable=daily The periodic.conf(5) manpage and default/periodic.conf have been updated accordingly, but I plan to further rework them after the patch is committed (especially, grouping security related variable into their own section). That way the modification done by the patch remain clear. Patch available here: http://people.freebsd.org/~jlh/daily_or_weekly_status_security.diff This approach creates the granularity that I was looking for, and represents a non-trivial amount of work; thanks for taking this on! I haven't looked closely at the patch, but I do have a couple of style comments. If someone uses an unrecognized value the config, the phrase this is incorrect, while strictly accurate, is a little harsh (and less FreeBSD-ish, I think). I would expect something more along the lines of Valid values are now (daily|weekly|NO). See periodic.conf(5) for more details. This gives the user the minimum information, leaves breadcrumbs ... and is a little less potentially pejorative. :-) Also, while I see the utility in toggling daily/weekly in the *_enable variables, how much precedent is there for overloading *_enable in this way? It's the first time that I've seen it, and may be a mild POLA violation. Most scripts seem to use *_enable solely as a binary YES/NO toggle, and then modify script behavior with other variables (perhaps _period in this case?) That would double the config size, though, so I definitely see why you went this route. Both of the above are closely related. If the period was stored in a different variable, and the default _period was daily, then the vast majority of the user base would still be correct and Just Keep Working ... and only those interested in weekly updates would need to modify anything. Just my $0.04. Royce ___ 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: weekly periodic security status
On 8/25/2013 7:05 AM, Jeremie Le Hen wrote: And the following variables to control whether you want each check to run daily, weekly or directly from crontab (the default, backward compatible values are shown): What do we do if we want to run a check both daily and weekly? ___ 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: weekly periodic security status
Hi Darren, On Sun, Aug 25, 2013 at 12:45:22PM -0400, Darren Pilgrim wrote: On 8/25/2013 7:05 AM, Jeremie Le Hen wrote: And the following variables to control whether you want each check to run daily, weekly or directly from crontab (the default, backward compatible values are shown): What do we do if we want to run a check both daily and weekly? I really don't see the point of running some checks weekly when you do daily. Do you have a particular example in mind? -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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
Torture test for atomics and userland locking?
Can anyone suggest a good test suite for stressing atomic primitives and/or userland locking? There were some questions on freebsd-arm about verifying that our atomics are correct; a few people have looked at the code and everything looks good so far, but it would be reassuring to have some test suite that could provide additional confidence. Tim ___ 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: weekly periodic security status
On Sun, Aug 25, 2013 at 07:39:25AM -0800, Royce Williams wrote: On Sun, Aug 25, 2013 at 3:05 AM, Jeremie Le Hen j...@freebsd.org wrote: On Sat, Aug 24, 2013 at 06:57:04PM +0200, Jeremie Le Hen wrote: On Fri, Aug 23, 2013 at 08:35:55PM -0800, Royce Williams wrote: On Fri, Aug 23, 2013 at 10:44 AM, Darren Pilgrim list_free...@bluerosetech.com wrote: Thank you for this, but if I may make one suggestion: don't combine all the security report settings--keep both daily_* and weekly_*. This makes possible running some security tasks on a daily basis and others on a weekly basis. For example, daily pkg/portaudit checks, but weekly filesystem scans. Agreed. I welcome and would use the weekly option at this level of granularity, but would like to retain daily for many checks, and so would not use weekly if was an all-or-nothing option. Sounds like a good idea. However I don't know how to implement this because, in the current state of the periodic security scripts, there is no way to know whether a script had been called from daily or weekly periodic scripts, so no way to know which variable to check. The easy way to work around this would be to declare an environment variable from 450.status-security, but it sounds like a hackish way because you create an additional dependency for the periodic security scripts. I've modified periodic(8) to set the $PERIODIC environment variable in r254829. The attached patch does more or less what you requested, but slightly differently. We now have the following variables to control daily/weekly security runs: daily_status_security_enable=YES daily_status_security_inline=NO daily_status_security_output=root weekly_status_security_enable=YES weekly_status_security_inline=NO weekly_status_security_output=root And the following variables to control whether you want each check to run daily, weekly or directly from crontab (the default, backward compatible values are shown): security_status_chksetuid_enable=daily security_status_neggrpperm_enable=daily security_status_chkmounts_enable=daily security_status_chkuid0_enable=daily security_status_passwdless_enable=daily security_status_logincheck_enable=daily security_status_chkportsum_enable=NO security_status_ipfwdenied_enable=daily security_status_ipfdenied_enable=daily security_status_pfdenied_enable=daily security_status_ipfwlimit_enable=daily security_status_ipf6denied_enable=daily security_status_kernelmsg_enable=daily security_status_loginfail_enable=daily security_status_tcpwrap_enable=daily The periodic.conf(5) manpage and default/periodic.conf have been updated accordingly, but I plan to further rework them after the patch is committed (especially, grouping security related variable into their own section). That way the modification done by the patch remain clear. Patch available here: http://people.freebsd.org/~jlh/daily_or_weekly_status_security.diff This approach creates the granularity that I was looking for, and represents a non-trivial amount of work; thanks for taking this on! I haven't looked closely at the patch, but I do have a couple of style comments. If someone uses an unrecognized value the config, the phrase this is incorrect, while strictly accurate, is a little harsh (and less FreeBSD-ish, I think). I would expect something more along the lines of Valid values are now (daily|weekly|NO). See periodic.conf(5) for more details. This gives the user the minimum information, leaves breadcrumbs ... and is a little less potentially pejorative. :-) Also, while I see the utility in toggling daily/weekly in the *_enable variables, how much precedent is there for overloading *_enable in this way? It's the first time that I've seen it, and may be a mild POLA violation. Most scripts seem to use *_enable solely as a binary YES/NO toggle, and then modify script behavior with other variables (perhaps _period in this case?) That would double the config size, though, so I definitely see why you went this route. Both of the above are closely related. If the period was stored in a different variable, and the default _period was daily, then the vast majority of the user base would still be correct and Just Keep Working ... and only those interested in weekly updates would need to modify anything. Just my $0.04. It's more than that, I really like your proposal. I've implemented it here: http://people.freebsd.org/~jlh/security_status_period.diff -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To
Re: weekly periodic security status
*Throughout the land, hard drives rejoice* On Sun, Aug 25, 2013 at 3:03 PM, Jeremie Le Hen j...@freebsd.org wrote: On Sun, Aug 25, 2013 at 07:39:25AM -0800, Royce Williams wrote: On Sun, Aug 25, 2013 at 3:05 AM, Jeremie Le Hen j...@freebsd.org wrote: On Sat, Aug 24, 2013 at 06:57:04PM +0200, Jeremie Le Hen wrote: On Fri, Aug 23, 2013 at 08:35:55PM -0800, Royce Williams wrote: On Fri, Aug 23, 2013 at 10:44 AM, Darren Pilgrim list_free...@bluerosetech.com wrote: Thank you for this, but if I may make one suggestion: don't combine all the security report settings--keep both daily_* and weekly_*. This makes possible running some security tasks on a daily basis and others on a weekly basis. For example, daily pkg/portaudit checks, but weekly filesystem scans. Agreed. I welcome and would use the weekly option at this level of granularity, but would like to retain daily for many checks, and so would not use weekly if was an all-or-nothing option. Sounds like a good idea. However I don't know how to implement this because, in the current state of the periodic security scripts, there is no way to know whether a script had been called from daily or weekly periodic scripts, so no way to know which variable to check. The easy way to work around this would be to declare an environment variable from 450.status-security, but it sounds like a hackish way because you create an additional dependency for the periodic security scripts. I've modified periodic(8) to set the $PERIODIC environment variable in r254829. The attached patch does more or less what you requested, but slightly differently. We now have the following variables to control daily/weekly security runs: daily_status_security_enable=YES daily_status_security_inline=NO daily_status_security_output=root weekly_status_security_enable=YES weekly_status_security_inline=NO weekly_status_security_output=root And the following variables to control whether you want each check to run daily, weekly or directly from crontab (the default, backward compatible values are shown): security_status_chksetuid_enable=daily security_status_neggrpperm_enable=daily security_status_chkmounts_enable=daily security_status_chkuid0_enable=daily security_status_passwdless_enable=daily security_status_logincheck_enable=daily security_status_chkportsum_enable=NO security_status_ipfwdenied_enable=daily security_status_ipfdenied_enable=daily security_status_pfdenied_enable=daily security_status_ipfwlimit_enable=daily security_status_ipf6denied_enable=daily security_status_kernelmsg_enable=daily security_status_loginfail_enable=daily security_status_tcpwrap_enable=daily The periodic.conf(5) manpage and default/periodic.conf have been updated accordingly, but I plan to further rework them after the patch is committed (especially, grouping security related variable into their own section). That way the modification done by the patch remain clear. Patch available here: http://people.freebsd.org/~jlh/daily_or_weekly_status_security.diff This approach creates the granularity that I was looking for, and represents a non-trivial amount of work; thanks for taking this on! I haven't looked closely at the patch, but I do have a couple of style comments. If someone uses an unrecognized value the config, the phrase this is incorrect, while strictly accurate, is a little harsh (and less FreeBSD-ish, I think). I would expect something more along the lines of Valid values are now (daily|weekly|NO). See periodic.conf(5) for more details. This gives the user the minimum information, leaves breadcrumbs ... and is a little less potentially pejorative. :-) Also, while I see the utility in toggling daily/weekly in the *_enable variables, how much precedent is there for overloading *_enable in this way? It's the first time that I've seen it, and may be a mild POLA violation. Most scripts seem to use *_enable solely as a binary YES/NO toggle, and then modify script behavior with other variables (perhaps _period in this case?) That would double the config size, though, so I definitely see why you went this route. Both of the above are closely related. If the period was stored in a different variable, and the default _period was daily, then the vast majority of the user base would still be correct and Just Keep Working ... and only those interested in weekly updates would need to modify anything. Just my $0.04. It's more than that, I really like your proposal. I've implemented it here: http://people.freebsd.org/~jlh/security_status_period.diff -- Jeremie Le Hen Scientists say the
