linux-kernel - Re: [RFC] kmemcheck: trap uses of uninitialized memory (v2)

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: <19f34abd0711290524k49628a0dja8a5a04d10253157@mail.gmail.com>
Date:	Thu, 29 Nov 2007 14:24:05 +0100
From:	"Vegard Nossum" <vegard.nossum@...il.com>
To:	"Andi Kleen" <andi@...stfloor.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [RFC] kmemcheck: trap uses of uninitialized memory (v2)

On 29 Nov 2007 11:29:48 +0100, Andi Kleen <andi@...stfloor.org> wrote:
> Vegard Nossum <vegard.nossum@...il.com> writes:
> >
> > - We properly flush TLB entries that change. This used to not be the case, and so we
>
> For low values of "properly" @)
>
> > +     pte = lookup_address(addr);
> > +     change_page_attr(page, 1, __pgprot(pte->pte_low | _PAGE_VISIBLE));
> > +     __flush_tlb_one(addr);
>
> That's not enough, you need to flush all CPUs.
>
> Also when you don't call global_flush_tlb() eventually because c_p_a() will leak flush
> objects over time.

We don't need to flush all CPUs. This is my rationale: The debug
exception (single-step trap) will always happen on the same CPU that
the page fault occurred on. Page fault shows the page, debug exception
hides the page again. Between those two operations, nothing else can
happen that will use the TLB entry in question (unless you have some
weird race condition, but then the code is in error anyway).

What is c_p_a() and what is a flush object?

>
> -Andi
>

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