<div dir="ltr">Andrey (Korolev),<div><br></div><div>You got all my points. Both of them. It is on you... What you'll do.</div><div><br></div><div>But whatever you do, please, post results here. :-)</div><div><br></div><div>Zoran</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 6, 2017 at 2:06 PM, Andrey Korolyov <span dir="ltr"><<a href="mailto:andrey@xdel.ru" target="_blank">andrey@xdel.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Jul 6, 2017 at 8:20 AM, Zoran Stojsavljevic<br>
<<a href="mailto:zoran.stojsavljevic@gmail.com">zoran.stojsavljevic@gmail.com</a><wbr>> wrote:<br>
> OK, both Andrjusas,<br>
><br>
> I am a bit ignorant, and I read beginning of the Coreboot log:<br>
><br>
> DIMM 0 side 0 = 1024 MB<br>
> DIMM 0 side 1 = 1024 MB<br>
> DIMM 2 side 0 = 1024 MB<br>
> DIMM 2 side 1 = 1024 MB<br>
> tRFC = 43 cycles<br>
> Setting Graphics Frequency...<br>
> FSB: 667 MHz Voltage: 1.05V Render: 250MHz Display: 200MHz<br>
> Setting Memory Frequency... CLKCFG = 0x00010023, CLKCFG = 0x00010043, ok<br>
> Setting mode of operation for memory channels...Dual Channel Interleaved.<br>
> Programming Clock Crossing...MEM=667 FSB=667... ok<br>
> Setting RAM size...<br>
> C0DRB = 0x40404020<br>
> C1DRB = 0x40404020<br>
> TOLUD = 0x00d0 <<==========???<br>
><br>
> 4GB (two channel) memory, in two slots out of 4... ?!<br>
><br>
> Top of Low Usable RAM 00d0h??? Any explanation for that?<br>
</span>@Zoran<br>
<br>
Thanks, that could be the point, though it seem to be same low for<br>
X/T60 [0]. I would check if reading PCI space in Linux would result to<br>
same small address and may be this is the point (also I could quickly<br>
run completely headless kernel to verify that).<br>
<span class=""><br>
><br>
> Andy (Korolev),<br>
><br>
> Did you manage to get to Linux emergency mode called Dracut?<br>
<br>
</span>I think that you meant dracut-produced initrd and try it against SMP<br>
kernel, right? If I could get your idea, you are possibly suggesting<br>
to cut off every device from being initalized except SuperIO, get to<br>
ramdisk and try to work things out from there? I didn`t tried this<br>
yet, mainly because I don`t want to spend much time with blind efforts<br>
on very old laptop whose support has almost no real value... If I am<br>
wrong, please explain what you`ve suggested in there.<br>
<span class=""><br>
><br>
> So you are after memory contents? Freeze DIMMS, turn off memory scrambling<br>
> and flash firmware that dumps memory contents. In essence, cold boot attack.<br>
<br>
</span>@Andrey<br>
That`s what I meant under 'spending few days', getting memory access<br>
during both cold-boot run and DMA-assisted run is a matter of tens of<br>
minutes, but the analysis of the dump would take much more time. The<br>
main problem is that I am losing dynamic picture for memory contents<br>
if I would do only post-mortem analysis and (with cold-boot attack)<br>
I`ll lose small portion of the memory state anyway, due to<br>
bootloader`s needs to initialize PCI devices (though I could imagine<br>
very slow and boring transfer using CAR and USB debug port and there`s<br>
bit of code need to be written for that). The fastest way to get close<br>
to the point of failure and see at least a dynamic stuff is, probably,<br>
a timer-based non-preemptible hack within ieee1394 driver which would<br>
literally freeze system to allow me to take snapshots without risk of<br>
hitting crash in the middle. Anyway, this closes down to analysis of<br>
what is going on within the dump and with Linux mm it`s not an easy<br>
task if you are not searching for something specific like LUKS key :)<br>
<br>
0. <a href="https://mail.coreboot.org/pipermail/coreboot/2014-October/078752.html" rel="noreferrer" target="_blank">https://mail.coreboot.org/<wbr>pipermail/coreboot/2014-<wbr>October/078752.html</a><br>
</blockquote></div><br></div>