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