[dm-crypt] Recover from Spontaneous Ejection

[dm-crypt] Recover from Spontaneous Ejection

[Frederick Gotham]

[-- Attachment #1: Type: text/html, Size: 2402 bytes --]

[-- Attachment #2: Type: text/plain, Size: 135 bytes --]

_______________________________________________
dm-crypt mailing list
dm-crypt@saout.de
https://www.saout.de/mailman/listinfo/dm-crypt

Re: [dm-crypt] Recover from Spontaneous Ejection

[Milan Broz]

On 20/01/2021 12:06, Frederick Gotham wrote:
> 
> I'm developing a product running embedded Linux.
> 
> We have an SDcard with one partition on it, and this partition is an
> encrypted LUKS volume.
> 
> While the SDcard is mounted, the user can spontaneously eject the
> SDcard. I have successfully altered the UDEV script to handle this
> eventuality, as follows:
> 
> umount /mnt/sdcard cryptsetup luksClose cryptocard
> 
> Then when the user re-inserts the SDcard after a spontaneous
> ejection, I try to re-mount it again. So the entire process from
> start to finish goes as follows:
> 
> echo -n password | cryptsetup luksOpen /dev/sdb1 cryptocard - mount
> /dev/mapper/cryptocard /mnt/sdcard [ User spontaneously ejects SDcard
> ] umount /mnt/sdcard cryptsetup luksClose cryptocard [ ... ... ... 1
> minute goes by ... ... ... ] [         User re-inserts SD card
> ] echo -n password | cryptsetup luksOpen /dev/sdb1 cryptocard - mount
> /dev/mapper/cryptocard /mnt/sdcard
> 
> This appears to work just fine, however when I try to do more complex
> write operations, it starts to freak out a little (files that were
> previously visible are no longer visible). When I reboot the machine,
> everything's working fine again.
> 
> So it seems that the system is not adequately recovering from the
> spontaneous ejection of the SDcard. Do I need to somehow "flush out"
> the LUKS system in order to successfully re-mount the volume? Is it
> possible to 'restart' the LUKS subsystem to get this to work properly
> again? I only ever have one LUKS volume open at a time so I don't
> have to worry about closing other volumes before 'flushing out'.

There is nothing like LUKS subsystem running - it is only kernel dm-crypt
configuration that need to be removed. Cryptsetup can only wait here for kernel.

What you see here is probably that something in kernel is blocking the dm-device
until some timeout expires (see lsblk; dmsetup info).

You can try to use "dmsetup remove --force <name>" instead of luksClose here
(that will try to replace dm-crypt with error target if there are active users,
that should fail more quickly).

For the flush - there is nothing to flush, underlying device already disappeared.
You should see the same problem even without LUKS/dmcrypt.

If you see this more often, perhaps report it to the distribution,
if it is your own distro, then you need to setup udev/kernel properly.

Milan
_______________________________________________
dm-crypt mailing list
dm-crypt@saout.de
https://www.saout.de/mailman/listinfo/dm-crypt

Re: [dm-crypt] Recover from Spontaneous Ejection

[Frederick Gotham]

[-- Attachment #1: Type: text/html, Size: 4080 bytes --]

[-- Attachment #2: Type: text/plain, Size: 135 bytes --]

_______________________________________________
dm-crypt mailing list
dm-crypt@saout.de
https://www.saout.de/mailman/listinfo/dm-crypt

[dm-crypt] Fw: Re: Recover from Spontaneous Ejection

[Frederick Gotham]

Actually my script is only working sometimes.

Sometimes dmsetup fails to remove the device and says 'ioctl device is busy'. When I try to enquire into which process is using the LUKS volume, it doesn't show any. I have confirmed that the LUKS volume isn't listed in '/proc/mounts', so it's definitely not mounted.

Even if I use the '--force' option with dmsetup, it still fails to remove the node from '/dev/mapper'.

I have tried deleting the node myself with 'rm /dev/mapper/monkeydisk', and while this succeeds in removing the node from the Linux file system, it still doesn't allow me to open the LUKS volume again with 'cryptsetup luksOpen' (it comes back with the error 'Device already open').

So is there anything more I can do to forcefully close the LUKS volume and remove the node from '/dev/mapper', so that I can then go on to re-open the LUKS volume and re-mount it?

(I of course realise that the user shouldn't be spontaneously pulling out the SDcard while it's still mounted, but I'm trying to make the best of a bad situation here).





 Sent: Wednesday, January 20, 2021 at 4:07 PM
> From: "Frederick Gotham" <thomas123@gmx.ca>
> To: dm-crypt@saout.de
> Cc: gmazyland@gmail.com
> Subject: Re: [dm-crypt] Recover from Spontaneous Ejection
>
> 
> 
>  
>  
> In my UDEV script that handles the spontaneous ejection of SDcards, I have replaced "cryptsetup luksClose" with "dmsetup remove --force".
>  
> This solution worked, thanks Milan.
>  
> Of course ideally I don't want the user to spontaneously remove the SDcard from the slot without unmounting it first, but at least I can make a good attempt to recover from this scenario.
>  
>  
>  
>  
> 
> Sent: Wednesday, January 20, 2021 at 11:23 AM
> From: "Milan Broz" <gmazyland@gmail.com>
> To: "Frederick Gotham" <thomas123@gmx.ca>, dm-crypt@saout.de
> Subject: Re: [dm-crypt] Recover from Spontaneous Ejection
> On 20/01/2021 12:06, Frederick Gotham wrote:
> >
> > I'm developing a product running embedded Linux.
> >
> > We have an SDcard with one partition on it, and this partition is an
> > encrypted LUKS volume.
> >
> > While the SDcard is mounted, the user can spontaneously eject the
> > SDcard. I have successfully altered the UDEV script to handle this
> > eventuality, as follows:
> >
> > umount /mnt/sdcard cryptsetup luksClose cryptocard
> >
> > Then when the user re-inserts the SDcard after a spontaneous
> > ejection, I try to re-mount it again. So the entire process from
> > start to finish goes as follows:
> >
> > echo -n password | cryptsetup luksOpen /dev/sdb1 cryptocard - mount
> > /dev/mapper/cryptocard /mnt/sdcard [ User spontaneously ejects SDcard
> > ] umount /mnt/sdcard cryptsetup luksClose cryptocard [ ... ... ... 1
> > minute goes by ... ... ... ] [ User re-inserts SD card
> > ] echo -n password | cryptsetup luksOpen /dev/sdb1 cryptocard - mount
> > /dev/mapper/cryptocard /mnt/sdcard
> >
> > This appears to work just fine, however when I try to do more complex
> > write operations, it starts to freak out a little (files that were
> > previously visible are no longer visible). When I reboot the machine,
> > everything's working fine again.
> >
> > So it seems that the system is not adequately recovering from the
> > spontaneous ejection of the SDcard. Do I need to somehow "flush out"
> > the LUKS system in order to successfully re-mount the volume? Is it
> > possible to 'restart' the LUKS subsystem to get this to work properly
> > again? I only ever have one LUKS volume open at a time so I don't
> > have to worry about closing other volumes before 'flushing out'.
> 
> There is nothing like LUKS subsystem running - it is only kernel dm-crypt
> configuration that need to be removed. Cryptsetup can only wait here for kernel.
> 
> What you see here is probably that something in kernel is blocking the dm-device
> until some timeout expires (see lsblk; dmsetup info).
> 
> You can try to use "dmsetup remove --force <name>" instead of luksClose here
> (that will try to replace dm-crypt with error target if there are active users,
> that should fail more quickly).
> 
> For the flush - there is nothing to flush, underlying device already disappeared.
> You should see the same problem even without LUKS/dmcrypt.
> 
> If you see this more often, perhaps report it to the distribution,
> if it is your own distro, then you need to setup udev/kernel properly.
> 
> Milan
_______________________________________________
dm-crypt mailing list
dm-crypt@saout.de
https://www.saout.de/mailman/listinfo/dm-crypt

Re: [dm-crypt] Recover from Spontaneous Ejection

[Arno Wagner]

You may run into the issue where that SD cards (like SSDs) may
actually use larger block-sizes than exposed at the interface.
Hence interrupting a write may damage parts that were not 
requested to be written.

SSDs have that mostly under control now, I think, probably by
adding some more complex commit schemes. But SD cards have 
far less comuting power and may not do that.

Regards,
Arno



On Wed, Jan 20, 2021 at 12:06:24 CET, Frederick Gotham wrote:
> 
>    I'm developing a product running embedded Linux.
> 
>    We have an SDcard with one partition on it, and this partition is an
>    encrypted LUKS volume.
> 
>    While the SDcard is mounted, the user can spontaneously eject the
>    SDcard. I have successfully altered the UDEV script to handle this
>    eventuality, as follows:
> 
>        umount /mnt/sdcard
>        cryptsetup luksClose cryptocard
> 
>    Then when the user re-inserts the SDcard after a spontaneous ejection,
>    I try to re-mount it again. So the entire process from start to finish
>    goes as follows:
> 
>        echo -n password | cryptsetup luksOpen /dev/sdb1 cryptocard -
>        mount /dev/mapper/cryptocard /mnt/sdcard
>        [ User spontaneously ejects SDcard  ]
>        umount /mnt/sdcard
>        cryptsetup luksClose cryptocard
>        [ ... ... ... 1 minute goes by ... ... ... ]
>        [         User re-inserts SD card         ]
>        echo -n password | cryptsetup luksOpen /dev/sdb1 cryptocard -
>        mount /dev/mapper/cryptocard /mnt/sdcard
> 
>    This appears to work just fine, however when I try to do more complex
>    write operations, it starts to freak out a little (files that were
>    previously visible are no longer visible). When I reboot the machine,
>    everything's working fine again.
> 
>    So it seems that the system is not adequately recovering from the
>    spontaneous ejection of the SDcard. Do I need to somehow "flush out"
>    the LUKS system in order to successfully re-mount the volume? Is it
>    possible to 'restart' the LUKS subsystem to get this to work properly
>    again? I only ever have one LUKS volume open at a time so I don't have
>    to worry about closing other volumes before 'flushing out'.
> 
>    Frederick

> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> https://www.saout.de/mailman/listinfo/dm-crypt


-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier
_______________________________________________
dm-crypt mailing list
dm-crypt@saout.de
https://www.saout.de/mailman/listinfo/dm-crypt