linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Dave Hansen <dave@sr71.net>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: hpa@zytor.com, mingo@redhat.com, x86@kernel.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linux-ia64@vger.kernel.org, linux-mips@linux-mips.org,
	qiaowei.ren@intel.com, dave.hansen@linux.intel.com
Subject: Re: [PATCH 10/11] x86, mpx: cleanup unused bound tables
Date: Thu, 13 Nov 2014 07:29:05 -0800	[thread overview]
Message-ID: <5464CE41.2090601@sr71.net> (raw)
In-Reply-To: <alpine.DEB.2.11.1411131541520.3935@nanos>

On 11/13/2014 06:55 AM, Thomas Gleixner wrote:
> On Wed, 12 Nov 2014, Dave Hansen wrote:
>> +/*
>> + * Get the base of bounds tables pointed by specific bounds
>> + * directory entry.
>> + */
>> +static int get_bt_addr(struct mm_struct *mm,
>> +			long __user *bd_entry, unsigned long *bt_addr)
>> +{
>> +	int ret;
>> +	int valid;
>> +
>> +	if (!access_ok(VERIFY_READ, (bd_entry), sizeof(*bd_entry)))
>> +		return -EFAULT;
>> +
>> +	while (1) {
>> +		int need_write = 0;
>> +
>> +		pagefault_disable();
>> +		ret = get_user(*bt_addr, bd_entry);
>> +		pagefault_enable();
>> +		if (!ret)
>> +			break;
>> +		if (ret == -EFAULT)
>> +			ret = mpx_resolve_fault(bd_entry, need_write);
>> +		/*
>> +		 * If we could not resolve the fault, consider it
>> +		 * userspace's fault and error out.
>> +		 */
>> +		if (ret)
>> +			return ret;
>> +	}
>> +
>> +	valid = *bt_addr & MPX_BD_ENTRY_VALID_FLAG;
>> +	*bt_addr &= MPX_BT_ADDR_MASK;
>> +
>> +	/*
>> +	 * When the kernel is managing bounds tables, a bounds directory
>> +	 * entry will either have a valid address (plus the valid bit)
>> +	 * *OR* be completely empty. If we see a !valid entry *and* some
>> +	 * data in the address field, we know something is wrong. This
>> +	 * -EINVAL return will cause a SIGSEGV.
>> +	 */
>> +	if (!valid && *bt_addr)
>> +		return -EINVAL;
>> +	/*
>> +	 * Not present is OK.  It just means there was no bounds table
>> +	 * for this memory, which is completely OK.  Make sure to distinguish
>> +	 * this from -EINVAL, which will cause a SEGV.
>> +	 */
>> +	if (!valid)
>> +		return -ENOENT;
> 
> So here you have the extra -ENOENT return value, but at the
> direct/indirect call sites you ignore -EINVAL or everything.

I've gone and audited the call sites and cleaned this up a bit.

>> +static int mpx_unmap_tables(struct mm_struct *mm,
>> +		unsigned long start, unsigned long end)
> 
>> +	ret = unmap_edge_bts(mm, start, end);
>> +	if (ret == -EFAULT)
>> +		return ret;
> 
> So here you ignore EINVAL despite claiming that it will cause a
> SIGSEGV. So this should be:
> 
> 	switch (ret) {
> 	case 0:
> 	case -ENOENT:	break;
> 	default:	return ret;
> 	}
> 
>> +	for (bd_entry = bde_start + 1; bd_entry < bde_end; bd_entry++) {
>> +		ret = get_bt_addr(mm, bd_entry, &bt_addr);
>> +		/*
>> +		 * If we encounter an issue like a bad bounds-directory
>> +		 * we should still try the next one.
>> +		 */
>> +		if (ret)
>> +			continue;
> 
> You ignore all error returns. 

That was somewhat intentional with the idea that if we have a problem in
the middle of a large unmap we should attempt to complete the unmap.
But, I've changed my mind.  If we have any kind of validity issue, we
should just SIGSEGV and not attempt to keep unmapping things.  I've
updated the patch.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2014-11-13 15:29 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-12 17:04 [PATCH 00/11] [v10] Intel MPX support Dave Hansen
2014-11-12 17:04 ` [PATCH 01/11] x86, mpx: rename cfg_reg_u and status_reg Dave Hansen
2014-11-12 17:04 ` [PATCH 02/11] mpx: extend siginfo structure to include bound violation information Dave Hansen
2014-11-12 17:04 ` [PATCH 03/11] mips: sync struct siginfo with general version Dave Hansen
2014-11-12 17:04 ` [PATCH 04/11] ia64: " Dave Hansen
2014-11-12 17:04 ` [PATCH 05/11] x86, mpx: add MPX to disaabled features Dave Hansen
2014-11-12 17:05 ` [PATCH 06/11] x86, mpx: introduce VM_MPX to indicate that a VMA is MPX specific Dave Hansen
2014-11-12 17:05 ` [PATCH 07/11] x86, mpx: add MPX-specific mmap interface Dave Hansen
2014-11-12 17:05 ` [PATCH 08/11] x86, mpx: [new code] decode MPX instruction to get bound violation information Dave Hansen
2014-11-13 13:51   ` Thomas Gleixner
2014-11-12 17:05 ` [PATCH 09/11] x86, mpx: on-demand kernel allocation of bounds tables Dave Hansen
2014-11-13 14:29   ` Thomas Gleixner
2014-11-12 17:05 ` [PATCH 10/11] x86, mpx: cleanup unused bound tables Dave Hansen
2014-11-13 14:55   ` Thomas Gleixner
2014-11-13 15:29     ` Dave Hansen [this message]
2014-11-12 17:05 ` [PATCH 11/11] x86, mpx: add documentation on Intel MPX Dave Hansen
2014-11-14 15:18 [PATCH 00/11] [v11] Intel MPX support Dave Hansen
2014-11-14 15:18 ` [PATCH 10/11] x86, mpx: cleanup unused bound tables Dave Hansen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5464CE41.2090601@sr71.net \
    --to=dave@sr71.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@redhat.com \
    --cc=qiaowei.ren@intel.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox