Re: [PATCH] audit: return on memory error to avoid null pointer dereference

I think if we went back and looked at history we'd see that all of the code originally had none of the if(!ab) checks after allocation and they just sorta slowly crept in over time. I prefer this pattern, but it used to be the opposite everywhere. On Wed, 2018-02-21 at 19:02 -0500, Paul Moore

Re: [PATCH] audit: return on memory error to avoid null pointer dereference

I think if we went back and looked at history we'd see that all of the code originally had none of the if(!ab) checks after allocation and they just sorta slowly crept in over time. I prefer this pattern, but it used to be the opposite everywhere. On Wed, 2018-02-21 at 19:02 -0500, Paul Moore

Re: RFC(v2): Audit Kernel Container IDs

On Sat, 2017-12-09 at 10:28 -0800, Casey Schaufler wrote: > On 12/9/2017 2:20 AM, Micka�l Sala�n wrote: > > What about automatically create > > and assign an ID to a process when it enters a namespace different > > than > > one of its parent process? This delegates the (permission) > >

Re: RFC(v2): Audit Kernel Container IDs

On Sat, 2017-12-09 at 10:28 -0800, Casey Schaufler wrote: > On 12/9/2017 2:20 AM, Micka�l Sala�n wrote: > > What about automatically create > > and assign an ID to a process when it enters a namespace different > > than > > one of its parent process? This delegates the (permission) > >

Re: [PATCH 4/4] kernel:audit.c fixed a coding style issue

On Tue, 2017-02-28 at 21:49 +, Joan Jani wrote: > This patch fixes the following checkpath.pl warning >  WARNING: Block comments use a trailing */ on a separate line > > like > > kernel/audit.c:135: WARNING: Block comments use a trailing */ on a > separate line > kernel/audit.c:170: WARNING:

Re: [PATCH 4/4] kernel:audit.c fixed a coding style issue

On Tue, 2017-02-28 at 21:49 +, Joan Jani wrote: > This patch fixes the following checkpath.pl warning >  WARNING: Block comments use a trailing */ on a separate line > > like > > kernel/audit.c:135: WARNING: Block comments use a trailing */ on a > separate line > kernel/audit.c:170: WARNING:

Re: [PATCH 00/46] SELinux: Fine-tuning for several function implementations

All of the patches look good to me except most of those which change the handling of `rc=`. I have a personal style preference for rc = -ENOMEM; val = kalloc(); if (!val) goto err; vs val = kalloc(); if (!val) { rc = -ENOMEM; goto err; } because it saves 1 line and I think the compiler

Re: [PATCH 00/46] SELinux: Fine-tuning for several function implementations

All of the patches look good to me except most of those which change the handling of `rc=`. I have a personal style preference for rc = -ENOMEM; val = kalloc(); if (!val) goto err; vs val = kalloc(); if (!val) { rc = -ENOMEM; goto err; } because it saves 1 line and I think the compiler

Re: [PATCH V2] audit: log 32-bit socketcalls

On Fri, 2017-01-13 at 10:06 -0500, Richard Guy Briggs wrote: > On 2017-01-13 09:42, Eric Paris wrote: > > On Fri, 2017-01-13 at 04:51 -0500, Richard Guy Briggs wrote: > > > diff --git a/include/linux/audit.h b/include/linux/audit.h > > > index 9d4443f..43d8003 10064

Re: [PATCH V2] audit: log 32-bit socketcalls

On Fri, 2017-01-13 at 10:06 -0500, Richard Guy Briggs wrote: > On 2017-01-13 09:42, Eric Paris wrote: > > On Fri, 2017-01-13 at 04:51 -0500, Richard Guy Briggs wrote: > > > diff --git a/include/linux/audit.h b/include/linux/audit.h > > > index 9d4443f..43d8003 10064

Re: [PATCH V2] audit: log 32-bit socketcalls

On Fri, 2017-01-13 at 04:51 -0500, Richard Guy Briggs wrote: > 32-bit socketcalls were not being logged by audit on x86_64 systems. > Log them.  This is basically a duplicate of the call from > net/socket.c:sys_socketcall(), but it addresses the impedance > mismatch > between 32-bit userspace

Re: [PATCH V2] audit: log 32-bit socketcalls

On Fri, 2017-01-13 at 04:51 -0500, Richard Guy Briggs wrote: > 32-bit socketcalls were not being logged by audit on x86_64 systems. > Log them.  This is basically a duplicate of the call from > net/socket.c:sys_socketcall(), but it addresses the impedance > mismatch > between 32-bit userspace

Re: [PATCH] Honor mmap_min_addr with the actual minimum

On Wed, 2016-05-11 at 14:54 +0200, Hector Marco-Gisbert wrote: > > El 21/04/16 a las 00:12, Kees Cook escribió: > > On Tue, Apr 19, 2016 at 11:55 AM, Hector Marco-Gisbert > v.es> wrote: > > > > On Wed, Apr 6, 2016 at 12:07 PM, Hector Marco-Gisbert > > > @upv.es> wrote: > > > > >

