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:	Mon, 5 Oct 2015 15:18:05 +0200
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	Peter Maydell <peter.maydell@...aro.org>,
	"Gabriel L. Somlo" <somlo@....edu>
Cc:	Mark Rutland <mark.rutland@....com>, gregkh@...uxfoundation.org,
	paul@...an.com, Kumar Gala <galak@...eaurora.org>,
	Will Deacon <will.deacon@....com>, agross@...eaurora.org,
	zajec5@...il.com, Hanjun Guo <hanjun.guo@...aro.org>,
	Catalin Marinas <catalin.marinas@....com>,
	"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
	lkml - Kernel Mailing List <linux-kernel@...r.kernel.org>,
	kernelnewbies@...nelnewbies.org,
	Matt Fleming <matt.fleming@...el.com>,
	Laszlo Ersek <lersek@...hat.com>,
	Jordan Justen <jordan.l.justen@...el.com>,
	"Michael S. Tsirkin" <mst@...hat.com>,
	Leif Lindholm <leif.lindholm@...aro.org>,
	Ard Biesheuvel <ard.biesheuvel@...aro.org>,
	Gerd Hoffmann <kraxel@...hat.com>,
	QEMU Developers <qemu-devel@...gnu.org>
Subject: Re: [PATCH v3 0/4] SysFS driver for QEMU fw_cfg device



On 05/10/2015 14:50, Peter Maydell wrote:
> If you want to try to support "firmware might also be reading
> fw_cfg at the same time as the kernel" this is a (painful)
> problem regardless of how the kernel figures out whether a
> fw_cfg device is present. I had assumed that one of the design
> assumptions of this series was that firmware would only
> read the fw_cfg before booting the guest kernel and never touch
> it afterwards. If it might touch it later then letting the
> guest kernel also mess with fw_cfg seems like a really bad idea.

The idea of tinkering with fw_cfg from the AML code (DSDT/SSDT) has been
proposed many times, and always dropped.  One of the reasons was that
the OS could have a driver for fw_cfg.

So I think that we can define the QEMU0002 id as owned by the OSPM,
similar to the various standard ACPI ids that are usually found in the
x86 world (e.g. PNP0B00 is a mc146818 RTC, PNP0303 is an 8042 keyboard
controller, PNP0501 is a 16550 or similar UART, and so on).  This
basically sanctions _CRS as the way to pass information from the
firmware to the OSPM, also similarly to those standard PNP ids.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