linux-kernel - Re: [PATCH v2] x86: Add a list for custom page fault handlers.

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, 3 Feb 2008 23:40:11 +0200
From:	Pekka Paalanen <pq@....fi>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	Harvey Harrison <harvey.harrison@...il.com>,
	linux-kernel@...r.kernel.org, Jan Beulich <jbeulich@...ell.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Pavel Roskin <proski@....org>
Subject: Re: [PATCH v2] x86: Add a list for custom page fault handlers.

On Sun, 3 Feb 2008 08:03:21 +0100
Ingo Molnar <mingo@...e.hu> wrote:

> i dont think this second problem is a practical one: i've test-merged 
> mmiotrace two days ago into x86.git and it's holding up very well in my 
> testing (it has not caused a single hickup so far). It's nice optional 
> debug functionality and i dont see any reason why not to merge it.

Good to hear!

I've made some fixes since my last mmiotrace patch (v2). Rewritten things
to use lookup_address(), added EXPORT_SYMBOL(lookup_address) into
pageattr.c to make it work (this hopefully fixed the undefined symbol
'init_mm' on x86-32), and fixed relay-buffer-full flags on SMP.

> a few cleanup requests:
> 
> - please make the pagefault callbacks explicit as Arjan has asked

What does this mean in practice? It should be able to call into a module,
so the only thing I can come up with is a single settable function
pointer. Just like I proposed in patch v2, but a function pointer instead
of a list. Is this what you and Arjan suggest?
We are talking about the hook in do_page_fault(), right?

> - any reason why it lives in arch/x86/kernel/mmiotrace/? It should be a
>   prime-time member of arch/x86/mm/ i think.

I was waiting for someone to comment on that, I didn't know what was the
proper place. I'll move it into there.

> - please make it build-in-able, not modules-only.

Then I need a way to clear the relay buffers at some point. Currently
they get cleared only on module unload. Maybe preferably also allocate
and deallocate them dynamically. I've no idea how to do this yet, any
pointers to examples?

Hmm, I guess relay buffers could be allocated on the first intercepted
call to ioremap, but then the userspace could not be started before
hand, and at that point it is too late.

Making it build-in-able will take so much time that I'd prefer to aim
it for 2.6.26.

> - [ longer-term: think about integrating pf_in.c with the x86
>     emulator/disassembler of KVM. ]

Yikes. Like I replied to Arjan, it looks daunting.

Thanks, I'll do what I can. When do you need the final (as for 2.6.25)
mmiotrace patch, or is it going in as v2 and then we fix it in RCs?

-- 
Pekka Paalanen
http://www.iki.fi/pq/
--
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/