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:	Thu, 10 Sep 2015 12:32:51 +0100
From:	Andrew Turner <andrew@...ar.geek.nz>
To:	Shannon Zhao <zhaoshenglong@...wei.com>
Cc:	<linux-arm-kernel@...ts.infradead.org>,
	<devicetree@...r.kernel.org>, linux-efi@...r.kernel.org,
	ian.campbell@...rix.com, linux-doc@...r.kernel.org,
	ard.biesheuvel@...aro.org, linux-kernel@...r.kernel.org,
	leif.lindholm@...aro.org, xen-devel@...ts.xen.org,
	julien.grall@...rix.com, freebsd-arm@...ebsd.org,
	matt.fleming@...el.com, christoffer.dall@...aro.org,
	jbeulich@...e.com, peter.huangpeng@...wei.com,
	stefano.stabellini@...citrix.com, shannon.zhao@...aro.org
Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub
 parameters

On Thu, 10 Sep 2015 16:41:56 +0800
Shannon Zhao <zhaoshenglong@...wei.com> wrote:

> From: Shannon Zhao <shannon.zhao@...aro.org>
> 
> These EFI stub parameters are used to internal communication between
> EFI stub and Linux kernel and EFI stub creates these parameters. But
> for Xen on ARM when booting with UEFI, Xen will create a minimal DT
> providing these parameters for Dom0 and Dom0 is not only Linux
> kernel, but also other OS (such as FreeBSD) which will be used in the
> future. So here we plan to standardize the names by dropping the
> prefix "linux," and make them common to other OS. Also this will not
> break the compatibility since these parameters are used to internal
> communication between EFI stub and kernel.

It is unlikely FreeBSD will use this property when booting ad Xen dom0.
The kernel expects to be passed a data structure to find boot this
information.

My preference would be to have the FreeBSD loader load the xen binary,
the FreeBSD kernel, and set up these data structs before passing
control to Xen, with the information it needs to boot the kernel. My
understanding is this is how it is done on x86.

I can see a few issues with this where, for example, the device tree or
ACPI tables need to be modified, but these should be solvable.

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