Re: [PATCH] Honor mmap_min_addr with the actual minimum

On Wed, 2016-05-11 at 14:54 +0200, Hector Marco-Gisbert wrote: > > El 21/04/16 a las 00:12, Kees Cook escribió: > > On Tue, Apr 19, 2016 at 11:55 AM, Hector Marco-Gisbert > v.es> wrote: > > > > On Wed, Apr 6, 2016 at 12:07 PM, Hector Marco-Gisbert > > > @upv.es> wrote: > > > > > The minimum

Re: [PATCH] audit: Don't spam logs with SECCOMP_KILL/RET_ERRNO by default

ays reaches a SECCOMP_KILL or more likely > > SECCOMP_RET_ERRNO in the rule set. > > > > The seccomp auditing was originally added by Eric with > > > > commit 85e7bac33b8d5edafc4e219c7dfdb3d48e0b4e31 > > Author: Eric Paris <epa...@redhat.com> > > Dat

Re: [PATCH] audit: Don't spam logs with SECCOMP_KILL/RET_ERRNO by default

RNO in the rule set. > > > > The seccomp auditing was originally added by Eric with > > > > commit 85e7bac33b8d5edafc4e219c7dfdb3d48e0b4e31 > > Author: Eric Paris > > Date:   Tue Jan 3 14:23:05 2012 -0500 > > > >    

Re: [PATCH] inotify: hide internal kernel bits from fdinfo

Acked-by: Eric Paris On Mon, 2015-09-21 at 11:45 -0700, Dave Hansen wrote: > From: Dave Hansen > > There was a report that my patch: > > inotify: actually check for invalid bits in > sys_inotify_add_watch() > > broke CRIU. > > The reason is that CRIU lo

Re: [PATCH] inotify: hide internal kernel bits from fdinfo

Acked-by: Eric Paris <epa...@redhat.com> On Mon, 2015-09-21 at 11:45 -0700, Dave Hansen wrote: > From: Dave Hansen <dave.han...@linux.intel.com> > > There was a report that my patch: > > inotify: actually check for invalid bits in > sys_inotify_add_watch() &g

Re: [PATCH] inotify: actually check for invalid bits in sys_inotify_add_watch()

Looks fine to me. And usually akpm picks them up these days. On Wed, 2015-09-09 at 14:59 -0700, Dave Hansen wrote: > On 06/30/2015 10:36 AM, Dave Hansen wrote: > > From: Dave Hansen > > > > The comment here says that it is checking for invalid bits. But, > > the mask is *actually* checking to

Re: [PATCH] inotify: actually check for invalid bits in sys_inotify_add_watch()

Looks fine to me. And usually akpm picks them up these days. On Wed, 2015-09-09 at 14:59 -0700, Dave Hansen wrote: > On 06/30/2015 10:36 AM, Dave Hansen wrote: > > From: Dave Hansen > > > > The comment here says that it is checking for invalid bits. But, > > the

Re: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd

This is already going to be in the audit log, right? We're going to send a CONFIG_CHANGE record with old_pid == the existing auditd. I bet it gets delivered to the old auditd. But why is this a printk(KERN_WARN) ? On Mon, 2015-09-07 at 12:48 -0400, Richard Guy Briggs wrote: > Nothing prevents a

Re: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd

This is already going to be in the audit log, right? We're going to send a CONFIG_CHANGE record with old_pid == the existing auditd. I bet it gets delivered to the old auditd. But why is this a printk(KERN_WARN) ? On Mon, 2015-09-07 at 12:48 -0400, Richard Guy Briggs wrote: > Nothing prevents a

Re: Linux Firmware Signing

On Mon, 2015-08-31 at 22:52 -0400, Paul Moore wrote: > On Fri, Aug 28, 2015 at 10:03 PM, Luis R. Rodriguez > wrote: > > On Fri, Aug 28, 2015 at 06:26:05PM -0400, Paul Moore wrote: > > > On Fri, Aug 28, 2015 at 7:20 AM, Roberts, William C > > > wrote: > > > > Even triggered updates make sense,

Re: Linux Firmware Signing

On Mon, 2015-08-31 at 22:52 -0400, Paul Moore wrote: > On Fri, Aug 28, 2015 at 10:03 PM, Luis R. Rodriguez > wrote: > > On Fri, Aug 28, 2015 at 06:26:05PM -0400, Paul Moore wrote: > > > On Fri, Aug 28, 2015 at 7:20 AM, Roberts, William C > > > wrote:

Re: [PATCH V6 4/4] audit: avoid double copying the audit_exe path string

I have to admit, I'm partial to not merging this (with the other patches). Changing object lifetimes in what i seem to remember is long standing code (auditfilter, not auditexe) seems to me like something we really would want to be git bisectable, not mushed with an unrelated feature addition.

Re: [PATCH V6 4/4] audit: avoid double copying the audit_exe path string

