Re: Address Collision using i386 4G/4G Memory Split
On 18.12.18 11:32, Konstantin Belousov wrote: > On Tue, Dec 18, 2018 at 11:22:53AM +0100, Alexander Lochmann wrote: >> >>>> 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). >>> >> Thanks for the advice! We'll include that in our toolchain. >> Do you use PLs other than 0(=kernel) and 3(=user)? > No, only 0 and 3. But be careful with vm86 (I am not sure how your VM > reports it to your instrumentation). > Ok. Thx! - Alex -- Technische Universität Dortmund Alexander LochmannPGP 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 signature.asc Description: OpenPGP digital signature
Re: Address Collision using i386 4G/4G Memory Split
>> 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). > Thanks for the advice! We'll include that in our toolchain. Do you use PLs other than 0(=kernel) and 3(=user)? - Alex -- Technische Universität Dortmund Alexander LochmannPGP 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 signature.asc Description: OpenPGP digital signature
Re: Address Collision using i386 4G/4G Memory Split
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 LochmannPGP 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
signature.asc
Description: OpenPGP digital signature
Address Collision using i386 4G/4G Memory Split
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?
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?
Regards,
Alex
--
Technische Universität Dortmund
Alexander LochmannPGP 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
signature.asc
Description: OpenPGP digital signature
Re: FreeBSD blocks on BOCHS serial port
I've to correct myself. It works if I activate the boot console (console="vidconsole,comconsole"). If I change the mentioned line to console="vidconsole", neither writing to /dev/ttyu0 nor reading from /dev/cuau1 works. It seems that the FreeBSD loader initialize the serial ports in a different way than the OS does. - Alex On 15.08.2018 12:46, Alexander Lochmann wrote: > Reading from /dev/cuau1 works. Thank you for your help! > However, I'm pretty sure I tried this device before. Nvm. It works. > > - Alex > > On 13.08.2018 22:49, Eugene Grosbein wrote: >> 14.08.2018 3:15, Alexander Lochmann wrote: >> >>>> You should not rely on defaults and make sure you disable modem control/CD >>>> either explicitly (using stty(1) etc.) or implicitly by switching to >>>> /dev/cuau0 >>>> instead of /dev/ttyu0. Flow control settings should match too, for both >>>> sides >>>> of virtual port. >>> Thx. I cannot even run 'stty < /dev/ttyu1' to see the current settings. >>> It simply blocks... >> >> Use /dev/ttyu1.init to see defaults and /dev/ttyu1.lock to set/show >> locked defaults that cannot be changed without disabling a lock first. >> >> > > -- Technische Universität Dortmund Alexander LochmannPGP 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 signature.asc Description: OpenPGP digital signature
Re: FreeBSD blocks on BOCHS serial port
Reading from /dev/cuau1 works. Thank you for your help! However, I'm pretty sure I tried this device before. Nvm. It works. - Alex On 13.08.2018 22:49, Eugene Grosbein wrote: > 14.08.2018 3:15, Alexander Lochmann wrote: > >>> You should not rely on defaults and make sure you disable modem control/CD >>> either explicitly (using stty(1) etc.) or implicitly by switching to >>> /dev/cuau0 >>> instead of /dev/ttyu0. Flow control settings should match too, for both >>> sides >>> of virtual port. >> Thx. I cannot even run 'stty < /dev/ttyu1' to see the current settings. >> It simply blocks... > > Use /dev/ttyu1.init to see defaults and /dev/ttyu1.lock to set/show > locked defaults that cannot be changed without disabling a lock first. > > -- Technische Universität Dortmund Alexander LochmannPGP 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 signature.asc Description: OpenPGP digital signature
Re: FreeBSD blocks on BOCHS serial port
On 13.08.2018 21:36, Eugene Grosbein wrote: > 13.08.2018 20:52, Alexander Lochmann wrote: > >> Hi folks! >> >> We are doing some automatic experiments using FreeBSD running in a >> virtual machine. >> To control the experiment from the outside, we use serial ports to >> communicate with an userspace program. >> The communication via serial does work with QEMU. However, it does not >> work with BOCHS which is our desired emulator. >> Even simple operations like 'echo FOO | tee /dev/ttyu1' or 'cat >> /dev/ttyu1' do not work. Both commands block 'forever'. >> It does not matter whether we use ttyu0 (file backend) or ttyu1 (tcp >> socket). >> I put some debug output in sys/dev/uart/uart_dev_ns8250.c. The output >> suggests that the driver more or less reads and writes to the serial >> ports. At least it does something... >> >> Do you have any hints how we can further analyze this problem? >> Did anyone came across a similar problem? > > This could be modem control line "Carrier Detection" (CD) or flow control > problem: > emulators can have distinct default settings for serial ports. > > You should not rely on defaults and make sure you disable modem control/CD > either explicitly (using stty(1) etc.) or implicitly by switching to > /dev/cuau0 > instead of /dev/ttyu0. Flow control settings should match too, for both sides > of virtual port. Thx. I cannot even run 'stty < /dev/ttyu1' to see the current settings. It simply blocks... 'stty < /dev/ttyu0' works perfectly. ttyu0 uses a file-based backend. Whereas ttyu1 uses a tcp server-based backend with a connected netcat. > > -- Technische Universität Dortmund Alexander LochmannPGP 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 signature.asc Description: OpenPGP digital signature
FreeBSD blocks on BOCHS serial port
Hi folks! We are doing some automatic experiments using FreeBSD running in a virtual machine. To control the experiment from the outside, we use serial ports to communicate with an userspace program. The communication via serial does work with QEMU. However, it does not work with BOCHS which is our desired emulator. Even simple operations like 'echo FOO | tee /dev/ttyu1' or 'cat /dev/ttyu1' do not work. Both commands block 'forever'. It does not matter whether we use ttyu0 (file backend) or ttyu1 (tcp socket). I put some debug output in sys/dev/uart/uart_dev_ns8250.c. The output suggests that the driver more or less reads and writes to the serial ports. At least it does something... Do you have any hints how we can further analyze this problem? Did anyone came across a similar problem? Thank you! Regards, Alex -- Technische Universität Dortmund Alexander LochmannPGP 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 signature.asc Description: OpenPGP digital signature
