Bug #6460

Fix memory wipe with recent kernel

Added by intrigeri 2013-11-30 05:14:27 . Updated 2014-03-19 07:20:16 .

Status:
Resolved
Priority:
High
Assignee:
Category:
Target version:
Start date:
2013-11-30
Due date:
% Done:

100%

Feature Branch:
feature/disable-mei
Type of work:
Code
Blueprint:

Starter:
0
Affected tool:
Deliverable for:

Description

See Shutdown stopped working in nightly experimental? and Fix sdmem on Intel graphic hardware, please review threads on tails-dev.

Not better with the following (one change at a time) attempts:

  • Linux 3.12 (3.12-1~exp1) from Debian experimental
  • Linux 3.12.3 (3.12.3-1~exp1) from Debian experimental
  • Linux 3.12.6 (3.12.6-1) from Debian unstable
  • Linux 3.13-rc6 (3.13~rc6-1~exp1) from Debian experimental
  • kexec-tools 2.0.4-1
  • initramfs-tools 0.114
  • removing --reset-vga from the tails-kexec initscript

This might be the same problem as:

Something that could be worth giving a try is booting with KMS disabled. If this works, then we may narrow it down to a graphics driver issue.


Subtasks


Related issues

Related to Tails - Feature #5948: Custom plymouth theme Confirmed
Related to Tails - Bug #6467: Memory wipe broken with Linux 3.11 Resolved 2013-11-30
Related to Tails - Feature #6584: Upgrade to Linux 3.12 Resolved 2013-11-30

History

#1 Updated by intrigeri 2013-12-01 06:15:50

  • Target version set to Tails_0.22

#2 Updated by winterfairy 2013-12-01 09:36:28

  • Status changed from Confirmed to In Progress
  • Assignee set to intrigeri
  • QA Check set to Ready for QA

Hopefully fixed in “bugfix/sdmem_on_intel_gpu” in my repo.

#3 Updated by intrigeri 2013-12-01 11:23:54

  • Assignee changed from intrigeri to winterfairy
  • QA Check changed from Ready for QA to Info Needed
  • Feature Branch set to bugfix/sdmem_on_intel_gpu

Does not fix the issue for me, asked more tests to winterfairy on tails-dev.

#4 Updated by intrigeri 2013-12-02 05:44:18

  • Assignee changed from winterfairy to bertagaz
  • QA Check changed from Info Needed to Ready for QA
  • Feature Branch changed from bugfix/sdmem_on_intel_gpu to bugfix/back-to-linux-3.10

#5 Updated by intrigeri 2013-12-06 02:07:24

  • Status changed from In Progress to Confirmed
  • Assignee deleted (bertagaz)
  • Target version deleted (Tails_0.22)
  • QA Check deleted (Ready for QA)
  • Feature Branch deleted (bugfix/back-to-linux-3.10)

#6 Updated by intrigeri 2013-12-06 02:09:17