I have to admit, I'm partial to not merging this (with the other patches). Changing object lifetimes in what i seem to remember is long standing code (auditfilter, not auditexe) seems to me like something we really would want to be git bisectable, not mushed with an unrelated feature addition.

Re: [RFCv2][PATCH 1/7] fs: optimize inotify/fsnotify code for unwatched files

ere will both be nothing to notify for > *and* implies that there is no need for clearing the ignore > mask. > > This patch gave a 13.8% speedup in writes/second on my test, > which is an improvement from the 10.8% that I saw with the > last version. > > Signed-off-by: Dav

Re: [RFCv2][PATCH 1/7] fs: optimize inotify/fsnotify code for unwatched files

-foundation.org Cc: Jan Kara j...@suse.cz Cc: Al Viro v...@zeniv.linux.org.uk Cc: Eric Paris epa...@redhat.com Cc: John McCutchan j...@johnmccutchan.com Cc: Robert Love rl...@rlove.org Cc: Tim Chen tim.c.c...@linux.intel.com Cc: Andi Kleen a...@linux.intel.com Cc: linux-kernel@vger.kernel.org --- b

Re: [PATCH v2] selinux: reduce locking overhead in inode_free_security()

On Sat, 2015-06-13 at 10:35 +0300, Yury wrote: > > On 13.06.2015 01:35, Waiman Long wrote: > > On 06/12/2015 08:31 AM, Stephen Smalley wrote: > > > On 06/12/2015 02:26 AM, Raghavendra K T wrote: > > > > On 06/12/2015 03:01 AM, Waiman Long wrote: > > > > > The inode_free_security() function just

Re: [PATCH v2] selinux: reduce locking overhead in inode_free_security()

On Sat, 2015-06-13 at 10:35 +0300, Yury wrote: On 13.06.2015 01:35, Waiman Long wrote: On 06/12/2015 08:31 AM, Stephen Smalley wrote: On 06/12/2015 02:26 AM, Raghavendra K T wrote: On 06/12/2015 03:01 AM, Waiman Long wrote: The inode_free_security() function just took the

Re: [PATCH v2] selinux: reduce locking overhead in inode_free_security()

On Fri, 2015-06-12 at 08:31 -0400, Stephen Smalley wrote: > On 06/12/2015 02:26 AM, Raghavendra K T wrote: > > On 06/12/2015 03:01 AM, Waiman Long wrote: > > > The inode_free_security() function just took the superblock's > > > isec_lock > > > before checking and trying to remove the inode

Re: [PATCH v2] selinux: reduce locking overhead in inode_free_security()

On Fri, 2015-06-12 at 08:31 -0400, Stephen Smalley wrote: On 06/12/2015 02:26 AM, Raghavendra K T wrote: On 06/12/2015 03:01 AM, Waiman Long wrote: The inode_free_security() function just took the superblock's isec_lock before checking and trying to remove the inode security struct

Re: [PATCH] Selinux/hooks.c: Fix a NULL pointer dereference caused by semop()

What kernel version was this? Didn't we have this problem and solve it upstream some time ago? IPC could be allocated with a valid security context, the ipc would be freed. the isec was free'd syncronously, but then the ipc could stick around until some rcu period or some usage flag got to 0,

Re: [PATCH] Selinux/hooks.c: Fix a NULL pointer dereference caused by semop()

What kernel version was this? Didn't we have this problem and solve it upstream some time ago? IPC could be allocated with a valid security context, the ipc would be freed. the isec was free'd syncronously, but then the ipc could stick around until some rcu period or some usage flag got to 0,

Re: fanotify bug on gdb -- hard crash

On Mon, 2014-12-29 at 13:06 +0800, ivo welch wrote: > thank you, eric. will do. I read up on it above and now understand it > better. Great let us know if it keeps giving you trouble! > the example in the man page seems somewhat misfortunate. I would use > an example that does not, by

Re: fanotify bug on gdb -- hard crash

On Mon, 2014-12-29 at 13:06 +0800, ivo welch wrote: thank you, eric. will do. I read up on it above and now understand it better. Great let us know if it keeps giving you trouble! the example in the man page seems somewhat misfortunate. I would use an example that does not, by default,

Re: fanotify bug on gdb -- hard crash

derson Fink Center for Finance and Investments > Free Finance Textbook, http://book.ivo-welch.info/ > Editor, Critical Finance Review, > http://www.critical-finance-review.org/ > > > On Mon, Dec 29, 2014 at 7:13 AM, Eric Paris wrote: > Why are you setting FAN_OPE

Re: fanotify bug on gdb -- hard crash

Why are you setting FAN_OPEN_PERM and then not responding to perm requests? Of course the system is going to appear locked, until you start responding to open events, remove that mark, or close the fanotify fd... -Eric On Fri, 2014-12-26 at 19:40 +0100, Heinrich Schuchardt wrote: > Hello Ivo, >

Re: fanotify bug on gdb -- hard crash

