From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751432AbcFYH2v (ORCPT ); Sat, 25 Jun 2016 03:28:51 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:58248 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751175AbcFYH2t (ORCPT ); Sat, 25 Jun 2016 03:28:49 -0400 X-IBM-Helo: d06dlp01.portsmouth.uk.ibm.com X-IBM-MailFrom: heiko.carstens@de.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org;linux-next@vger.kernel.org Date: Sat, 25 Jun 2016 09:28:42 +0200 From: Heiko Carstens To: Paul Moore Cc: Stephen Rothwell , James Morris , linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, Kees Cook , Martin Schwidefsky Subject: Re: linux-next: manual merge of the audit tree with the security tree References: <20160623141814.5512ffd1@canb.auug.org.au> <20160623060113.GA3866@osiris> <20160624054131.GA3940@osiris> <20160624152046.GB3940@osiris> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16062507-0008-0000-0000-000002925810 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16062507-0009-0000-0000-000018E03565 Message-Id: <20160625072842.GA3303@osiris> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-06-25_01:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606250086 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 24, 2016 at 12:20:52PM -0400, Paul Moore wrote: > > I'm a bit concerned about user space pointers passed as argument for compat > > tasks. These need to mask out 33 instead of 32 bits. This is of course > > system call specific and I don't know enough about audit to tell if it > > could be a problem. > > From a practical point of view I'm not sure how much of an impact that > will have as it is unlikely anyone will be doing anything useful with > those pointer values; for example, you aren't going to be inspecting a > process' memory space using just the audit log. Also, at the very > least we aren't removing any information, just adding in an extra bit > of potential junk. Anyone who does care about user space pointers in > the audit log, should have all the information the need to drop the > high bit. > > Does that sound reasonable? Yes, it does. If there should be problems because of the one extra bit that potentially contains garbage we still can look for a way to fix this. Thanks!