Project

General

Profile

Bug #10831

Update nopersistent boot parameter

Added by intrigeri about 3 years ago. Updated about 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Persistence
Target version:
Start date:
12/31/2015
Due date:
% Done:

100%

QA Check:
Pass
Feature Branch:
bugfix/persistence-fixes-for-2.0-take1
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

Apparently, since live-boot (3.0~a27-1) and this commit:

commit 4e54d60d7f69ae3441e519e5611bd7ea48a8be19
Author: Daniel Baumann <daniel@debian.org>
Date:   Sun Apr 8 18:29:45 2012 +0200

    Using 'persistence' (noun) rather than 'persistent' (adjective/adverb) everywhere.

... we should use nopersistence instead of nopersistent on the kernel command line.

Strangely, db4e9230ebf36cbe6fa0f451a90d29d9ce4d7ec3 updates the design doc while the code is unchanged. Too bad we didn't have an automated test for the way live-boot handles persistence in the initramfs.

This may has security implications, to be confirmed (the fact we're passing live-media=removable might help quite a bit).

Associated revisions

Revision 3f57f379 (diff)
Added by intrigeri about 3 years ago

Update 'nopersistent' boot parameter to 'nopersistence'.

Since live-boot (3.0~a27-1) and this commit:

commit 4e54d60d7f69ae3441e519e5611bd7ea48a8be19
Author: Daniel Baumann &lt;&gt;
Date: Sun Apr 8 18:29:45 2012 +0200
Using 'persistence' (noun) rather than 'persistent'
(adjective/adverb) everywhere.

... we should have been passing 'nopersistence' instead of 'nopersistent' on the
kernel command line.

Will-fix: #10831

Revision aeee0d93
Added by anonym about 3 years ago

Merge remote-tracking branch 'origin/bugfix/persistence-fixes-for-2.0-take1' into devel

Fix-committed: #10784, #10809, #10831, #10832

History

#1 Updated by intrigeri about 3 years ago

  • Description updated (diff)

#2 Updated by intrigeri about 3 years ago

  • Description updated (diff)

#3 Updated by intrigeri about 3 years ago

  • Status changed from Confirmed to In Progress
  • Priority changed from High to Normal
  • % Done changed from 0 to 10
  • Private changed from Yes to No
  • Feature Branch set to bugfix/10831-update-nopersistent-boot-parameter

Thanks to live-media=removable, the impact of this mistake is that indeed live-boot looks for persistent volumes (for the rootfs and home directory) on removable storage media at boot. This is useless and suboptimal, and might slow down the boot a bit, but at least it does not break our design goal of not trusting internal hard drives: we're instructing live-boot to look for the root SquashFS on any plugged removable storage device, that are considered to be trusted, so letting it look for overlays there as well does not break our current security model (if we had #7475 already, this analysis would be different).

On the test suite side: we're already testing that live-media=removable is effective when it comes to looking for the root squashfs. This parameter bypasses persistence/nopersistence, so I don't think we need to add a specific test case. Now, perhaps it would be useful as a regression test, to let us notice e.g. any regression in the handling of live-media=removable => kytv, this may be a good candidate for your "write regression tests" mission; keep in mind that we're talking about live-boot's regular persistence features here, that happen at initramfs time, not the weird way we're using them for TailsData later in the boot process. I'll let you create the corresponding ticket.

#4 Updated by intrigeri about 3 years ago

  • Assignee changed from intrigeri to anonym
  • % Done changed from 10 to 50
  • QA Check set to Ready for QA

I'll do a test suite run to check that the proposed persistent-related changes don't break anything, but I'd like to do it only once so I'll work on #10809 first, so here you go.

#5 Updated by intrigeri about 3 years ago

  • Feature Branch changed from bugfix/10831-update-nopersistent-boot-parameter to bugfix/persistence-fixes-for-2.0-take1

#6 Updated by anonym about 3 years ago

  • Status changed from In Progress to Fix committed
  • % Done changed from 50 to 100

#7 Updated by anonym about 3 years ago

  • Assignee deleted (anonym)

Thanks to live-media=removable, the impact of this mistake is that indeed live-boot looks for persistent volumes (for the rootfs and home directory) on removable storage media at boot. This is useless and suboptimal, and might slow down the boot a bit, but at least it does not break our design goal of not trusting internal hard drives: we're instructing live-boot to look for the root SquashFS on any plugged removable storage device, that are considered to be trusted, so letting it look for overlays there as well does not break our current security model (if we had #7475 already, this analysis would be different).

Thanks for spelling out the analysis clearly. I agree that there was no harm done. Phew!

#8 Updated by anonym about 3 years ago

  • QA Check changed from Ready for QA to Pass

#9 Updated by intrigeri about 3 years ago

Thanks for spelling out the analysis clearly.

Well, initially I started to write it thinking it would end up in a security advisory. Thankfully, that's not needed in the end.

#10 Updated by anonym about 3 years ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF