[dm-crypt] LUKS - SSD trim

[dm-crypt] LUKS - SSD trim

[Felix Blanke]

Hi,

does anybody know a way to trim a luks encrypted SSD? (btrfs filesystem
on top, but I think that doesn't count)


Regards,
Felix B.

Re: [dm-crypt] LUKS - SSD trim

[Milan Broz]

On 04/22/2010 12:48 AM, Felix Blanke wrote:
> does anybody know a way to trim a luks encrypted SSD? (btrfs filesystem
> on top, but I think that doesn't count)

TRIM is not yet supported in device-mapper devices (thus dm-crypt/LUKS too)
but it is planned.

Milan

Re: [dm-crypt] LUKS - SSD trim

[Felix Blanke]

Thanks for your reply.

Do you have any idea how long will it takes? My ssd is quiet slow
without trim :/

Regards,
Felix

Am Thu, 22 Apr 2010 01:00:01 +0200
schrieb Milan Broz <mbroz@redhat.com>:

> On 04/22/2010 12:48 AM, Felix Blanke wrote:
> > does anybody know a way to trim a luks encrypted SSD? (btrfs
> > filesystem on top, but I think that doesn't count)
> 
> TRIM is not yet supported in device-mapper devices (thus
> dm-crypt/LUKS too) but it is planned.
> 
> Milan

Re: [dm-crypt] LUKS - SSD trim

[Arno Wagner]

You can image it to a file on a conventional disk and
image it back, e.g. wioth dd_rescue. That should
also fix things, at least for a while.

Arno

On Thu, Apr 22, 2010 at 01:03:28AM +0200, Felix Blanke wrote:
> Thanks for your reply.
> 
> Do you have any idea how long will it takes? My ssd is quiet slow
> without trim :/
> 
> Regards,
> Felix
> 
> Am Thu, 22 Apr 2010 01:00:01 +0200
> schrieb Milan Broz <mbroz@redhat.com>:
> 
> > On 04/22/2010 12:48 AM, Felix Blanke wrote:
> > > does anybody know a way to trim a luks encrypted SSD? (btrfs
> > > filesystem on top, but I think that doesn't count)
> > 
> > TRIM is not yet supported in device-mapper devices (thus
> > dm-crypt/LUKS too) but it is planned.
> > 
> > Milan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

Re: [dm-crypt] LUKS - SSD trim

[Heinz Diehl]

On 22.04.2010, Felix Blanke wrote: 

> does anybody know a way to trim a luks encrypted SSD?

That's not possible because of a limitation in the underlying devicemapper.

> (btrfs filesystem on top, but I think that doesn't count)

Btrfs is specially suited for use with SSD, as a hint you could start with
what I have in fstab in the mount section: "nobarrier,ssd_spread".

Re: [dm-crypt] LUKS - SSD trim

[mark]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 22/04/10 03:17, Arno Wagner wrote:
> You can image it to a file on a conventional disk and
> image it back, e.g. wioth dd_rescue. That should
> also fix things, at least for a while.

I guess it might help to check that your partitions are aligned to the
erase blocks on the SSD, before you restore the image of your brtfs.
Look here http://www.saout.de/pipermail/dm-crypt/2010-February/000584.html

Cheers,
Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvQDAEACgkQ3b8v4BN9hRRSrgCfWeLBY437QMYCSXHPQ0m89GQd
MMQAn2kqFW6IFcEgQ3Ebo3kMmt4p/i9G
=gQav
-----END PGP SIGNATURE-----

Re: [dm-crypt] LUKS - SSD trim

[Milan Broz]

On 04/22/2010 10:42 AM, mark wrote:
> On 22/04/10 03:17, Arno Wagner wrote:
>> You can image it to a file on a conventional disk and
>> image it back, e.g. wioth dd_rescue. That should
>> also fix things, at least for a while.
> 
> I guess it might help to check that your partitions are aligned to the
> erase blocks on the SSD, before you restore the image of your brtfs.
> Look here http://www.saout.de/pipermail/dm-crypt/2010-February/000584.html

FYI: upstream svn have already automatic alignment code
(requires kernel 2.6.33 and above - topology ioclt calls supported).

I need just test it that it uses proper offset claculation:-),
but should be in cryptsetup 1.1.1

Anyway, yes - for SSD is VERY important to align the whole device stack
(partition, LUKS, LVM2, ...).
More important than TRIM support.

Milan

Re: [dm-crypt] LUKS - SSD trim

[Felix Blanke]

Hi,

first of all thank you guys a lot for helping me! 

I hope it is ok if I write one more question about those things:

I aligned the partition (which was allready fine) and the luks part to
the same value.

scooter ~ # fdisk -l /dev/sdb

Disk /dev/sdb: 160.0 GB, 160041885696 bytes
224 heads, 56 sectors/track, 24918 cylinders
Units = cylinders of 12544 * 512 = 6422528 bytes
Disk identifier: 0x5328d0af

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1          34      213220   83  Linux
/dev/sdb2              35         704     4202240   82  Linux swap /
   Solaris /dev/sdb3             705       13244    78650880   83  Linux
/dev/sdb4           13245       24918    73219328   83  Linux

scooter ~ # cryptsetup luksDump /dev/sdb4
...
Payload offset: 12544
...

The filesystem on top is btrfs. I didn't find any information about the
align thing and btrfs. I dont know mutch about align and those stuff :/


The problem is:

scooter ~ # hdparm -tT /dev/sdb3

/dev/sdb3:
 Timing cached reads:   18686 MB in  2.00 seconds = 9354.32 MB/sec
 Timing buffered disk reads:  758 MB in  3.00 seconds = 252.61 MB/sec

scooter ~ # hdparm -tT /dev/mapper/ssd 

/dev/mapper/ssd:
 Timing cached reads:   17432 MB in  2.00 seconds = 8725.18 MB/sec
 Timing buffered disk reads:  158 MB in  3.02 seconds =  52.36 MB/sec


The first value is perfect, then second one really sucks.
Obv. /dev/mapper/ssd is the decrypted /dev/sdb3

Any idea about that?


Regards,
Felix




Am Thu, 22 Apr 2010 09:42:41 +0100
schrieb mark <mark@aktivix.org>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 22/04/10 03:17, Arno Wagner wrote:
> > You can image it to a file on a conventional disk and
> > image it back, e.g. wioth dd_rescue. That should
> > also fix things, at least for a while.
> 
> I guess it might help to check that your partitions are aligned to the
> erase blocks on the SSD, before you restore the image of your brtfs.
> Look here
> http://www.saout.de/pipermail/dm-crypt/2010-February/000584.html
> 
> Cheers,
> Mark
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkvQDAEACgkQ3b8v4BN9hRRSrgCfWeLBY437QMYCSXHPQ0m89GQd
> MMQAn2kqFW6IFcEgQ3Ebo3kMmt4p/i9G
> =gQav
> -----END PGP SIGNATURE-----
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

Re: [dm-crypt] LUKS - SSD trim

[Richard Zidlicky]

On Thu, Apr 22, 2010 at 10:12:37PM +0200, Felix Blanke wrote:

> scooter ~ # hdparm -tT /dev/sdb3
> 
> /dev/sdb3:
>  Timing cached reads:   18686 MB in  2.00 seconds = 9354.32 MB/sec
>  Timing buffered disk reads:  758 MB in  3.00 seconds = 252.61 MB/sec
> 
> scooter ~ # hdparm -tT /dev/mapper/ssd 
> 
> /dev/mapper/ssd:
>  Timing cached reads:   17432 MB in  2.00 seconds = 8725.18 MB/sec
>  Timing buffered disk reads:  158 MB in  3.02 seconds =  52.36 MB/sec
> 
> 
> The first value is perfect, then second one really sucks.
> Obv. /dev/mapper/ssd is the decrypted /dev/sdb3
> 
> Any idea about that?

dm-crypt is slow - and when it is read I don't think alignment will do any difference. 
loop-AES might be faster.

Richard

Re: [dm-crypt] LUKS - SSD trim

[Richard Zidlicky]

On Thu, Apr 22, 2010 at 01:00:01AM +0200, Milan Broz wrote:
> On 04/22/2010 12:48 AM, Felix Blanke wrote:
> > does anybody know a way to trim a luks encrypted SSD? (btrfs filesystem
> > on top, but I think that doesn't count)
> 
> TRIM is not yet supported in device-mapper devices (thus dm-crypt/LUKS too)
> but it is planned.

isn't TRIM considered information leakage in the case of dm-crypt?

Richard

Re: [dm-crypt] LUKS - SSD trim

[Milan Broz]

On 04/23/2010 12:22 AM, Richard Zidlicky wrote:
> On Thu, Apr 22, 2010 at 01:00:01AM +0200, Milan Broz wrote:
>> On 04/22/2010 12:48 AM, Felix Blanke wrote:
>>> does anybody know a way to trim a luks encrypted SSD? (btrfs filesystem
>>> on top, but I think that doesn't count)
>>
>> TRIM is not yet supported in device-mapper devices (thus dm-crypt/LUKS too)
>> but it is planned.
> 
> isn't TRIM considered information leakage in the case of dm-crypt?

What do you mean? Information that some blocks are not used in device?

It depends what are you trying to do.

If it is problem, you should not use FS with TRIM support in the first place.
dm-crypt basically should support TRIM if the request comes, it is just block device.

dm-crypt is just transparent layer, it is configured some way and configuration
depends on your requirements and previous analysis.

The same logic - should I ban old ciphers and weak IV because they are insecure?
Nope, it is not dm-crypt level decision.

Milan

Re: [dm-crypt] LUKS - SSD trim

[Mikko Rauhala]

pe, 2010-04-23 kello 10:49 +0200, Milan Broz kirjoitti:
> On 04/23/2010 12:22 AM, Richard Zidlicky wrote:
> > isn't TRIM considered information leakage in the case of dm-crypt?

It is leakage indeed, but for many purposes acceptable at least as such.

I personally would want TRIM support on my dm-crypt-on-lvm SSD to
improve lifetime and performance; I'm not too worried about leaking
empty block information. (I would be somewhat interested though if
someone knows of particular ways that empty block data could leak other
information; known-plaintext attacks against filesystem data structures
and through them against the encryption key springs to mind, but I
recognize I'm just talking out of my ass here, grasping at worst-case
straws.)

I do think that dm-crypt, as a security solution, should probably offer
optional dropping of TRIM commands when dm gains support for it; some
uses may be more sensitive (and/or some users may wish to wear thicker
tinfoil than myself). This is probably not critical, though:

> If it is problem, you should not use FS with TRIM support in the first place.
> dm-crypt basically should support TRIM if the request comes, it is just block
> device.

This would detract from the usefulness of dm-crypt, as you would be
artificially limited in what you can run on top of it to meet your
paranoia quota. However, considering in addition that many (most/all? -
at least ext4, btrfs, gfs2) filesystems that make use of TRIM on Linux
do appear on a quick glance to make this optional through the
(no)discard mount options, it wouldn't indeed be a very bad thing for
dm-crypt to Just Do It anyway.

> dm-crypt is just transparent layer, it is configured some way and
> configuration depends on your requirements and previous analysis.

A "Drop TRIMs" flag could still be useful as just such a configuration
option that you could set accordingly after said analysis, the ability
to _often_ block TRIMs higher up on the stack notwithstanding.

-- 
Mikko Rauhala <mjr@iki.fi>       - http://www.iki.fi/mjr/blog/  
The Finnish Pirate Party         - http://piraattipuolue.fi/  
World Transhumanist Association  - http://transhumanism.org/  
Singularity Institute            - http://singinst.org/  

Re: [dm-crypt] LUKS - SSD trim

[Richard Zidlicky]

On Fri, Apr 23, 2010 at 10:49:23AM +0200, Milan Broz wrote:
> On 04/23/2010 12:22 AM, Richard Zidlicky wrote:

> > isn't TRIM considered information leakage in the case of dm-crypt?
> 
> What do you mean? Information that some blocks are not used in device?

yes.

> If it is problem, you should not use FS with TRIM support in the first place.
> dm-crypt basically should support TRIM if the request comes, it is just block device.

Layering problem. Traditionally dm-crypt was expected to provide fs agnostic transparent 
encryption. TRIM is something that breaks the layering assumption. 

> The same logic - should I ban old ciphers and weak IV because they are insecure?
> Nope, it is not dm-crypt level decision.

these are useful only in case someone has such an obsolete volume. But you would not 
seriously consider implementing new known weak features just on the ground that the user 
can choose some workaround?

I am not against having the possibility to pass through ata trim but it is debatable
whether this should be the default behaviour.

Richard

Re: [dm-crypt] LUKS - SSD trim

[Milan Broz]

On 04/23/2010 01:13 PM, Richard Zidlicky wrote:
> On Fri, Apr 23, 2010 at 10:49:23AM +0200, Milan Broz wrote:

>> The same logic - should I ban old ciphers and weak IV because they are insecure?
>> Nope, it is not dm-crypt level decision.
> 
> these are useful only in case someone has such an obsolete volume. But you would not 
> seriously consider implementing new known weak features just on the ground that the user 
> can choose some workaround?

That's why there are safe defaults in cryptsetup (userspace).
I just said that dm-crypt should be able to process it - where it should be configurable
is another question.

> I am not against having the possibility to pass through ata trim but it is debatable
> whether this should be the default behaviour.

Currently core device-mapper doesn't support TRIM at all. There must be
per dm target implementation - so we can selectively disable that anyway.

So yes, kernel module option and/or optional mapping table parameter can be added.
Well, no problem, already two requests for that:-)

If the default should be reject it - I am really not sure...

We have already this situation:
 - zeroed disk (not randomised) and encryption.
You easily see which blocks were written and which are unused.
- almost the same if you can snapshot underlying device in time (ciphertext only).
It is not new problem IMHO. TRIM makes it only worse.

Milan

Re: [dm-crypt] LUKS - SSD trim

[Richard Zidlicky]

On Fri, Apr 23, 2010 at 01:46:33PM +0200, Milan Broz wrote:

> If the default should be reject it - I am really not sure...
> 
> We have already this situation:
>  - zeroed disk (not randomised) and encryption.

people are known to initialise disks manually. But true, it would be cool if it
could be added as a no-brainer (optional) for those who don't.

> You easily see which blocks were written and which are unused.
> - almost the same if you can snapshot underlying device in time (ciphertext only).
> It is not new problem IMHO. TRIM makes it only worse.

there is a huge immediate difference for some people: deniability (assuming the user was 
smart enough not to use a previously zeroed disk). 

As of cryptographic attacks: I have no idea how easy it is to retrieve the TRIM data and how 
it is stored internally. But in the worst (and not quite unlikely) case the device would have 
something like a log-structured trim record which - if extracted by some means would reveal 
not only the free block count but would allow to infer things like file sizes of almost all 
files and lots of the filesystem structure and history. 
It is impossible to overestimate the worst case information leak in this scenario. 

So even in case the disk was not cleverly filled by garbage it could still make a huge 
difference in some cases.

Richard

Re: [dm-crypt] LUKS - SSD trim

[Milan Broz]

On 04/23/2010 10:09 PM, Richard Zidlicky wrote:
> On Fri, Apr 23, 2010 at 01:46:33PM +0200, Milan Broz wrote:

> As of cryptographic attacks: I have no idea how easy it is to retrieve the TRIM data and how 
> it is stored internally. But in the worst (and not quite unlikely) case the device would have 
> something like a log-structured trim record which - if extracted by some means would reveal 
> not only the free block count but would allow to infer things like file sizes of almost all 
> files and lots of the filesystem structure and history. 
> It is impossible to overestimate the worst case information leak in this scenario. 

I asked how TRIM (and SCSI discard) is handled and it seems that most of drives zeroes
trimmed blocks (or the function is internal to drive - so undefined, we must expect the worst case).

So it is clear that an attacker can recognize which block was trimmed (reading
zeroed blocks instead of "random" data). If there is some internal drive data
related to TRIM available, it can be even worse.

So the option to disable TRIM requests in dm-crypt layer seems to be quite useful
option to avoid these possible leaks.

> So even in case the disk was not cleverly filled by garbage it could still make a huge 
> difference in some cases.

yes.
Still probably most of people can ignore it (even leaking of file & disk sizes is not problem),
but according to above, you are right it should default to safe operation.

(I used a quite stupid example to demonstrate the problem - take several SSD empty disks,
use encryption and then format it with FS which TRIMs free space. Use one disk to store
backup. Without TRIM you cannot say which disk contains data, with TRIM you can scan
disk and see used block statistics - so you know which disk you should watch or install
hacked fw etc:-)

Milan

Re: [dm-crypt] LUKS - SSD trim

[Richard Zidlicky]

On Fri, Apr 23, 2010 at 10:45:34PM +0200, Milan Broz wrote:

> I asked how TRIM (and SCSI discard) is handled and it seems that most of drives zeroes
> trimmed blocks (or the function is internal to drive - so undefined, we must expect the worst case).
> 
> So it is clear that an attacker can recognize which block was trimmed (reading
> zeroed blocks instead of "random" data). If there is some internal drive data
> related to TRIM available, it can be even worse.

it can be even much worse. The most evil case is a specially crafted device manufactured
by a mighty agency which will record every single read/write/trim command. A few weeks ago
it was on the news here that most copiers have builtin hard discs and make copies of what
people are copying.. so who knows what is in our ordinary hard discs today.

The second most evil - and very realistic scenario is that any drive can have a log storing 
trim states/operations. If its an SSD device that log could be *very* huge if we are 
unlucky.  Although I am not an expert on this devices I would think it is the obvious way 
to do it. All the information about trimmed blocks must be stored somewhere and in order 
to keep the "wear" low its likely to be log-structured, not a simple bitmask. 
There is not an official way to retrieve this backlog but there may be device specific 
undocumented proprietary ways to do it or someone might open the chip. 

But there sure is no way to guarantee that any information that is ever entrusted to a blackbox
device might not resurface again.

Richard

Re: [dm-crypt] LUKS - SSD trim

[Arno Wagner]

On Sat, Apr 24, 2010 at 12:59:18AM +0200, Richard Zidlicky wrote:
> On Fri, Apr 23, 2010 at 10:45:34PM +0200, Milan Broz wrote:
> 
> > I asked how TRIM (and SCSI discard) is handled and it seems that most of drives zeroes
> > trimmed blocks (or the function is internal to drive - so undefined, we must expect the worst case).
> > 
> > So it is clear that an attacker can recognize which block was trimmed (reading
> > zeroed blocks instead of "random" data). If there is some internal drive data
> > related to TRIM available, it can be even worse.
> 
> it can be even much worse. The most evil case is a specially crafted device manufactured
> by a mighty agency which will record every single read/write/trim command. A few weeks ago
> it was on the news here that most copiers have builtin hard discs and make copies of what
> people are copying.. so who knows what is in our ordinary hard discs today.

Only as temporary storage. Better copiers do a secure erase after
the copy as well, but not all do. It is something copiers used
for secret material can get certified for.
 
> The second most evil - and very realistic scenario is that any drive can
> have a log storing trim states/operations. If its an SSD device that log
> could be *very* huge if we are unlucky.  Although I am not an expert on
> this devices I would think it is the obvious way to do it. All the
> information about trimmed blocks must be stored somewhere and in order to
> keep the "wear" low its likely to be log-structured, not a simple bitmask. 
> There is not an official way to retrieve this backlog but there may be
> device specific undocumented proprietary ways to do it or someone might
> open the chip.
>
> But there sure is no way to guarantee that any information that is ever
> entrusted to a blackbox device might not resurface again.

That is way you use encryoption on top. However, it is higly unlikely
current HDDs/SSDs store a lot of information of this type. The storage
space is just not there.

Arno

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

Re: [dm-crypt] LUKS - SSD trim

[Richard Zidlicky]

On Sat, Apr 24, 2010 at 05:59:15PM +0200, Arno Wagner wrote:
> On Sat, Apr 24, 2010 at 12:59:18AM +0200, Richard Zidlicky wrote:

> > it can be even much worse. The most evil case is a specially crafted device manufactured
> > by a mighty agency which will record every single read/write/trim command. A few weeks ago
> > it was on the news here that most copiers have builtin hard discs and make copies of what
> > people are copying.. so who knows what is in our ordinary hard discs today.
> 
> Only as temporary storage. Better copiers do a secure erase after
> the copy as well, but not all do. It is something copiers used
> for secret material can get certified for.

very offtopic, I would think there is certainly pressure from various agencies and companies
not to erase anything. Given that printers are programmed to print secret identification 
patterns on every page there could be quite a few surprises lurking in copiers.

> That is way you use encryoption on top. However, it is higly unlikely
> current HDDs/SSDs store a lot of information of this type. The storage
> space is just not there.

most will do clever traffic analysis trying to predict access patterns at the very least. 
Most likely not store everything to survive reboots but there can be exceptions.

Richard

Re: [dm-crypt] LUKS - SSD trim

[Arno Wagner]

On Sat, Apr 24, 2010 at 06:44:52PM +0200, Richard Zidlicky wrote:
[...]
> very offtopic, I would think there is certainly pressure from various
> agencies and companies not to erase anything. Given that printers are
> programmed to print secret identification patterns on every page there
> could be quite a few surprises lurking in copiers.

Only for color printers. It serves to identify a printer that was 
used in couterfiting currency. Storing everything in copiers is 
infeasible. Thstorage available is just about enough for the largest 
possible print-job, usually not more than 1000 or so different pages.
Given that this limit is routinely exceeded in a day, almost all
pages will not be stored.

> > That is way you use encryoption on top. However, it is higly unlikely
> > current HDDs/SSDs store a lot of information of this type. The storage
> > space is just not there.
> 
> most will do clever traffic analysis trying to predict access patterns at
> the very least.  Most likely not store everything to survive reboots but
> there can be exceptions.

Sorry, but I openend my SSD. There are just no bits in there for this.
My 30GB SSD has 2GB extra storage, most used for spares for broken
cells. The rest cannot store a lot. In addition, the SSD does not have a
clock that would be essential for adding timestamps to a data access
pattern log.

Here is a story from my country some years back. The federal prolice 
wanted to have all emails copied and archived. The ISPs responded
with the query where the cubic-meter of DAT tapes per day should
go? After this (and after realizing the cost, which the police would 
have had to pay), the proposal was off the table.

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

Re: [dm-crypt] LUKS - SSD trim

[JG]

hi,

you can try the modified version of the wiper.sh script (originally by
mark lord but the new patches have not been commented by him so take
care and do what the poster says => backup :)) for trimming a dmcrypt
partition.
i just tested it and so far i found no problems or changes in
comparison to my backup regarding trim.

https://sourceforge.net/tracker/index.php?func=detail&aid=2997551&group_id=136732&atid=736684

--------
one question regarding alignment whether the following is correct. i
used the latest tools which should do this automatically:
fdisk (util-linux-ng 2.17.2) + cryptsetup 1.1.1-rc2, created with some
2.6.33.x kernel (don't know for sure anymore, i'm now running 2.6.33.4).


# fdisk -luc /dev/sda

Disk /dev/sda: 100.0 GB, 100030242816 bytes
255 heads, 63 sectors/track, 12161 cylinders, total 195371568 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xe2d5b28c

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1            2048      145407       71680   83  Linux
/dev/sda2          145408     4339711     2097152   82  Linux swap
/dev/sda3         4339712   195371567    95515928    5  Extended
/dev/sda5         4341760    98713599    47185920   83  Linux
/dev/sda6        98715648   193087487    47185920   83  Linux

/dev/sda5 e.g. is a cryptsetup/luks partition:
# cryptsetup luksDump /dev/sda5 | grep Payload
Payload offset: 4040

JG

Re: [dm-crypt] LUKS - SSD trim

[Christoph Anton Mitterer]

Hi.

Just a few thoughts and questions on this:

1) Was it decided now, that TRIM will by default be blocked at dm-crypt level?


2) A solution that came up was to make blocking configurable via  
module parameter. Wouldn't it be better to configure that as option in  
the LUKS header and/or per device when setting up the dm-crypt- or  
LUKS-mapping via crpytsetup?

The reason is that one might not want to set this globally for _all_  
dm-crypt devices... e.g. swap might have not that tight  
security-constraints (regarding deniability nad so on) as a pure data  
partition... so one might want to chose that some for some dm-crypt  
devices TRIM is passed on, while for others not.


3) Blocking/announcing TRIM at the dm-crypt block device to higher  
level things (especially filesystems).
I assume block devices somehow announce their capabilities (in that  
case) trim to userspace and the kernel, right?
I further assume that also dm-crypt devices (/dev/mapper/sda1 or so)  
pass this somehow on.. in both directions,.. up (to kernel/userspace)  
and down (to kernel, e.g. LVM or RAID sitting below), right? I mean a  
filesystem like btrfs/ext4 must somehow know whether the disk is an  
SSD or not, and in addition whether it supports TRIM.
Right so far?

a) How far is this already implemented in the meantime, and in  
starting with which kernel version? I read at some place that dm  
itself would not yet support it?

b) If we consider that we probably block TRIM,... is this properly  
propagated to things on top (filesystems, userspace stuff like hdparm).
I mean just silently discarding TRIM could lead to problems if a fs  
like btrfs thinks that TRIM is suppored and behaves specially because  
of this,... but it never reaches the device.



Thanks,
Chris.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.