linux-kernel - Re: [PATCH 1/2] kmemcheck v3

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: <19f34abd0802080459t4630c251q2a7cb3680e207e7a@mail.gmail.com>
Date:	Fri, 8 Feb 2008 13:59:57 +0100
From:	"Vegard Nossum" <vegard.nossum@...il.com>
To:	"Andi Kleen" <andi@...stfloor.org>
Cc:	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"Ingo Molnar" <mingo@...e.hu>,
	"Pekka Enberg" <penberg@...helsinki.fi>,
	"Richard Knutsson" <ricknu-0@...dent.ltu.se>,
	"Christoph Lameter" <clameter@....com>
Subject: Re: [PATCH 1/2] kmemcheck v3

On 2/8/08, Andi Kleen <andi@...stfloor.org> wrote:
> On Fri, Feb 08, 2008 at 01:18:37PM +0100, Vegard Nossum wrote:
> > On 2/8/08, Andi Kleen <andi@...stfloor.org> wrote:
> > > Your assumption that only the string instructions can take
> > > multiple page faults seems a little dangerous too.
> >
> > Yes, this is true. I cannot guarantee that there are no other
> > instructions that could access more than one memory location but only
> > take one page fault. However, since the kernel does boot, we at least
> > know that these instructions are not very frequently used. (If you
> > know of any other instructions we might be missing, I'll be happy to
> > know about it!)
>
> Pretty much all in the right circumstances.
>
> e.g. consider a segment reload in tracked memory.
>
> Also there are various instructions which do all kinds of complicated
> things internally; like IRET or INT: often with many memory accesses.
> Just page through a instruction manual and look at the pseudo code
> describing what the various instructions do.

Yes, this is true. Then our task is to make sure that this memory is
never allocated from tracked caches. We do have some changes in this
area, for instance we never track task structs. Keep in mind that only
slab objects are tracked currently, so things like stacks never catch
page faults. I am not sure if this is exactly what you had in mind,
but I don't know other kernel code very well enough to come up with
perhaps more relevant examples :-)

For now, I am simply assuming that we never load task segments, GDTs,
LDTs, or paging structures from tracked memory (e.g. regular
kmalloc()).

> > There is also the point that if kmemcheck doesn't handle all the
> > faulting addresses, it will simply fault again and again, without
> > making any progress. I mean, it won't go unnoticed for very long :-)
> >
> > This is also why we depend on M386 and !X86_GENERIC, to avoid those
> > MMX, etc. instructions, as we have no support for those currently
>
> I would not expect problems from MMX/SSE here (except for the generic
> ones all instructions have)

The problem with these instructions is not that they take page faults,
but that kmemcheck doesn't know how to handle them. Kmemcheck needs to
parse the instruction stream at EIP to determine what addresses were
accessed, their size, and the type (read or write). This can be done
currently with surprisingly little amounts of code.

But AFAIK the format for MMX and SSE is different from the "regular"
instructions, and so I don't know how to parse them. But this is
something we can look at later.

Vegard

PS: Thanks for telling me about how change_page_attr() was wrong in
kmemcheck v2. A lot of things were simply wrong in v2, but hopefully
they are better now :-)
--
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/