Am 18.12.18 um 06:27 schrieb Konstantin Belousov:
> On Mon, Dec 17, 2018 at 02:51:48PM +0100, Alexander Lochmann wrote:
>> Hi folks!
>>
>> 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?
> The feature was added to HEAD during this summer, before stable/12 was
> branched.
Mhmkay. But how likely is it that two memory areas will get the same
address?
Does the kernel, for example, start in the high memory region and the
user space starts in the mid region?
This would reduce the likelihood of two memory areas starting at the
same virtual address.

Some context: We are doing VM-based tracing in the FreeBSD kernel. For
that, we observe parts of the kernel memory (allocations, accesses,...).
Before 12.0 we simply knew that kernel addresses that we logged were
unique. Moreover, when a memory access to a region of interest happened
we knew that could only be kernel memory.
We know have to ensure that we only record memory accesses that happen
within the kernel.
Our approach is to record the kernels value for the CR3 register, and
record memory accesses if the CR3 registers holds the aforementioned value.

> 
>>
>> 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?
> Because it is needed for i386 to self-host, in modern world 1G KVA
> is too small, and because it provides Meltdown mitigation.
> 

-- 
Technische Universität Dortmund
Alexander Lochmann                PGP key: 0xBC3EF6FD
Otto-Hahn-Str. 16                 phone:  +49.231.7556141
D-44227 Dortmund                  fax:    +49.231.7556116
http://ess.cs.tu-dortmund.de/Staff/al

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to