Date: Tue, 18 Dec 2018 12:01:59 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Alexander Lochmann <alexander.lochmann@tu-dortmund.de> Cc: freebsd-stable@freebsd.org, Horst Schirmeier <horst.schirmeier@tu-dortmund.de> Subject: Re: Address Collision using i386 4G/4G Memory Split Message-ID: <20181218100159.GE60291@kib.kiev.ua> In-Reply-To: <40f4db11-84cb-9b8d-2eb5-5882ad01d1d8@tu-dortmund.de> References: <38ad0d50-c776-9deb-d56b-db8db548cefc@tu-dortmund.de> <20181218052738.GZ60291@kib.kiev.ua> <40f4db11-84cb-9b8d-2eb5-5882ad01d1d8@tu-dortmund.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 18, 2018 at 10:16:35AM +0100, Alexander Lochmann wrote: > 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? It is possible. > Does the kernel, for example, start in the high memory region and the > user space starts in the mid region? No, kernel now does not relocate itself, it is running with PA == VA for text and data segment. Look at the kernel binary to see the addresses. > This would reduce the likelihood of two memory areas starting at the > same virtual address. I do not see why this would be even slightly needed. > > 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. You must use CPL to see if the current operation mode is user or kernel. If user, nothing should be done (this would avoid vm86). If kernel, you need to compare current %cr3 with IdlePTD (IdlePTDP for PAE case). There are moments where kernel is executing on the user page tables. This happens on kernel entry/exit, and sometimes on copyout(9). > > > > >> > >> 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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20181218100159.GE60291>