Why are you setting FAN_OPEN_PERM and then not responding to perm requests? Of course the system is going to appear locked, until you start responding to open events, remove that mark, or close the fanotify fd... -Eric On Fri, 2014-12-26 at 19:40 +0100, Heinrich Schuchardt wrote: Hello Ivo,

Re: fanotify bug on gdb -- hard crash

Finance Review, http://www.critical-finance-review.org/ On Mon, Dec 29, 2014 at 7:13 AM, Eric Paris epa...@redhat.com wrote: Why are you setting FAN_OPEN_PERM and then not responding to perm requests? Of course the system is going to appear locked, until

Re: linux-next 20141216 BUG: sleeping function called from invalid context at mm/slab.c:2849

On Thu, 2014-12-18 at 13:44 -0500, Richard Guy Briggs wrote: > On 14/12/18, Eric Paris wrote: > > On Thu, 2014-12-18 at 12:46 -0500, Richard Guy Briggs wrote: > > > On 14/12/18, Eric Paris wrote: > > > > On Thu, 2014-12-18 at 11:45 -0500, valdis.kletni...@vt.edu w

Re: linux-next 20141216 BUG: sleeping function called from invalid context at mm/slab.c:2849

On Thu, 2014-12-18 at 12:46 -0500, Richard Guy Briggs wrote: > On 14/12/18, Eric Paris wrote: > > On Thu, 2014-12-18 at 11:45 -0500, valdis.kletni...@vt.edu wrote: > > > On Tue, 16 Dec 2014 20:09:54 -0500, Valdis Kletnieks said: > > > > Spotted these two while b

Re: linux-next 20141216 BUG: sleeping function called from invalid context at mm/slab.c:2849

On Thu, 2014-12-18 at 11:45 -0500, valdis.kletni...@vt.edu wrote: > On Tue, 16 Dec 2014 20:09:54 -0500, Valdis Kletnieks said: > > > Spotted these two while booting single-user on 20141216. 20141208 > > doesn't throw these, so it's something in the last week or so.. > > Gaah! Turns out that

Re: linux-next 20141216 BUG: sleeping function called from invalid context at mm/slab.c:2849

On Thu, 2014-12-18 at 11:45 -0500, valdis.kletni...@vt.edu wrote: On Tue, 16 Dec 2014 20:09:54 -0500, Valdis Kletnieks said: Spotted these two while booting single-user on 20141216. 20141208 doesn't throw these, so it's something in the last week or so.. Gaah! Turns out that 20141208

Re: linux-next 20141216 BUG: sleeping function called from invalid context at mm/slab.c:2849

On Thu, 2014-12-18 at 12:46 -0500, Richard Guy Briggs wrote: On 14/12/18, Eric Paris wrote: On Thu, 2014-12-18 at 11:45 -0500, valdis.kletni...@vt.edu wrote: On Tue, 16 Dec 2014 20:09:54 -0500, Valdis Kletnieks said: Spotted these two while booting single-user on 20141216. 20141208

Re: linux-next 20141216 BUG: sleeping function called from invalid context at mm/slab.c:2849

On Thu, 2014-12-18 at 13:44 -0500, Richard Guy Briggs wrote: On 14/12/18, Eric Paris wrote: On Thu, 2014-12-18 at 12:46 -0500, Richard Guy Briggs wrote: On 14/12/18, Eric Paris wrote: On Thu, 2014-12-18 at 11:45 -0500, valdis.kletni...@vt.edu wrote: On Tue, 16 Dec 2014 20:09:54

Re: linux-next 20141216 BUG: sleeping function called from invalid context at mm/slab.c:2849

I haven't looked into it, but I'd place my first bet on the audit multicast code... Richard? On Tue, 2014-12-16 at 20:09 -0500, Valdis Kletnieks wrote: > Not sure who's to blame here, but I'm tending towards selinux based on > who was holding the locks... > > Spotted these two while booting

Re: linux-next 20141216 BUG: sleeping function called from invalid context at mm/slab.c:2849

I haven't looked into it, but I'd place my first bet on the audit multicast code... Richard? On Tue, 2014-12-16 at 20:09 -0500, Valdis Kletnieks wrote: Not sure who's to blame here, but I'm tending towards selinux based on who was holding the locks... Spotted these two while booting

Re: sparc: Clashing values for O_PATH and FMODE_NONOTIFY?

On Thu, 2014-11-20 at 12:12 +, David Drysdale wrote: > [+linux-fsdevel, without the typo this time] > > On Wed, Nov 19, 2014 at 8:30 PM, David Miller wrote: > > From: David Drysdale > > Date: Tue, 18 Nov 2014 13:13:51 + > > > >> Hi folks, > >> > >> It looks like the value for O_PATH on

Re: sparc: Clashing values for O_PATH and FMODE_NONOTIFY?

On Thu, 2014-11-20 at 12:12 +, David Drysdale wrote: [+linux-fsdevel, without the typo this time] On Wed, Nov 19, 2014 at 8:30 PM, David Miller da...@davemloft.net wrote: From: David Drysdale drysd...@google.com Date: Tue, 18 Nov 2014 13:13:51 + Hi folks, It looks like the

