Alexander Lochmann writes:> According to git commit e3089a (https://reviews.freebsd.org/D1463) > FreeBSD 12.0 i386 uses separate address spaces for kernel and user > space. So basically two memory areas, one in each space, can have the > same address. > Is this possible with FreeBSD 12.0? Is this likely to happen?If the userspace program and the kernel address happen to overlap, the system will deal with it. There's not anything to worry about. As to whether or not it's likely to happen -- I'm not sure about that. I expect the default stack and heap space locations for a fresh process have changed due to this change, but it should not matter.> On my opinion, this is also very expensive in terms of performance. > Any copy{in,out} has to flush the TLB. > (http://fxr.watson.org/fxr/source/i386/i386/copyout_fast.s#L91) > Why are you still using this 4G/4G approach?The complete split between the user address space and kernel address space mapping is largely due to the mitigation of the Spectre attacks, as I understand things. To have both the kernel and userspace mapped at the same time, can be used to extract information from the kernel that should not be made available. I think it falls into the "slower but safer" class of change. Someone will, undoubtedly, correct me if I'm wrong. -Kurt
On Mon, Dec 17, 2018 at 03:58:05PM -0500, Kurt Lidl wrote:> Alexander Lochmann writes: > > According to git commit e3089a (https://reviews.freebsd.org/D1463) > > FreeBSD 12.0 i386 uses separate address spaces for kernel and user > > space. So basically two memory areas, one in each space, can have the > > same address. > > Is this possible with FreeBSD 12.0? Is this likely to happen? > > If the userspace program and the kernel address happen to overlap, the > system will deal with it. There's not anything to worry about. As to > whether or not it's likely to happen -- I'm not sure about that. I > expect the default stack and heap space locations for a fresh process > have changed due to this change, but it should not matter.4/4 does potentially alter the failure modes of buggy code that tries to read directly from userspace addresses. For example, correct calls to the sysctls fixed in r342125 may panic prior to the fix because the addresses in question aren't mapped in kernel space. They might also fail or behave bizarrely if the page is mapped and the value from the kernel page is used. -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: not available URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20181218/4acce37e/attachment.sig>