From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Moore Subject: Audit not recording the correct syscall return value in Fedora 10? Date: Tue, 7 Apr 2009 11:34:35 -0400 Message-ID: <200904071134.35379.paul.moore@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx3.redhat.com (mx3.redhat.com [172.16.48.32]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n37FaIf8031207 for ; Tue, 7 Apr 2009 11:36:18 -0400 Received: from g5t0007.atlanta.hp.com (g5t0007.atlanta.hp.com [15.192.0.44]) by mx3.redhat.com (8.13.8/8.13.8) with ESMTP id n37FYekI025925 for ; Tue, 7 Apr 2009 11:34:40 -0400 Received: from g1t0038.austin.hp.com (g1t0038.austin.hp.com [16.236.32.44]) by g5t0007.atlanta.hp.com (Postfix) with ESMTP id 87449146BF for ; Tue, 7 Apr 2009 15:34:40 +0000 (UTC) Received: from ldl.fc.hp.com (ldl.fc.hp.com [15.11.146.30]) by g1t0038.austin.hp.com (Postfix) with ESMTP id 62A55300A8 for ; Tue, 7 Apr 2009 15:34:40 +0000 (UTC) Received: from localhost (ldl.fc.hp.com [127.0.0.1]) by ldl.fc.hp.com (Postfix) with ESMTP id 09CC339C010 for ; Tue, 7 Apr 2009 09:34:39 -0600 (MDT) Received: from ldl.fc.hp.com ([127.0.0.1]) by localhost (ldl.fc.hp.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4f3U4E0H52Kx for ; Tue, 7 Apr 2009 09:34:37 -0600 (MDT) Received: from flek.localnet (squirrel.fc.hp.com [15.11.146.57]) by ldl.fc.hp.com (Postfix) with ESMTP id A885439C009 for ; Tue, 7 Apr 2009 09:34:36 -0600 (MDT) Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com List-Id: linux-audit@redhat.com While doing some testing on Fedora 10 using the 2.6.27.5-117.fc10.x86_64 kernel I stumbled across a rather odd problem: somewhere between the end of sys_sendto() and audit_syscall_exit() the syscall's return value was changing resulting in incorrect audit records (similar problems with sys_sendmsg()). After some head scratching and debugging I determined that the %rax register was being altered at some point and if we reloaded the syscall's return value from the stack before calling audit_syscall_exit() we could avoid the problem (see patch below). I also tried to reproduce the problem with a vanilla 2.6.29.1 kernel and after several hours of testing I have yet to see the problem using the newer, upstream kernel. Taking a look at the entry_64.S files of the two kernels there appear to be a number of changes, the most significant are the tracing changes but I'm not familiar enough with this chunk of code to identify the definitive root cause (although, tracing changes does sound reasonable). Does anyone have any thoughts? diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S index a331ec3..16db517 100644 --- a/arch/x86/kernel/entry_64.S +++ b/arch/x86/kernel/entry_64.S @@ -589,8 +589,8 @@ auditsys: * masked off. */ sysret_audit: - movq %rax,%rsi /* second arg, syscall return value */ - cmpq $0,%rax /* is it < 0? */ + movq RAX-ARGOFFSET(%rsp),%rsi /* second arg, syscall return value */ + cmpq $0,%rsi /* is it < 0? */ setl %al /* 1 if so, 0 if not */ movzbl %al,%edi /* zero-extend that into %edi */ inc %edi /* first arg, 0->1(AUDITSC_SUCCESS), 1->2(AUDITSC_FAILURE) */ -- paul moore linux @ hp