From: Milan Broz <mbroz@redhat.com>
To: Warren Crossing <warren.crossing@mofokom.biz>
Cc: dm-crypt@saout.de
Subject: Re: [dm-crypt] LuksResume with key on partition
Date: Fri, 07 May 2010 20:00:24 +0200 [thread overview]
Message-ID: <4BE45538.7050509@redhat.com> (raw)
In-Reply-To: <4BE425BB.9020701@mofokom.biz>
On 05/07/2010 04:37 PM, Warren Crossing wrote:
> hmmm. It now works..
>
> I seem to have miscalculated a factor of 8 somewhere, the correct size of my key was 1216bytes=9728bits
>
> I also had to change lib/utils.c to
>
> 483c483
> < for(i = 0; read_horizon == 0 || i <= read_horizon; i++) {
> ---
> > for(i = 0; read_horizon == 0 || i < read_horizon; i++) {
This seems wrong to me. It will read one byte more than expected, why?
Do you have reproducer where it fails? If so, send me the exact commands
which fails here (including example of failing key file).
Properly set -s should work here without the patch.
> .. Now I can use the following udev rule
> DRIVERS=="usb" ACTION=="remove" SUBSYSTEM=="usb", ENV{ID_SERIAL_SHORT}=="001D",
> RUN+="/usr/bin/xscreensaver-command -display :0.0 -lock"
> DRIVERS=="usb" ACTION=="remove" SUBSYSTEM=="usb", ENV{ID_SERIAL_SHORT}=="001D",
> RUN+="/sbin/cryptsetup luksSuspend safe"
hmmm. it is interesting idea, but running such commands directly from udev
is probably not ideal (not even supported).
Luckily, Suspend/resume do not depend on udev sync, so maybe
it works in this case. But luksOpen and luksCLose can deadlock here waiting for itself)
> DRIVERS=="usb" ACTION=="add" SUBSYSTEM=="usb", ENV{ID_SERIAL_SHORT}=="001D",
> RUN+="/usr/bin/xscreensaver-command -display :0.0 -deactivate"
> DRIVERS=="sd" ACTION=="add" SUBSYSTEM=="block", ENV{ID_SERIAL_SHORT}=="001D",
> RUN+="/usr/sbin/cryptsetup luksResume safe -d /dev/%k -s 9728"
"add" event means, that new device object was added to system. But it doesn't mean
that device is ready to use - it probably will work for usb device, but
only because they send event after initialization.
(I was surprised that is is implemented that way, but it is. "add" means
you can try scan device, but it can fail and you should retry on next change event...)
IOW read of key can fail. It should react to first add or change event (only
if device is suspended). Again, maybe it works in this case, but not in other.
Anyway, I think this should be done from some widget listening on system bus
(or using libudev) not in udev rules.
Milan
prev parent reply other threads:[~2010-05-07 18:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-06 8:24 [dm-crypt] LuksResume with key on partition Warren Crossing
2010-05-06 9:02 ` Milan Broz
2010-05-06 9:54 ` Warren Crossing
2010-05-06 10:02 ` Milan Broz
2010-05-06 13:26 ` Warren Crossing
2010-05-06 13:43 ` Milan Broz
2010-05-07 14:37 ` Warren Crossing
2010-05-07 18:00 ` Milan Broz [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BE45538.7050509@redhat.com \
--to=mbroz@redhat.com \
--cc=dm-crypt@saout.de \
--cc=warren.crossing@mofokom.biz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox