From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753549AbbC3S6K (ORCPT <rfc822;w@1wt.eu>);
	Mon, 30 Mar 2015 14:58:10 -0400
Received: from www.sr71.net ([198.145.64.142]:56561 "EHLO blackbird.sr71.net"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1753530AbbC3S6F (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 30 Mar 2015 14:58:05 -0400
Message-ID: <55199CBC.2060008@sr71.net>
Date: Mon, 30 Mar 2015 11:58:04 -0700
From: Dave Hansen <dave@sr71.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Borislav Petkov <bp@alien8.de>
CC: linux-kernel@vger.kernel.org, x86@kernel.org, tglx@linutronix.de,
        dave.hansen@linux.intel.com
Subject: Re: [PATCH 15/17] x86, mpx: do 32-bit-only cmpxchg for 32-bit apps
References: <20150326183327.64807530@viggo.jf.intel.com> <20150326183353.A2A5B371@viggo.jf.intel.com> <20150327172914.GE5517@pd.tnic> <55159E89.5090007@sr71.net> <20150328083928.GA17284@pd.tnic>
In-Reply-To: <20150328083928.GA17284@pd.tnic>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 03/28/2015 01:39 AM, Borislav Petkov wrote:
> AFAICT, in this case, we return only a 32-bit value and don't touch
> the upper 32 bits of actual_old_val which might be a problem if the
> assumptions of the callers is that the whole unsigned long is being
> changed.

The suggestion to just drop in the futex code does not work for just
that reason.

We do this:

static int unmap_single_bt(struct mm_struct *mm,
{
...
	unsigned long uninitialized_var(actual_old_val);

	ret = mpx_cmpxchg_bd_entry(mm, &actual_old_val,
                                bd_entry, bt_addr, cleared_bd_entry);

and then check:

        if (actual_old_val != expected_old_val) {

If we do not touch the upper 32-bits of 'actual_old_val', then we might
end up with stack gunk in there.  The other caller of
mpx_cmpxchg_bd_entry() is OK since it initializes its 'actual_old_val'.

So, I don't think it will work as you've written.  We need to somehow
ensure that the upper 32-bits match the upper 32-bits of
'expected_old_val' which will always be 0's for a 32-bit app.

So, yeah, it's ugly.  You got me.  But all the 64/32-bit conversions are
done out in the open and it's obvious what's going on.  It is also
_tested_ and works.

I'd really like to keep it the way it is.