Re: [PATCH] audit_tree: keep inode pinned

[adding paul and richard] On Tue, 2014-11-04 at 11:27 +0100, Miklos Szeredi wrote: > From: Miklos Szeredi > > Audit rules disappear when an inode they watch is evicted from the cache. > This is likely not what we want. > > The guilty commit is "fsnotify: allow marks to not pin inodes in core",

Re: [PATCH] audit_tree: keep inode pinned

[adding paul and richard] On Tue, 2014-11-04 at 11:27 +0100, Miklos Szeredi wrote: From: Miklos Szeredi mszer...@suse.cz Audit rules disappear when an inode they watch is evicted from the cache. This is likely not what we want. The guilty commit is fsnotify: allow marks to not pin inodes

Re: [PATCH] i386/audit: stop scribbling on the stack frame

On Mon, 2014-10-27 at 21:52 +0100, Thomas Gleixner wrote: > On Sun, 26 Oct 2014, Richard Guy Briggs wrote: > > diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S > > index b553ed8..344b63f 100644 > > --- a/arch/x86/kernel/entry_32.S > > +++ b/arch/x86/kernel/entry_32.S > > @@

Re: [PATCH] i386/audit: stop scribbling on the stack frame

On Mon, 2014-10-27 at 10:02 -0700, H. Peter Anvin wrote: > On 10/27/2014 06:55 AM, Eric Paris wrote: > > My patch was already committed to the -tip urgent branch. I believe any > > optimization should be based on that branch, Richard. If you are trying > > to wrangle e

Re: [PATCH] i386/audit: stop scribbling on the stack frame

t; After the call to __audit_syscall_entry all we need to do is get that > now useless junk off the stack (pair of pops) and reload %eax with the > original syscall so other stuff can keep going about it's business. > > Reported-by: Paulo Zanoni > Signed-off-by: Eric Paris > S

Re: [PATCH] i386/audit: stop scribbling on the stack frame

that now useless junk off the stack (pair of pops) and reload %eax with the original syscall so other stuff can keep going about it's business. Reported-by: Paulo Zanoni przan...@gmail.com Signed-off-by: Eric Paris epa...@redhat.com Signed-off-by: Richard Guy Briggs r...@redhat.com Cc

Re: [PATCH] i386/audit: stop scribbling on the stack frame

On Mon, 2014-10-27 at 10:02 -0700, H. Peter Anvin wrote: On 10/27/2014 06:55 AM, Eric Paris wrote: My patch was already committed to the -tip urgent branch. I believe any optimization should be based on that branch, Richard. If you are trying to wrangle every bit of speed out

Re: [PATCH] i386/audit: stop scribbling on the stack frame

On Mon, 2014-10-27 at 21:52 +0100, Thomas Gleixner wrote: On Sun, 26 Oct 2014, Richard Guy Briggs wrote: diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S index b553ed8..344b63f 100644 --- a/arch/x86/kernel/entry_32.S +++ b/arch/x86/kernel/entry_32.S @@ -447,15

[tip:x86/urgent] i386/audit: stop scribbling on the stack frame

Commit-ID: 26c2d2b39128adba276d140eefa2745591b88536 Gitweb: http://git.kernel.org/tip/26c2d2b39128adba276d140eefa2745591b88536 Author: Eric Paris AuthorDate: Thu, 23 Oct 2014 00:04:03 -0400 Committer: H. Peter Anvin CommitDate: Fri, 24 Oct 2014 13:27:56 -0700 i386/audit: stop

[tip:x86/urgent] i386/audit: stop scribbling on the stack frame

Commit-ID: 26c2d2b39128adba276d140eefa2745591b88536 Gitweb: http://git.kernel.org/tip/26c2d2b39128adba276d140eefa2745591b88536 Author: Eric Paris epa...@redhat.com AuthorDate: Thu, 23 Oct 2014 00:04:03 -0400 Committer: H. Peter Anvin h...@linux.intel.com CommitDate: Fri, 24 Oct 2014 13

Re: [PATCH] i386/audit: stop scribbling on the stack frame

On Thu, 2014-10-23 at 12:20 -0700, Andy Lutomirski wrote: > On Thu, Oct 23, 2014 at 12:15 PM, Eric Paris wrote: > > On Thu, 2014-10-23 at 11:39 -0700, Andy Lutomirski wrote: > >> On 10/22/2014 09:04 PM, Eric Paris wrote: > >> > git commit b4f0d3755c5e9cc86292d5fd

Re: [PATCH] i386/audit: stop scribbling on the stack frame

On Thu, 2014-10-23 at 15:30 -0400, Eric Paris wrote: > On Thu, 2014-10-23 at 12:20 -0700, Andy Lutomirski wrote: > > On Thu, Oct 23, 2014 at 12:15 PM, Eric Paris wrote: > > > On Thu, 2014-10-23 at 11:39 -0700, Andy Lutomirski wrote: > > >> On 10/22/2014 09:04 PM,

