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: <20160413191011.GZ1990@wotan.suse.de>
Date:	Wed, 13 Apr 2016 21:10:11 +0200
From:	"Luis R. Rodriguez" <mcgrof@...nel.org>
To:	Roger Pau Monné <roger.pau@...rix.com>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:	"Luis R. Rodriguez" <mcgrof@...nel.org>,
	George Dunlap <george.dunlap@...rix.com>,
	Matt Fleming <matt@...eblueprint.co.uk>,
	Michael Chang <MChang@...e.com>,
	Julien Grall <julien.grall@....com>,
	Jan Beulich <JBeulich@...e.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Daniel Kiper <daniel.kiper@...cle.com>,
	the arch/x86 maintainers <x86@...nel.org>,
	Vojtěch Pavlík <vojtech@...e.cz>,
	Gary Lin <GLin@...e.com>,
	xen-devel <xen-devel@...ts.xenproject.org>,
	Jeffrey Cheung <JCheung@...e.com>,
	Charles Arndol <carnold@...e.com>,
	Stefano Stabellini <stefano.stabellini@...citrix.com>,
	Jim Fehlig <jfehlig@...e.com>, joeyli <jlee@...e.com>,
	Borislav Petkov <bp@...en8.de>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	Juergen Gross <jgross@...e.com>,
	Andrew Cooper <andrew.cooper3@...rix.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>,
	David Vrabel <david.vrabel@...rix.com>,
	Takashi Iwai <tiwai@...e.de>, jeffm@...e.com,
	torvalds@...ux-foundation.org,
	Julien Grall <julien.grall@...aro.org>
Subject: Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Wed, Apr 13, 2016 at 12:25:03PM +0200, Roger Pau Monné wrote:
> On Wed, Apr 13, 2016 at 12:12:25AM +0200, Luis R. Rodriguez wrote:
> [...]
> > Also, x86 does have a history of short DT use. Just pointing that its there as
> > an option as well. I'll Cc you on some thread about that.
> 
> I don't see how this is relevant to the conversation that's going on:

Its relevant as George brought up DT as a *reason* why ARM was able
to cope with no custom entry point...

> How many x86 hardware provide DT?


One. CE4100.

arch/x86/platform/ce4100/falconfalls.dt

> I bet this is 0%.

That's slightly more than 0%.

> How many OSes can boot on x86 using DT? Linux maybe, certainly FreeBSD, 
> Windows or OpenBSD won't be able to boot at all when provided a DT on x86.

You guys seem to be taking these things too personal. 

Let me repeat, my goal is to ensure we review things without a bias. The points
you make here *now* are things I welcome to the discussion as reasons for
ruling out DT as ways to fine tune further semantics, its however by no means
something we should have discarded.

> Is Xen going to craft a DT for x86 based on ACPI?  No, because it can't parse
> the DSDT or other dynamic tables that contain the information about the
> devices in the system.

Again, DT was brought up by George as reason why ARM was able to cope
with no custom entry point. That's all. What you raise is a good point
to highlight but it does not mean we can't use it if we wanted to for
other things, for instance as an alternative to extending the x86 boot
protocol with custom things which we may need to enhance semantics
early in boot. If that is a stupid prospect lets highlight that and
rule it out.

> I would also like to point out that DT or not DT is not really the problem 
> here, the issue that George was trying to point out is that on x86 there's 
> some legacy hardware that's considered to be always there, so it's presence 
> is not signaled by ACPI, and HVMlite is _not_ emulating this hardware. It 
> doesn't matter if the hardware description comes from ACPI or DT, this 
> hardware is considered to be always present on PC compatible hardware.

x86 Xen PV guests are not alone.  I'm adding quirks we can use to address this
in a clean way now which turns out to be very useful for other custom x86
platforms.

  Luis

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