Sorry for the delay, mailing list archives was offline, or whatever...
intrigeri wrote:
> I can reproduce winterfairy's results on a ThinkPad X201 (both with
> the shutdown applet and with the emergency shutdown). FWIW, both this
> system and the ThinkPenguin Royal have Intel graphics. I can't
> reproduce this issue in libvirt/qemu (qxl graphics). winterfairy, what
> graphics driver is used by the system exposing this bug?
lspci:
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960
Integrated Graphics Controller (rev 03)
(using "i915" driver according to lsmod)
> I've seen no indication that the kernel has finished loading and run
> the initramfs' init. I haven't checked if the memory wipe did happen
> or not. I fear we have to treat this as a serious regression.
Was hoping it was just my computer... :(
Was there important security fixes in the new kernel version, or is it
possible to revert the kernel upgrade if the cause is not found promply
enough?
> [list of TODO items]
>
> winterfairy, do you think you can take care of any of this in the next
> few days (say, before next Tuesday)?
I doubt it, will be kind of busy until Thursday.
intrigeri wrote:
> winterfairy wrote:
>> This makes me believe the memory erasing acts badly with this kernel
>> version and hardware combination, possibly writing some data somewhere
>> it shouldn't had, causing the kernel or hardware to force a reboot.
>> And that it worked with previous kernel versions on this hardware
>> by pure luck.
>
> My understanding is that sdmem shouldn't be allowed to write to places
> it shouldn't. Changes in the OOM area, perhaps?
>
>> I want to look deeper into this, but I cannot find where the actual
>> memory erasing code is (where sdmem is started?)? Only where the
>> kexec bits are. Where is it?
>
> You want to look at
> https://tails.boum.org/contribute/design/memory_erasure/ and
> /usr/share/initramfs-tools/scripts/init-premount/sdmem
intrigeri wrote:
> I'm more and more inclined to think it's a regression in Linux itself.
I still believes what I said about overwriting something it shouldn't, and
now I also believe it is directly Intel graphic card related. These are
still guesses though, I may be wrong.
But, previously on my computer, the screen was always scrambled during
memory erasure. The exact pattern sometimes varied between Tails releases,
but it was just scrambled. Expected, maybe, since the video memory is RAM
mapped.
But a few releases back, when Tails switched to a much newer Linux kernel,
the scrambling stopped, and I instead got blue twinkling stars (pixels
actually) during the erasure procedure. Now, how is that possible, unless
the video card is put in some absurd state?
And now it broke?
So, I will look into that sdmem script and see if there is something odd
there, for starters.