Re: [PATCH] i386/audit: stop scribbling on the stack frame

On Thu, 2014-10-23 at 11:39 -0700, Andy Lutomirski wrote: > On 10/22/2014 09:04 PM, Eric Paris wrote: > > git commit b4f0d3755c5e9cc86292d5fd78261903b4f23d4a was very very dumb. > > It was writing over %esp/pt_regs semi-randomly on i686 with the expected > > "system can'

Re: [PATCH] i386/audit: stop scribbling on the stack frame

On Thu, 2014-10-23 at 11:39 -0700, Andy Lutomirski wrote: On 10/22/2014 09:04 PM, Eric Paris wrote: git commit b4f0d3755c5e9cc86292d5fd78261903b4f23d4a was very very dumb. It was writing over %esp/pt_regs semi-randomly on i686 with the expected system can't boot results. As noted

Re: [PATCH] i386/audit: stop scribbling on the stack frame

On Thu, 2014-10-23 at 15:30 -0400, Eric Paris wrote: On Thu, 2014-10-23 at 12:20 -0700, Andy Lutomirski wrote: On Thu, Oct 23, 2014 at 12:15 PM, Eric Paris epa...@redhat.com wrote: On Thu, 2014-10-23 at 11:39 -0700, Andy Lutomirski wrote: On 10/22/2014 09:04 PM, Eric Paris wrote: git

Re: [PATCH] i386/audit: stop scribbling on the stack frame

On Thu, 2014-10-23 at 12:20 -0700, Andy Lutomirski wrote: On Thu, Oct 23, 2014 at 12:15 PM, Eric Paris epa...@redhat.com wrote: On Thu, 2014-10-23 at 11:39 -0700, Andy Lutomirski wrote: On 10/22/2014 09:04 PM, Eric Paris wrote: git commit b4f0d3755c5e9cc86292d5fd78261903b4f23d4a was very

[PATCH] i386/audit: stop scribbling on the stack frame

_entry all we need to do is get that now useless junk off the stack (pair of pops) and reload %eax with the original syscall so other stuff can keep going about it's business. Signed-off-by: Eric Paris Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.

Re: Regression: audit: x86: drop arch from __audit_syscall_entry() interface

On Wed, 2014-10-22 at 14:43 -0700, H. Peter Anvin wrote: > On 10/22/2014 02:38 PM, Eric Paris wrote: > > > > It was sent, numerous times, to the x86 list for reviews, and lived in > > -next for 2 complete devel cycles without a complaint. I'm trying to > > get a

Re: Regression: audit: x86: drop arch from __audit_syscall_entry() interface

On Wed, 2014-10-22 at 14:43 -0700, H. Peter Anvin wrote: > On 10/22/2014 02:38 PM, Eric Paris wrote: > > > > It was sent, numerous times, to the x86 list for reviews, and lived in > > -next for 2 complete devel cycles without a complaint. I'm trying to > > get a

Re: Regression: audit: x86: drop arch from __audit_syscall_entry() interface

On Wed, 2014-10-22 at 23:36 +0200, Thomas Gleixner wrote: > On Wed, 22 Oct 2014, Eric Paris wrote: > > > That's really serious. Looking now. > > Indeed its serious. And it's even more serious as this masterpiece of > assembly wreckage was pulled in via your tree w/o hav

Re: Regression: audit: x86: drop arch from __audit_syscall_entry() interface

That's really serious. Looking now. On Wed, 2014-10-22 at 16:08 -0200, Paulo Zanoni wrote: > Hi > > (Cc'ing everybody mentioned in the original patch) > > I work for Intel, on our Linux Graphics driver - aka i915.ko - and our > QA team recently reported a regression on: > > commit

[PATCH] i386/audit: stop scribbling on the stack frame

need to do is get that now useless junk off the stack (pair of pops) and reload %eax with the original syscall so other stuff can keep going about it's business. Signed-off-by: Eric Paris epa...@redhat.com Cc: Thomas Gleixner t...@linutronix.de Cc: Ingo Molnar mi...@redhat.com Cc: H. Peter Anvin h

Re: Regression: audit: x86: drop arch from __audit_syscall_entry() interface

That's really serious. Looking now. On Wed, 2014-10-22 at 16:08 -0200, Paulo Zanoni wrote: Hi (Cc'ing everybody mentioned in the original patch) I work for Intel, on our Linux Graphics driver - aka i915.ko - and our QA team recently reported a regression on: commit

Re: Regression: audit: x86: drop arch from __audit_syscall_entry() interface

On Wed, 2014-10-22 at 23:36 +0200, Thomas Gleixner wrote: On Wed, 22 Oct 2014, Eric Paris wrote: That's really serious. Looking now. Indeed its serious. And it's even more serious as this masterpiece of assembly wreckage was pulled in via your tree w/o having an acked-by one of the x86

Re: Regression: audit: x86: drop arch from __audit_syscall_entry() interface

