linux-kernel - Re: [PATCH] x86: use pgd accessors when cloning a pgd range.

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: <4CC876DC.3090708@linux.intel.com>
Date:	Wed, 27 Oct 2010 12:00:44 -0700
From:	"H. Peter Anvin" <hpa@...ux.intel.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
CC:	Borislav Petkov <bp@...en8.de>,
	Ian Campbell <ian.campbell@...rix.com>,
	linux-kernel@...r.kernel.org, x86@...nel.org
Subject: Re: [PATCH] x86: use pgd accessors when cloning a pgd range.

On 10/27/2010 11:51 AM, Jeremy Fitzhardinge wrote:
>
> "pvops" as a single thing is a bit of a misnomer these days, in that it
> has been devolving into a number of different functional pieces specific
> to different problem domains, with the only unifying thing is that they
> share the patching machinery.  They're also all controlled by a single
> fat CONFIG_PARAVIRT, but someone posted a patch to separate them out
> into distinct config options so they could be enabled/disabled
> independently as needed, but it seems it was never merged.  I even
> remember acking it.
>
> Aside from that, the notion of pvops has been extending into this
> broader notion of supporting non-traditional x86 platforms, and indeed
> the hooks I'm referring to here are now part of that (or at least tglx
> factored them out of the pvops infrastructure at the same time as the
> things like timers and the like).  So really what you're complaining
> about is that we have lots of indirection and late binding - and yes,
> well, there is rather a lot of that in the kernel overall.
>

tglx's changes are part of the work to clean up and eliminate pvops 
where it is redundant.  However, the pvops machinery has been too rigid 
to be reused, resulting in that we now have something like four 
different patching machineries in the kernel.

But of course, the worst part of pvops is that it is used at a low level 
in a lot of hot paths, and the resulting header files looking like 
someone barfed on a piece of paper, full little inlines pointing "here, 
no over here, no over here."

The indirection and late binding is a problem, especially when the 
indirection layer is badly designed, and encodes design bugs.  Last I 
checked, as an example, there are three paravirt_ops to deal with two 
levels of page tables on non-PAE i386.  One of them (not sure which one) 
doesn't do anything on native, but hell if anyone knows if they are 
actually dead.

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