linux-kernel - Re: [PATCH v2 0/4] x86: sigcontext fixes, again

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: <1446483683.20657.189.camel@hpe.com>
Date:	Mon, 02 Nov 2015 10:01:23 -0700
From:	Toshi Kani <toshi.kani@....com>
To:	Stas Sergeev <stsp@...t.ru>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Toshi Kani <toshi.kani@...com>, Ingo Molnar <mingo@...nel.org>
Cc:	Andy Lutomirski <luto@...capital.net>,
	Andy Lutomirski <luto@...nel.org>, X86 ML <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Brian Gerst <brgerst@...il.com>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Borislav Petkov <bp@...en8.de>,
	Stas Sergeev <stsp@...rs.sourceforge.net>
Subject: Re: [PATCH v2 0/4] x86: sigcontext fixes, again

On Sat, 2015-10-31 at 14:58 +0300, Stas Sergeev wrote:
> 29.10.2015 01:51, Toshi Kani пишет:
> > On Wed, 2015-10-28 at 13:22 -0600, Toshi Kani wrote:
> > > On Wed, 2015-10-28 at 10:34 -0600, Toshi Kani wrote:

:

> > > I looked at the dosemu code and was able to reproduce the issue with a
> > > test program.  This problem happens when mremap() to /dev/mem (or PFNMAP)
> > > is called with MREMAP_FIXED.
> > > 
> > > In this case, mremap calls move_vma(), which first calls 
> > > move_page_tables() to remap the translation and then calls do_munmap() to 
> > > remove the original mapping.  Hence, when untrack_pfn() is called from 
> > > do_munmap(), the original map is already removed, and follow_phys() fails 
> > > with the !pte_present() check.
> > > 
> > > I think there are a couple of issues:
> > >   - If untrack_pfn() ignores an error from follow_phys() and skips
> > > free_pfn_range(), PAT continues to track the original map that is removed.
> > >   - untrack_pfn() calls free_pfn_range() to untrack a given free range.
> > >   However, rbt_memtype_erase() requires the free range match exactly to 
> > > the tracked range.  This does not support mremap, which needs to free up
> > > part of the tracked range.
> > >   - PAT does not track a new translation specified by mremap() with 
> > > MREMAP_FIXED.
> > Thinking further, I think the 1st and 3rd items are non-issues.  mremap 
> > remaps virtual address, but keeps the same cache type and pfns.  So, PAT 
> > does not have to change the tracked pfns in this case.  The 2nd item is 
> > still a problem, though.
> Hello Toshi, thanks for your analysis.
> Now as you do not seem to be preparing a fix, how
> about attaching your test-case to the bug-report for
> others to re-use? Or maybe you can even make it a
> part of the kernel's test suit - I suppose this will help.

I can work on the fix, but I did not think we needed to rush on it since this
issue exists for a long time.  Can we target it to 4.4-rcX and then cc to
stables?

As for the test, it might be tricky to make it run on any platforms since it
needs to mmap/mremap a non-RAM range.  It could just map a reserved range
randomly, but I chose a range manually which I know is safe to map & read/write
on my platform in my test.

Thanks,
-Toshi
--
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/