On Wed, 2014-10-22 at 14:43 -0700, H. Peter Anvin wrote: On 10/22/2014 02:38 PM, Eric Paris wrote: It was sent, numerous times, to the x86 list for reviews, and lived in -next for 2 complete devel cycles without a complaint. I'm trying to get an i386 system to test a fix. But yes, it's

Re: Regression: audit: x86: drop arch from __audit_syscall_entry() interface

On Wed, 2014-10-22 at 14:43 -0700, H. Peter Anvin wrote: On 10/22/2014 02:38 PM, Eric Paris wrote: It was sent, numerous times, to the x86 list for reviews, and lived in -next for 2 complete devel cycles without a complaint. I'm trying to get an i386 system to test a fix. But yes, it's

Re: [RFC][PATCH] audit: log join and part events to the read-only multicast log socket

On Tue, 2014-10-21 at 17:08 -0400, Richard Guy Briggs wrote: > On 14/10/21, Steve Grubb wrote: > > On Tuesday, October 07, 2014 03:03:14 PM Eric Paris wrote: > > > On Tue, 2014-10-07 at 14:23 -0400, Richard Guy Briggs wrote: > > > > Log the event when a client atte

Re: [PATCH V5 0/5] audit by executable name

On Tue, 2014-10-21 at 17:56 -0400, Paul Moore wrote: > * Change the audit_status.version field comment in include/uapi/linux/audit.h > to "/* audit functionality bitmap */", or similar. We can't really change > the > structure now, but the comment is fair game. Trying to think how to do

Re: [PATCH] audit: add Paul Moore to the MAINTAINERS entry

; > Signed-off-by: Paul Moore Acked-by: Eric Paris > --- > MAINTAINERS |5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index c2066f4..86c24fd 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1689,1

Re: [PATCH 2/2] fs: Support compiling out sendfile

On Tue, 2014-10-21 at 10:18 -0700, j...@joshtriplett.org wrote: > On Tue, Oct 21, 2014 at 08:37:00AM -0700, H. Peter Anvin wrote: > > On 10/20/2014 02:48 PM, Pieter Smith wrote: > > > Many embedded systems will not need this syscall, and omitting it > > > saves space. Add a new EXPERT config

Re: [PATCH 2/2] fs: Support compiling out sendfile

On Tue, 2014-10-21 at 10:18 -0700, j...@joshtriplett.org wrote: On Tue, Oct 21, 2014 at 08:37:00AM -0700, H. Peter Anvin wrote: On 10/20/2014 02:48 PM, Pieter Smith wrote: Many embedded systems will not need this syscall, and omitting it saves space. Add a new EXPERT config option

Re: [PATCH] audit: add Paul Moore to the MAINTAINERS entry

Moore pmo...@redhat.com Acked-by: Eric Paris epa...@redhat.com --- MAINTAINERS |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index c2066f4..86c24fd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1689,10 +1689,11 @@ S:Supported

Re: [PATCH V5 0/5] audit by executable name

On Tue, 2014-10-21 at 17:56 -0400, Paul Moore wrote: * Change the audit_status.version field comment in include/uapi/linux/audit.h to /* audit functionality bitmap */, or similar. We can't really change the structure now, but the comment is fair game. Trying to think how to do things

Re: [RFC][PATCH] audit: log join and part events to the read-only multicast log socket

On Tue, 2014-10-21 at 17:08 -0400, Richard Guy Briggs wrote: On 14/10/21, Steve Grubb wrote: On Tuesday, October 07, 2014 03:03:14 PM Eric Paris wrote: On Tue, 2014-10-07 at 14:23 -0400, Richard Guy Briggs wrote: Log the event when a client attempts to connect to the netlink audit

Re: [PATCH V5 0/5] audit by executable name

On Mon, 2014-10-20 at 16:25 -0400, Steve Grubb wrote: > On Thursday, October 02, 2014 11:06:51 PM Richard Guy Briggs wrote: > > This is a part of Peter Moody, my and Eric Paris' work to implement > > audit by executable name. > > Does this patch set define an AUDIT_VERSION_S

Re: [PATCH V5 0/5] audit by executable name

On Mon, 2014-10-20 at 16:25 -0400, Steve Grubb wrote: On Thursday, October 02, 2014 11:06:51 PM Richard Guy Briggs wrote: This is a part of Peter Moody, my and Eric Paris' work to implement audit by executable name. Does this patch set define an AUDIT_VERSION_SOMETHING and then set

[GIT PULL] Audit changes for 3.18

() Burn Alting (1): audit: invalid op= values for rules Eric Paris (11): audit: drop unused struct audit_rule definition SH: define syscall_get_arch() for superh UM: implement syscall_get_arch() Alpha: define syscall_get_arch() ARCH: AUDIT: implement

[GIT PULL] Audit changes for 3.18

() Burn Alting (1): audit: invalid op= values for rules Eric Paris (11): audit: drop unused struct audit_rule definition SH: define syscall_get_arch() for superh UM: implement syscall_get_arch() Alpha: define syscall_get_arch() ARCH: AUDIT: implement

