linux-kernel - Re: [uClinux-dev] [PATCH 5/7] NOMMU: Avoiding duplicate icache flushes of shared maps

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20091215004143.GA15785@shareable.org>
Date:	Tue, 15 Dec 2009 00:41:43 +0000
From:	Jamie Lokier <jamie@...reable.org>
To:	uClinux development list <uclinux-dev@...inux.org>
Cc:	vapier.adi@...il.com, lethal@...ux-sh.org, jie.zhang@...log.com,
	stefani@...bold.net, gerg@...pgear.com,
	linux-kernel@...r.kernel.org
Subject: Re: [uClinux-dev] [PATCH 5/7] NOMMU: Avoiding duplicate icache flushes of shared maps

David Howells wrote:
> From: Mike Frysinger <vapier.adi@...il.com>
> 
> When working with FDPIC, there are many shared mappings of read-only code
> regions between applications (the C library, applet packages like busybox,
> etc.), but the current do_mmap_pgoff() function will issue an icache flush
> whenever a VMA is added to an MM instead of only doing it when the map is
> initially created.
> 
> @@ -1354,10 +1355,14 @@ unsigned long do_mmap_pgoff(struct file *file,
>  share:
>  	add_vma_to_mm(current->mm, vma);
>  
> -	up_write(&nommu_region_sem);
> +	/* we flush the region from the icache only when the first executable
> +	 * mapping of it is made  */
> +	if (vma->vm_flags & VM_EXEC && !region->vm_icache_flushed) {
> +		flush_icache_range(region->vm_start, region->vm_end);
> +		region->vm_icache_flushed = true;
> +	}
>  
> -	if (prot & PROT_EXEC)
> -		flush_icache_range(result, result + len);
> +	up_write(&nommu_region_sem);
>  
>  	kleave(" = %lx", result);
>  	return result;

This looks like it won't work in the following sequence:

    process A maps MAP_SHARED, PROT_READ|PROT_EXEC (flushes icache)
    process B maps MAP_SHARED, PROT_READ|PROT_WRITE
        and proceeds to modify the data
    process C maps MAP_SHARED, PROT_READ|PROT_EXEC (no icache flush)

On a possibly related note:

What about icache flushes in these cases:

When using mprotect() PROT_READ|PROT_WRITE -> PROT_READ|PROT_EXEC,
e.g. as an FDPIC implementation may do when updating PLT entries.

And when calling msync(), like this:

    process A maps MAP_SHARED, PROT_READ|PROT_EXEC (flushes icache)
    process B maps MAP_SHARED, PROT_READ|PROT_WRITE
        and proceeds to modify the data
    process A calls msync()
        and proceeds to execute the modified contents

Do you think the mprotect() and msync() calls should flush icache in
those cases?

If seen arguments for it, and arguments that the executing process can
be expected to explicitly flush icache itself in those cases because
it knows what it is doing.  (Personally I lean towards the kernel
should be doing it.  IRIX interestingly offers both alternatives, with
a PROT_EXEC_NOFLUSH).

But in the first example above, I don't see how process C could be
expected to know it must flush icache, and process B could just be an
"optimised with writable mmap" file copy, so it shouldn't have
responsibility for icache either.

Or is icache fully flushed on every context switch on all nommu
architectures anyway, and defined to do so?

-- Jamie

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/