Workaround’ed in 0.22 (Bug #6462) but we still have to fix this on the long run.

#7 Updated by intrigeri 2013-12-06 03:05:15

  • Target version set to Tails_0.23

#8 Updated by intrigeri 2013-12-08 08:40:19

  • Target version changed from Tails_0.23 to Tails_0.22.1

#9 Updated by intrigeri 2013-12-16 05:02:36

  • Subject changed from Memory wipe broken with Linux 3.11 to Upgrade Linux kernel without breaking memory wipe

#10 Updated by intrigeri 2013-12-23 01:34:21

One should retry:

  • with Linux 3.12.6-1 from sid
  • passing vga=current to the kexec’d kernel (with and without --reset-vga in the tails-kexec initscript)

#11 Updated by intrigeri 2013-12-23 02:02:12

This might be related to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1257338, that is fixed by the “PCI: Disable Bus Master only on kexec reboot” commit in Linux 3.13-rc4.

#12 Updated by intrigeri 2013-12-26 06:19:54

Another check that could be useful would be to remove the quiet boot parameter for the kexec’d kernel.

#13 Updated by intrigeri 2014-01-01 05:02:26

On a MacBook Pro 8,1, the kexec’d kernel freezes just the same with Linux 3.13-rc6 as it does with 3.11.

#14 Updated by alant 2014-01-04 03:15:28

Tried yesterday’s experimental (476ade7) with the following graphics hardware, which do not expose the problem:

- QEMU with QXL graphics

- QEMU with cirrus graphics

- QEMU with VGA graphics

- QEMU with VMVGA graphics

- bare metal with Intel Corporation 82915G/GV/910GL graphics (i915)
- bare metal with Intel Corporation Mobile 945GME graphics (i915)

#15 Updated by intrigeri 2014-01-04 03:54:39

On today’s experimental (with 3.13-rc6) and a ThinkPad X220 (SandyBridge), the kexec’d kernel freezes.

Disabling KMS (i915.modeset=0 nomodeset) does not help.

Removing the quiet kernel parameter makes the “normal” kernel a tiny bit more verbose, but the kexec’d one still does not say anything at all.

I suspect a kexec failure, rather than a (later) boot failure in the kexec’d kernel.

#16 Updated by intrigeri 2014-01-04 04:34:56

ThinkPad X230 (IvyBridge):

  • On today’s feature/wheezy (with 3.12.6-2 32-bit), the kexec’d kernel reboots so the memory has probably not been erased. Disabling KMS (i915.modeset=0 nomodeset) does not help.
  • On today’s experimental (with 3.13-rc6 64-bit), both in Legacy BIOS mode and in UEFI mode, memory erasure works fine.

#17 Updated by akuckartz 2014-01-06 02:30:48

Lenovo ThinkPad X130e
tails-i386-feature_uefi-0.23-20140104T0920Z-3305611.iso

Automatic memory wiping seems to fail, no power off even after several minutes.

Two acpi_evalf() falures are reported: AE_NOT_FOUND

The last line of the displayed log says “Starting new kernel”

#18 Updated by intrigeri 2014-01-08 04:58:11

  • Subject changed from Upgrade Linux kernel without breaking memory wipe to Fix memory wipe with recent kernel
  • Target version changed from Tails_0.22.1 to Hole in the Roof

#19 Updated by intrigeri 2014-01-10 02:14:18

sajolida reports, with Tails 0.22.1~rc1 just before the freeze (linux-image-3.12-1-486 version 3.12.6-2, 32-bit):

  • success with Thinkpad X61: it starts the memory wipe and shuts down.
  • failure with Thinkpad X40: starts the memory wipe but never shuts down.

#20 Updated by sajolida 2014-02-26 19:34:17

Also reported on:

  • Hewlett-Packard HP Compaq nx6110
    • Bug report d015fcc61352b49724a8fde6df1d9479
    • Press the button and choose shutdown. Doesn’t show snow on display and doesn’t eject DVD, suggesting memory wiping may have failed. Tails 0.22 and previous showed snow on display and ejected DVD.
  • ASUSTeK K50IJ
    • Bug report c26d821e7b24914ca69d3cbe381ebbd4
    • Follow normal shutdown procedure Tails 0.22.1. Tails fails to shutdown after USB stick removal, retains data in memory that is accessible on reboot. All previous builds running on this hardware followed the same shutdown pattern — screen distorts and then machine powers down. Cold reboot examination of memory using custom low level tools reveals that besides hanging and refusing to power down machine, info is left in memory from last tails session.

#21 Updated by intrigeri 2014-02-27 08:41:14

  • Description updated

#22 Updated by intrigeri 2014-02-27 10:05:29

  • Assignee set to anonym
  • QA Check set to Ready for QA
  • Feature Branch set to feature/disable-mei

Blacklisting the mei-me and mei modules fixes this problem on the only hardware I currently have at hand that exposed the bug.

#23 Updated by anonym 2014-02-27 14:25:19

  • Assignee deleted (anonym)
  • QA Check changed from Ready for QA to Info Needed

I’ve merged feature/disable-mei just for the secondary reasons given on tails-dev@. I do not have any hardware that exhibits the issue, though, so I leave this ticket opened until we have more confirmations that it actually does.

#24 Updated by intrigeri 2014-02-27 18:27:49

  • Assignee set to intrigeri
  • QA Check changed from Info Needed to Ready for QA

#25 Updated by intrigeri 2014-02-28 10:30:27

Call for testing sent to tails-dev.

#26 Updated by winterfairy 2014-02-28 16:56:21

Tried “tails-i386-devel-0.23-20140228T0804Z-0d3192c.iso”:

3 out of 3 shutdown attempts succeeded.
The delay suggests memory wiping is working as it should.

Roughtly 60% of shutdowns fail on Tails 0.22.1.

I do believe it was fixed I while before this however,
as experimental images before this branch also have
survived 3 out of 3 shutdown attempts
(maybe kernel upgrade or amd64 fixed it).
And lsmod does not report any “mei” modules for my
computer in Tails 0.22.1.

#27 Updated by intrigeri 2014-03-03 21:50:09

As reported by Alan:

  • On thinkpad X200
    • 0.22.1 reboot instead of shutting down thrice on 3 attempts
    • exeprimental @53f0fdf shuts down thrice on 3 attempts
  • On thinkpad X200s
    • 0.22.1 reboot instead of shutting down twice on 3 attempts
    • exeprimental @53f0fdf shuts down thrice on 3 attempts
  • On thinkpad X32
    • 0.22.1 shuts down twice on 2 attempts
    • exeprimental @53f0fdf shuts down twice on 2 attempts

#28 Updated by intrigeri 2014-03-04 18:29:20

  • Status changed from Confirmed to Fix committed
  • Assignee deleted (intrigeri)
  • % Done changed from 0 to 100
  • QA Check changed from Ready for QA to Pass

anonym and I are now happy with the amount of testing this has seen.

#29 Updated by intrigeri 2014-03-06 14:37:55

  • Target version changed from Hole in the Roof to Tails_0.23

#30 Updated by anonym 2014-03-19 07:20:13

  • Status changed from Fix committed to Resolved