Re: [PATCH 5/7] audit: remove redundant watch refcount

Having a hard time convincing myself of the next 2... Doesn't mean they're wrong or bad, but my brain isn't seeing it today... On Thu, 2014-10-02 at 22:05 -0400, Richard Guy Briggs wrote: > Remove extra layer of audit_{get,put}_watch() calls. > > Signed-off-by: Richard Guy Briggs > --- >

Re: [PATCH 4/7] audit: optimize add to parent skipping needless search and consuming parent ref

On Thu, 2014-10-02 at 22:05 -0400, Richard Guy Briggs wrote: > When parent has just been created there is no need to search for the parent in > the list. Add a parameter to skip the search Since the parent was just allocated, and thus has an empty list, this "search" is just as fast as the check

Re: [PATCH 3/7] audit: eliminate string copy for new tree rules

On Thu, 2014-10-02 at 22:05 -0400, Richard Guy Briggs wrote: > New tree rules copy the path twice and discard the intermediary copy. > > This saves one pointer at the expense of one path string copy. > > Signed-off-by: Richard Guy Briggs > --- > kernel/audit_tree.c |9 + >

Re: [PATCH 2/7] audit: cull redundancy in audit_rule_change

On Thu, 2014-10-02 at 22:05 -0400, Richard Guy Briggs wrote: > Re-factor audit_rule_change() to reduce the amount of code redundancy and > simplify the logic. > > Signed-off-by: Richard Guy Briggs > --- > kernel/auditfilter.c | 20 +++- > 1 files changed, 7 insertions(+), 13

Re: [PATCH 2/7] audit: cull redundancy in audit_rule_change

On Thu, 2014-10-02 at 22:05 -0400, Richard Guy Briggs wrote: Re-factor audit_rule_change() to reduce the amount of code redundancy and simplify the logic. Signed-off-by: Richard Guy Briggs r...@redhat.com --- kernel/auditfilter.c | 20 +++- 1 files changed, 7

Re: [PATCH 3/7] audit: eliminate string copy for new tree rules

On Thu, 2014-10-02 at 22:05 -0400, Richard Guy Briggs wrote: New tree rules copy the path twice and discard the intermediary copy. This saves one pointer at the expense of one path string copy. Signed-off-by: Richard Guy Briggs r...@redhat.com --- kernel/audit_tree.c |9 +

Re: [PATCH 4/7] audit: optimize add to parent skipping needless search and consuming parent ref

On Thu, 2014-10-02 at 22:05 -0400, Richard Guy Briggs wrote: When parent has just been created there is no need to search for the parent in the list. Add a parameter to skip the search Since the parent was just allocated, and thus has an empty list, this search is just as fast as the check

Re: [PATCH 5/7] audit: remove redundant watch refcount

Having a hard time convincing myself of the next 2... Doesn't mean they're wrong or bad, but my brain isn't seeing it today... On Thu, 2014-10-02 at 22:05 -0400, Richard Guy Briggs wrote: Remove extra layer of audit_{get,put}_watch() calls. Signed-off-by: Richard Guy Briggs r...@redhat.com

Re: [RFC][PATCH] audit: log join and part events to the read-only multicast log socket

On Tue, 2014-10-07 at 14:23 -0400, Richard Guy Briggs wrote: > Log the event when a client attempts to connect to the netlink audit multicast > socket, requiring CAP_AUDIT_READ capability, binding to the > AUDIT_NLGRP_READLOG > group. Log the disconnect too. > > Sample output: > time->Tue Oct

Re: [RFC][PATCH] audit: log join and part events to the read-only multicast log socket

On Tue, 2014-10-07 at 14:23 -0400, Richard Guy Briggs wrote: Log the event when a client attempts to connect to the netlink audit multicast socket, requiring CAP_AUDIT_READ capability, binding to the AUDIT_NLGRP_READLOG group. Log the disconnect too. Sample output: time-Tue Oct 7

Re: [PATCH v2] next: openrisc: Fix build

> ./arch/openrisc/include/asm/syscall.h: In function 'syscall_get_arch': > ./arch/openrisc/include/asm/syscall.h:77:9: error: 'EM_OPENRISC' undeclared > > Fix by moving EM_OPENRISC to include/uapi/linux/elf-em.h. > > Fixes: ce5d112827e5 ("ARCH: AUDIT: implement syscall_get_

Re: linux-next: New build failures in Sep 25 tree

On Fri, 2014-09-26 at 06:32 -0700, Guenter Roeck wrote: > On 09/26/2014 12:59 AM, Stefan Kristiansson wrote: > > On Fri, Sep 26, 2014 at 08:30:57AM +0200, Geert Uytterhoeven wrote: > >> Hi Günther, > >> > >> [cc openrisc] > >> > >> On Thu, Sep 25, 2014 at 10:25 PM, Guenter Roeck wrote: > >>> New

  1   2   3   4   5   6   >