linux-kernel - Re: CONFIG_XEN dependencies

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:	Wed, 24 Oct 2007 09:31:10 +0100
From:	"Jan Beulich" <jbeulich@...ell.com>
To:	"Jeremy Fitzhardinge" <jeremy@...source.com>
Cc:	"Jeremy Fitzhardinge" <jeremy@...p.org>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: CONFIG_XEN dependencies

>>> Jeremy Fitzhardinge <jeremy@...source.com> 23.10.07 20:09 >>>
>Jan Beulich wrote:
>> Jeremy,
>>
>> CONFIG_XEN (in 2.6.23) depends on X86_CMPXCHG and X86_TSC. This
>> precludes enabling the option in kernels using M386, M486, or M586, despite
>> the fact that the detection code doesn't need these features and if Xen is
>> present the features are implicitly there. At least the X86_TSC dependency
>> can thus be dropped in my opinion, which would then only exclude M386
>> kernels. (Dropping X86_CMPXCHG may yield build problems, but could
>> perhaps also be eliminated by forcibly #define-ing it in the relevant source
>> files.)
>
>Yeah, that's a bit tacky though.  We added it because reviewers
>(probably Adrian Bunk, or maybe akpm) noticed the Xen code
>unconditionally using cmpxchg, and I added tsc because, well, we use it.
>
>But you're right; we can't get to any of the Xen code without booting
>under Xen, which necessarily means all those features are available,
>regardless of how the kernel is configured.
>
>What config combinations do you want to support?

The specific goal is to be able to enable the XEN option in our native kernel,
which gets configured with M586. So we could live with XEN depending on
X86_CMPXCHG, but would definitely need the dependency on X86_TSC
dropped. Nevertheless I'd favor even X86_CMPXCHG dropped unless that
causes unresolvable (or difficult to resolve) problems.

Jan

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