Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

In initramfs, do not prompt if keylocation is "file" #9764

Merged
merged 1 commit into from
Dec 26, 2019

Conversation

sam-lunt
Copy link
Contributor

If the encryption key is stored in a file, the initramfs should not
prompt for the password. This scenario is possible if the initramfs is
stored on a removable media that is only inserted when booting

Motivation and Context

I placed my /boot partition on flash drive that is only inserted at boot time (I have a home server that normally does not have a monitor attached). The initramfs is built with the key file in the location specified by the keylocation property, so there is no need for the prompt at boot time.

Description

This is a small change to the initramfs-tools script that loads the zfs filesystem. I made the corresponding change to the dracut script as well.

How Has This Been Tested?

I edited the initramfs-tools script for my system, rebuilt the initramfs, and booted successfully. I don't have a system that builds the initramfs using dracut, so that change wasn't tested directly. It's the same logic as the initramfs, however.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Performance enhancement (non-breaking change which improves efficiency)
  • Code cleanup (non-breaking change which makes code smaller or more readable)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation (a change to man pages or other documentation)

Checklist:

@PrivatePuffin
Copy link
Contributor

PrivatePuffin commented Dec 22, 2019

@sam-lunt your solution is in fact one of the best for preventing evil maid attacks and yes, ZFS should be able to handle this.

Nice find! :)

Signed-off-by might be case senstive... Interesting... shouldn't be...

@codecov
Copy link

codecov bot commented Dec 23, 2019

Codecov Report

Merging #9764 into master will decrease coverage by <1%.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff            @@
##           master    #9764    +/-   ##
========================================
- Coverage      80%      80%   -<1%     
========================================
  Files         385      385            
  Lines      121470   121470            
========================================
- Hits        96756    96701    -55     
- Misses      24714    24769    +55
Flag Coverage Δ
#kernel 80% <ø> (ø) ⬆️
#user 67% <ø> (ø) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c587b2c...cb5b875. Read the comment docs.

@sam-lunt sam-lunt force-pushed the initramfs-headless branch 2 times, most recently from f8ea830 to 13b249a Compare December 23, 2019 04:34
@sam-lunt
Copy link
Contributor Author

@sam-lunt your solution is in fact one of the best for preventing evil maid attacks and yes, ZFS should be able to handle this.

Nice find! :)

Thanks!

Signed-off-by might be case senstive... Interesting... shouldn't be...

If I need to change the commit message, just let me know.

@PrivatePuffin
Copy link
Contributor

@sam-lunt
Ofcourse you need to edit the commit message, because you are failing the style test. because (as I said) it seems the test is case sensitive ;)

@sam-lunt
Copy link
Contributor Author

@Ornias1993

Not sure why, but I read the examples as "Signed-Off-by", so I was confused what the issue was with my message. Anyway, I took a second look and fixed the issue.

@behlendorf behlendorf added the Status: Code Review Needed Ready for review and testing label Dec 23, 2019
Copy link
Member

@rlaager rlaager left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm marking this approved, as my comment changes fall into "nit" territory. I'd like to see them addressed, but this otherwise seems great to me.

If the encryption key is stored in a file, the initramfs should not
prompt for the password. For example, this could be the case if the boot
partition is stored on removable media that is only present at boot time

Signed-off-by: Sam Lunt <samuel.j.lunt@gmail.com>
Copy link
Member

@rlaager rlaager left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@behlendorf behlendorf added Status: Accepted Ready to integrate (reviewed, tested) and removed Status: Code Review Needed Ready for review and testing labels Dec 23, 2019
@PrivatePuffin
Copy link
Contributor

@behlendorf Just a reminder:
It has been flagged as "accepted" but there have been changes pushed that break zfstest.

@ghfields
Copy link
Contributor

@behlendorf Just a reminder:
It has been flagged as "accepted" but there have been changes pushed that break zfstest.

Can you be more specific to which failures you believe are from this PR? I am not seeing anything related to encryption lock state.

@behlendorf
Copy link
Contributor

behlendorf commented Dec 24, 2019

@ghfields @Ornias1993 the failures here are unrelated. Sorry, we hit an unexpected snag when updating the CI environment. Once it's sorted out, I'll resubmit this PR for a new run.

@PrivatePuffin
Copy link
Contributor

@behlendorf I noticed, forgot to edit my comment, sorry.
@ghfields Please ignore what I wrote....

@behlendorf behlendorf merged commit ad353e2 into openzfs:master Dec 26, 2019
allanjude pushed a commit to allanjude/zfs that referenced this pull request Dec 28, 2019
If the encryption key is stored in a file, the initramfs should not
prompt for the password. For example, this could be the case if the boot
partition is stored on removable media that is only present at boot time

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Garrett Fields <ghfields@gmail.com>
Reviewed-by: Richard Laager <rlaager@wiktel.com>
Reviewed-by: Kjeld Schouten <kjeld@schouten-lebbing.nl>
Signed-off-by: Sam Lunt <samuel.j.lunt@gmail.com>
Closes openzfs#9764
@sam-lunt sam-lunt deleted the initramfs-headless branch January 1, 2020 23:10
tonyhutter pushed a commit to tonyhutter/zfs that referenced this pull request Jan 2, 2020
If the encryption key is stored in a file, the initramfs should not
prompt for the password. For example, this could be the case if the boot
partition is stored on removable media that is only present at boot time

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Garrett Fields <ghfields@gmail.com>
Reviewed-by: Richard Laager <rlaager@wiktel.com>
Reviewed-by: Kjeld Schouten <kjeld@schouten-lebbing.nl>
Signed-off-by: Sam Lunt <samuel.j.lunt@gmail.com>
Closes openzfs#9764
tonyhutter pushed a commit to tonyhutter/zfs that referenced this pull request Jan 7, 2020
If the encryption key is stored in a file, the initramfs should not
prompt for the password. For example, this could be the case if the boot
partition is stored on removable media that is only present at boot time

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Garrett Fields <ghfields@gmail.com>
Reviewed-by: Richard Laager <rlaager@wiktel.com>
Reviewed-by: Kjeld Schouten <kjeld@schouten-lebbing.nl>
Signed-off-by: Sam Lunt <samuel.j.lunt@gmail.com>
Closes openzfs#9764
tonyhutter pushed a commit that referenced this pull request Jan 23, 2020
If the encryption key is stored in a file, the initramfs should not
prompt for the password. For example, this could be the case if the boot
partition is stored on removable media that is only present at boot time

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Garrett Fields <ghfields@gmail.com>
Reviewed-by: Richard Laager <rlaager@wiktel.com>
Reviewed-by: Kjeld Schouten <kjeld@schouten-lebbing.nl>
Signed-off-by: Sam Lunt <samuel.j.lunt@gmail.com>
Closes #9764
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Accepted Ready to integrate (reviewed, tested)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants