linux-kernel - Re: [patch] paravirt: isolate module ops

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: <459F288C.1070809@vmware.com>
Date:	Fri, 05 Jan 2007 20:41:48 -0800
From:	Zachary Amsden <zach@...are.com>
To:	Arjan van de Ven <arjan@...radead.org>
CC:	Ingo Molnar <mingo@...e.hu>, Andrew Morton <akpm@...l.org>,
	linux-kernel@...r.kernel.org,
	Rusty Russell <rusty@...tcorp.com.au>,
	Adrian Bunk <bunk@...sta.de>
Subject: Re: [patch] paravirt: isolate module ops

Arjan van de Ven wrote:
>> I would suggest a slightly different carving.  For one, no TLB flushes.  
>> If you can't modify PTEs, why do you need to have TLB flushes?  And I 
>> would allow CR0 read / write for code which saves and restores FPU state 
>>     
>
> no that is abstracted away by kernel_fpu_begin/end. Modules have no
> business doing that themselves
>   

As long as they don't rely on inlines for that... checking and 
kernel_fpu_end is inline and uses stts(), which requires CR0 read / 
write.  One can easily imagine binary modules which do use the fpu, and 
these were not broken before, so breaking them now seems the wrong thing 
to do.

I agree on debug registers - anything touching them is way too shady.  
And there is no reason modules should be doing raw page table 
operations, they should use proper mm functions and leave the page 
details to the mm layer, which doesn't do these things inline.

Basically, it is just the things that do get inlined that I think we 
should worry about.  If you all feel strongly that this should be fixed 
in 2.6.20, perhaps the best thing to do is in fact 
EXPORT_SYMBOL_GPL(paravirt_ops), and we can queue up a patch in -mm 
which will export those paravirt_ops required inline by modules for 
2.6.21.  Otherwise, I think there will be too many rejects against the 
paravirt code in Andrew's tree.

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/