Re: [PATCH 2/2] audit: Move CONFIG_AUDITSYSCALL into staging and update help text
On Wed, May 28, 2014 at 03:21:20PM -0700, Andy Lutomirski wrote: > Here are some issues with the code: > - It thinks that syscalls have four arguments. > - It's a performance disaster. > - It assumes that syscall numbers are between 0 and 2048. > - It's unclear whether it's supposed to be reliable. > - It's broken on things like x32. > - It can't support ARM OABI. > - Its approach to memory allocation is terrifying. > > I considered marking it BROKEN, but that might be too harsh. > > Signed-off-by: Andy Lutomirski > --- > init/Kconfig | 13 - > 1 file changed, 8 insertions(+), 5 deletions(-) > > diff --git a/init/Kconfig b/init/Kconfig > index 9d3585b..4584f8a 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -296,13 +296,16 @@ config HAVE_ARCH_AUDITSYSCALL > bool > > config AUDITSYSCALL > - bool "Enable system-call auditing support" > - depends on AUDIT && HAVE_ARCH_AUDITSYSCALL > + bool "Enable system-call auditing support (not recommended)" > + depends on AUDIT && HAVE_ARCH_AUDITSYSCALL && STAGING As it doesn't actually move any code into drivers/staging/, and I have no TODO list that needs to be resolved in order to get it out of staging (other than your list above), I'd prefer it not to take on the STAGING mark. But BROKEN is fine with me, that should wake people up to fix it or just drop it :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] audit: Move CONFIG_AUDITSYSCALL into staging and update help text
Here are some issues with the code: - It thinks that syscalls have four arguments. - It's a performance disaster. - It assumes that syscall numbers are between 0 and 2048. - It's unclear whether it's supposed to be reliable. - It's broken on things like x32. - It can't support ARM OABI. - Its approach to memory allocation is terrifying. I considered marking it BROKEN, but that might be too harsh. Signed-off-by: Andy Lutomirski --- init/Kconfig | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/init/Kconfig b/init/Kconfig index 9d3585b..4584f8a 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -296,13 +296,16 @@ config HAVE_ARCH_AUDITSYSCALL bool config AUDITSYSCALL - bool "Enable system-call auditing support" - depends on AUDIT && HAVE_ARCH_AUDITSYSCALL + bool "Enable system-call auditing support (not recommended)" + depends on AUDIT && HAVE_ARCH_AUDITSYSCALL && STAGING default y if SECURITY_SELINUX help - Enable low-overhead system-call auditing infrastructure that - can be used independently or with another kernel subsystem, - such as SELinux. + Enable system-call auditing infrastructure that can be used + independently or with another kernel subsystem, such as + SELinux. + + AUDITSYSCALL has serious performance and correctness issues. + Use it with extreme caution. config AUDIT_WATCH def_bool y -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] audit: Move CONFIG_AUDITSYSCALL into staging and update help text
Here are some issues with the code: - It thinks that syscalls have four arguments. - It's a performance disaster. - It assumes that syscall numbers are between 0 and 2048. - It's unclear whether it's supposed to be reliable. - It's broken on things like x32. - It can't support ARM OABI. - Its approach to memory allocation is terrifying. I considered marking it BROKEN, but that might be too harsh. Signed-off-by: Andy Lutomirski l...@amacapital.net --- init/Kconfig | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/init/Kconfig b/init/Kconfig index 9d3585b..4584f8a 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -296,13 +296,16 @@ config HAVE_ARCH_AUDITSYSCALL bool config AUDITSYSCALL - bool Enable system-call auditing support - depends on AUDIT HAVE_ARCH_AUDITSYSCALL + bool Enable system-call auditing support (not recommended) + depends on AUDIT HAVE_ARCH_AUDITSYSCALL STAGING default y if SECURITY_SELINUX help - Enable low-overhead system-call auditing infrastructure that - can be used independently or with another kernel subsystem, - such as SELinux. + Enable system-call auditing infrastructure that can be used + independently or with another kernel subsystem, such as + SELinux. + + AUDITSYSCALL has serious performance and correctness issues. + Use it with extreme caution. config AUDIT_WATCH def_bool y -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] audit: Move CONFIG_AUDITSYSCALL into staging and update help text
On Wed, May 28, 2014 at 03:21:20PM -0700, Andy Lutomirski wrote: Here are some issues with the code: - It thinks that syscalls have four arguments. - It's a performance disaster. - It assumes that syscall numbers are between 0 and 2048. - It's unclear whether it's supposed to be reliable. - It's broken on things like x32. - It can't support ARM OABI. - Its approach to memory allocation is terrifying. I considered marking it BROKEN, but that might be too harsh. Signed-off-by: Andy Lutomirski l...@amacapital.net --- init/Kconfig | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/init/Kconfig b/init/Kconfig index 9d3585b..4584f8a 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -296,13 +296,16 @@ config HAVE_ARCH_AUDITSYSCALL bool config AUDITSYSCALL - bool Enable system-call auditing support - depends on AUDIT HAVE_ARCH_AUDITSYSCALL + bool Enable system-call auditing support (not recommended) + depends on AUDIT HAVE_ARCH_AUDITSYSCALL STAGING As it doesn't actually move any code into drivers/staging/, and I have no TODO list that needs to be resolved in order to get it out of staging (other than your list above), I'd prefer it not to take on the STAGING mark. But BROKEN is fine with me, that should wake people up to fix it or just drop it :) thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
