Patches 1 and 2 I applied for 3.10, but I'd really like to have someone who
knows PPC ack 3 and 4. Especially if there is a hope that it goes through my
tree...
Link to original messages for your ease of review...
http://marc.info/?l=linux-kernel&m=135768892320439&w=2
http://marc.info/?l=linux
For all arches which support audit implement syscall_get_arch()
They are all pretty easy and straight forward, stolen from how the call
to audit_syscall_entry() determines the arch.
Signed-off-by: Eric Paris
Cc: linux-i...@vger.kernel.org
Cc: microblaze-ucli...@itee.uq.edu.au
Cc: linux-m
We have a function where the arch can be queried, syscall_get_arch().
So rather than have every single piece of arch specific code use and/or
duplicate syscall_get_arch(), just have the audit code use the
syscall_get_arch() code.
Signed-off-by: Eric Paris
Cc: linux-al...@vger.kernel.org
Cc
On Wed, 2014-03-19 at 15:19 -0700, Matt Turner wrote:
> On Wed, Mar 19, 2014 at 3:04 PM, Eric Paris wrote:
> > For all arches which support audit implement syscall_get_arch()
>
> support audit -- is that AUDIT_ARCH? If so, alpha gained support
> recently, so I think this pat
[dropping microblaze and roland]
lOn Fri, 2011-05-13 at 14:10 +0200, Ingo Molnar wrote:
> * James Morris wrote:
> It is a simple and sensible security feature, agreed? It allows most code to
> run well and link to countless libraries - but no access to other files is
> allowed.
It's simple en
[dropping microblaze and roland]
On Fri, 2011-05-13 at 15:18 +0200, Ingo Molnar wrote:
> * Peter Zijlstra wrote:
>
> > On Fri, 2011-05-13 at 14:54 +0200, Ingo Molnar wrote:
> > > I think the sanest semantics is to run all active callbacks as well.
> > >
> > > For example if this is used for thr
On Fri, 2011-05-13 at 17:23 +0200, Peter Zijlstra wrote:
> On Fri, 2011-05-13 at 11:10 -0400, Eric Paris wrote:
> > Then again, I certainly don't see a
> > reason that this syscall hardening patch should be held up while a whole
> > new concept in computer security is c
].
Signed-off-by: Eric Paris
---
arch/ia64/include/asm/ptrace.h| 10 +-
arch/ia64/kernel/ptrace.c |9 +
arch/microblaze/include/asm/ptrace.h |2 ++
arch/microblaze/kernel/ptrace.c |3 +--
arch/mips/include/asm/ptrace.h
On 06/02/2011 06:32 PM, Richard Weinberger wrote:
> Am Donnerstag 02 Juni 2011, 23:04:58 schrieb Eric Paris:
>> b/arch/um/sys-i386/shared/sysdep/ptrace.h index d50e62e..ef5c310 100644
>> --- a/arch/um/sys-i386/shared/sysdep/ptrace.h
>> +++ b/arch/um/sys-i386/shared/sysdep/
On 06/02/2011 07:00 PM, Tony Luck wrote:
>> But there seems to be another problem.
>> Why is pt_regs of type void *?
>>
>> gcc complains:
>> In file included from include/linux/fsnotify.h:15:0,
>> from include/linux/security.h:26,
>> from init/main.c:32:
>> include/l
is macro, kretprobe_example.c, won't notice and it makes
the value signed consistently for the audit functions across all archs.
Signed-off-by: Eric Paris
Acked-by: Acked-by: H. Peter Anvin [for x86 portion]
---
arch/ia64/include/asm/ptrace.h| 13 -
arch/ia64/ke
On Tue, 2011-06-07 at 19:19 +0200, Oleg Nesterov wrote:
> On 06/03, Eric Paris wrote:
> >
> > The audit system previously expected arches calling to audit_syscall_exit to
> > supply as arguments if the syscall was a success and what the return code
> > was.
>
On Wed, 2011-06-08 at 18:36 +0200, Oleg Nesterov wrote:
> On 06/07, Eric Paris wrote:
> >
> > On Tue, 2011-06-07 at 19:19 +0200, Oleg Nesterov wrote:
> > >
> > > With or without this patch, can't we call audit_syscall_exit() twice
> > > if there i
always positive so the regs_return_value(), much like ia64 makes it negative
before calling the audit code when appropriate.
Signed-off-by: Eric Paris
Acked-by: H. Peter Anvin [for x86 portion]
Acked-by: Tony Luck [for ia64]
Acked-by: Richard Weinberger [for uml]
Acked-by: David S. Miller [for sparc]
Acked-
14 matches
Mail list logo
