linux-kernel - Re: [PATCH] paravirt.h

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:	Tue, 22 Aug 2006 15:02:52 -0700
From:	Zachary Amsden <zach@...are.com>
To:	Andi Kleen <ak@...e.de>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	virtualization@...ts.osdl.org,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Andrew Morton <akpm@...l.org>,
	Chris Wright <chrisw@...s-sol.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] paravirt.h

Andi Kleen wrote:
> Zachary Amsden <zach@...are.com> writes:
>   
>> That is a really nasty problem.  You need a synchronization primitive
>> which guarantees a flat stack, so you can't do it in the interrupt
>> handler as I have tried to do.  I'll bang my head on it awhile.  In
>> the meantime, were there ever any solutions to the syscall patching
>> problem that might lend me a clue as to what to do (or not to do, or
>> impossible?).
>>     
>
> stop_machine_run() solves the problem I think. It is currently not 
> exported though. I don't think there's anything in there that couldn't
> be reimplemented in a module, but then we could also just export it
> if there's a useful user.
>   

Well, I don't think anything is sufficient for a preemptible kernel.  I 
think that's just plain not going to work.  You could have a kernel 
thread that got preempted in a paravirt-op patch point, and making all 
the patch points non-preempt is probably a non-starter (either +12 bytes 
each or no native inlining).  Finding out after the fact that you have a 
kernel thread that was preempted in a patch point is very hard work, but 
it is possible.  The fixing it up is where you need to take liberties 
with reality.

stop_machine_run() is almost what I want, but even that is not 
sufficient.  You also need to disable NMIs and debug traps, which is 
pretty hairy, but doable.  The problem with stop_machine_run() is that I 
don't just want the kernel to halt running on remote CPUs, I want the 
kernel on all CPUs to actually do something simultaneously - the entry 
into paravirt mode requires a hypervisor call on each CPU, and 
stop_machine() doesn't provide a facility to fire a callback on each CPU 
from the stopmachine state.

Since this code is so rather, um, custom, I was going to reimplement 
stop_machine in the module.

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