On Sat, 22 Nov 2014 19:57:07 -0800
Peter Grehan gre...@freebsd.org wrote:
Hi Shawn,
Interesting. I'll have to do more digging. Because removing map_at_zero
support is the same as keeping it at the default of 0. It's not possible
that our ASLR implementation is affecting bhyve, since our
Oliver fixed the problem. bhyve's vmm.ko uses VM_MIN_ADDRESS, which
defaults to NULL in FreeBSD. We modified that to be at 64k to prevent
NULL dereferences. Combine that with the removal of map_at_zero, NULL
deref is not possible anymore. But since we bumped VM_MIN_ADDRESS up,
bhyve's vmm.ko no
On Sat, 22 Nov 2014 21:52:45 -0500
Shawn Webb latt...@gmail.com wrote:
So I just built a new dev box with 32GB ram and an Intel Core i7-4790S
(Haswell). I've enabled virtualization in the BIOS. I'm running 11.0-CURRENT,
updated today.
When I run `bhyveload -m 4G -d
Hi Shawn,
Forgot to mention, I'm on r274859.
I have a working system at r274783. A quick glance doesn't show
anything obvious that may cause a regression, but I'm rebuilding now and
will give it a try.
Is your system stock FreeBSD or HardenedBSD ?
later,
Peter.
On Nov 22, 2014 10:15 PM, Peter Grehan gre...@freebsd.org wrote:
Hi Shawn,
Forgot to mention, I'm on r274859.
I have a working system at r274783. A quick glance doesn't show anything
obvious that may cause a regression, but I'm rebuilding now and will give
it a try.
Is your system stock
Hi Shawn,
It's hardenedBSD. I'll try a stock build tomorrow. The only change we
have that could affect bhyve is the removal of map_at_zero.
This may be the issue. bhyve creates a kernel-use-only vmspace that
represents guest memory (starting at 0), and is used to allow the VM
system to
On Nov 22, 2014 10:27 PM, Peter Grehan gre...@freebsd.org wrote:
Hi Shawn,
It's hardenedBSD. I'll try a stock build tomorrow. The only change we
have that could affect bhyve is the removal of map_at_zero.
This may be the issue. bhyve creates a kernel-use-only vmspace that
represents
Digging thru my system - I have (2) stock FreeBSD system (HP DL385s) at
r274859 - bhyve seems to be working fine for FreeBSD and Linux guests. r274900
also appears to be good.
I know it’s not a ton of help of resolving the issue
cheers,
-bp
On Nov 22, 2014, at 7:20 PM, Shawn Webb
Hi Shawn,
There isn't. map_at_zero was fully removed. I can revert that change,
though. Or is there a way to make bhyve work with out it (with a patch)?
I just set
sysctl security.bsd.map_at_zero=1
.. on my test system and was able to run bhyveload without any issues.
Does
On Nov 22, 2014 10:44 PM, Peter Grehan gre...@freebsd.org wrote:
Hi Shawn,
There isn't. map_at_zero was fully removed. I can revert that change,
though. Or is there a way to make bhyve work with out it (with a patch)?
I just set
sysctl security.bsd.map_at_zero=1
.. on my test
Nope. What if you have map_at_zero set to 0? Dies bhyve work then?
Works with the default of 0, and also with it being set to 1.
later,
Peter.
___
freebsd-virtualization@freebsd.org mailing list
On Nov 22, 2014 10:48 PM, Peter Grehan gre...@freebsd.org wrote:
Nope. What if you have map_at_zero set to 0? Dies bhyve work then?
Works with the default of 0, and also with it being set to 1.
later,
Peter.
Interesting. I'll have to do more digging. Because removing map_at_zero
Hi Shawn,
Interesting. I'll have to do more digging. Because removing map_at_zero
support is the same as keeping it at the default of 0. It's not possible
that our ASLR implementation is affecting bhyve, since our ASLR
implementation is in sys_mmap and the elf image activator. At this
stage,
13 matches
Mail list logo
