However, most existing BIOSes, including
current-generation BIOSes, don't provide that protocol. We've actually
seriously considered a minimal pure-Python implementation of DNS that
can fetch A records, to work around that.
> Are you using Gerd's RPMs?
No, we t
On Wed, Jan 13, 2016 at 10:24:00AM -0800, Josh Triplett wrote:
> On Wed, Jan 13, 2016 at 01:43:38PM +0100, Laszlo Ersek wrote:
> > I just noticed that the most recent release of BITS provides a
> > standalone HTTP client!
> >
> > http://biosbits.org/news/bits-2070/
g/PlatformPei/Xen.c", and (I assume!) in the
> > host-side Xen tools as well.
> >
> > Personally I think that this dynamic approach is overkill (mainly
> > because I'm fine with being unable to install Debian Wheezy guests, both
> > wearing and not wearing my red fedora; and because the properties table
> > feature is not active for *any* OVMF guests anyway, in practice).
> >
> > So I'd like to ask you guys to decide which one you prefer: a simple
> > build time flag called NX_STACK_ENABLE (which will allow you to install
> > Wheezy guests, but deprive all other guests from a non-exec stack), or
> > the dynamic switches (which will take host-side work in Xen, plus a
> > matching OvmfPkg patch).
>
> I might go ahead and implement the -fw_cfg solution (for when OVMF runs
> on QEMU), leaving any parallel Xen functionality to Xen developers, for
> later.
>
> Because, I just found out that the GRUB binary built into the bits-2005
> release ISO <http://biosbits.org/download/> blows up the exact same way,
> and *that* is very annoying to me personally.
>
> Maybe we should invert the default. I'm not so convinced any longer that
> the current default is right. I didn't know that the GRUB version with
> code on the stack was this wide-spread.
Heh. Our fault for still using old (2.00) GRUB2, which we do plan to
upgrade at some point, though doing so doesn't top the TODO list. But I
do agree that with OVMF not having previously enforced NX in the UEFI
environment, going from that to immediately enforcing it *by default*
seems a bit quick. I would be surprised if doing so didn't break other
UEFI programs too.
Could OVMF build with NX support available, but disabled by default, so
that qemu can then turn it *on* with a -fw_cfg option?
Do any UEFI stacks on systems in the wild have NX turned on? I don't
think it makes sense for OVMF to enable NX by default until a majority
of new physical systems do so.
- Josh Triplett
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
On Fri, Sep 11, 2015 at 05:28:06PM +0200, Laszlo Ersek wrote:
> On 09/11/15 16:10, Josh Triplett wrote:
> > On Fri, Sep 11, 2015 at 01:43:53PM +0200, Laszlo Ersek wrote:
> >> On 09/09/15 12:48, Laszlo Ersek wrote:
> >>> On 09/09/15 11:37, Ian Campbell wrote:
>
On Fri, Sep 11, 2015 at 11:27:32PM +0200, Laszlo Ersek wrote:
> On 09/11/15 21:30, Josh Triplett wrote:
> > On Fri, Sep 11, 2015 at 05:28:06PM +0200, Laszlo Ersek wrote:
> >> Breaking Debian Wheezy's and BITS's GRUB is also bad, but the former is
> >> very old
the Intel folks etc. for it to be used.
Whether running a standalone system or a hosted service, I don't think
it makes sense to use one completely separate from code hosting. If
you're using github for code, it makes sense to use github for issues;
if you were using Phabricator for code rev
6 matches
Mail list logo
