linux-kernel - Re: [PATCH] x86, AMD: Correct F15h IC aliasing issue

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]

Date:	Sun, 24 Jul 2011 20:30:46 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Borislav Petkov <bp@...64.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	"Przywara, Andre" <Andre.Przywara@....com>,
	"Pohlack, Martin" <Martin.Pohlack@....com>
Subject: Re: [PATCH] x86, AMD: Correct F15h IC aliasing issue


* Borislav Petkov <bp@...64.org> wrote:

> On Sun, Jul 24, 2011 at 01:39:25PM -0400, Linus Torvalds wrote:
> > On Sun, Jul 24, 2011 at 10:22 AM, Borislav Petkov <bp@...64.org> wrote:
> > >
> > >> So at a MINIMUM, I would say that this is acceptable only when the
> > >> process doing the allocation hasn't got ASLR disabled.
> > >
> > > I guess I could look at randomize_va_space before enabling it.
> > 
> > That's not what I meant - I meant the per-process PF_RANDOMIZE and
> > ADDR_NO_RANDOMIZE personality flags (although the global
> > "randomize_va_space" thing obviously is one input to that too)
> > 
> > In fact, if 99% of your problem is ASLR-induced, might I suggest just
> > making the whole thing a tweak to ASLR instead, and not use ASLR for
> > bits 14:12? That should be fundamentally much safer: it doesn't change
> > any semantics at all, it just makes for slightly less random bits to
> > be used.
> > 
> > So I really think that you might be *much* better off just changing
> > mmap_rnd(), and nothing else. Just make *that* mask off the three low
> > bits of the random address, ie something like
> > 
> >   diff --git a/arch/x86/mm/mmap.c b/arch/x86/mm/mmap.c
> >   index 1dab5194fd9d..6b62ab5a5ae1 100644
> >   --- a/arch/x86/mm/mmap.c
> >   +++ b/arch/x86/mm/mmap.c
> >   @@ -90,6 +90,9 @@ static unsigned long mmap_rnd(void)
> >                           rnd = (long)get_random_int() % (1<<8);
> >                   else
> >                           rnd = (long)(get_random_int() % (1<<28));
> >   +
> >   +               if (avoid_aliasing_in_bits_14_12)
> >   +                       rnd &= ~7;
> >           }
> >           return rnd << PAGE_SHIFT;
> >    }
> > 
> > would be fundamentally very safe - it would already take all our
> > current anti-randomization code into account.
> > 
> > No?
> 
> Hehe, we had that idea initially. However, the special 1% case I was
> hinting at is this:
> 
> process P0, mapping libraries A, B, C
> 
> and
> 
> process P1, mapping libraries A, C
> 
> Library C ends up possibly with aliasing VAs and there's the 
> problem again. [...]

Well, since all library positions are randomized, and the quirk masks 
out bits 12,13,14, all libraries that are not explicitly fix-mapped 
will end up on a 32K granular VA address.

So i don't think this is an issue.

Also, in practice on most distros most libraries will be prelinked to 
the same address in all processes.

Thanks,

	Ingo
--
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/