Hello,

I have not looked at encryption before and find myself in a situation
that I have to encrypt my hard drive. I keep /, /boot, and swap outside
LVM, everything else is under LVM. I think all I need to do is to
encrypt /home which is under LVM. I use reiserfs.

I would appreciate suggestion and pointers on what it is practical and
simple in order to accomplish this task with a minimum of downtime.

Thanks,

--
Valmor

Am 11.03.2012 16:38, schrieb Valmor de Almeida:
>
> Hello,
>
> I have not looked at encryption before and find myself in a situation
> that I have to encrypt my hard drive. I keep /, /boot, and swap outside
> LVM, everything else is under LVM. I think all I need to do is to
> encrypt /home which is under LVM. I use reiserfs.
>
> I would appreciate suggestion and pointers on what it is practical and
> simple in order to accomplish this task with a minimum of downtime.
>
> Thanks,
>
> --
> Valmor
>


Is it acceptable for you to have a commandline prompt for the password
when booting? In that case you can use LUKS with the /etc/init.d/dmcrypt
init script. /etc/conf.d/dmcrypt should contain some examples. As you
want to encrypt an LVM volume, the lvm init script needs to be started
before this. As I see it, there is no strict dependency between those
two scripts. You can add this by adding this line to /etc/rc.conf:
rc_dmcrypt_after="lvm"

For creating a LUKS-encrypted volume, look at
http://en.gentoo-wiki.com/wiki/DM-Crypt

You won't need most of what is written there; just section 9,
"Administering LUKS" and the kernel config in section 2, "Assumptions".

Concerning downtime, I'm not aware of any solution that avoids copying
the data over to the new volume. If downtime is absolutely critical, ask
and we can work something out that minimizes the time.

Regards,
Florian Philipp

On 03/11/2012 02:29 PM, Florian Philipp wrote:
> Am 11.03.2012 16:38, schrieb Valmor de Almeida:
>>
>> Hello,
>>
>> I have not looked at encryption before and find myself in a situation
>> that I have to encrypt my hard drive. I keep /, /boot, and swap outside
>> LVM, everything else is under LVM. I think all I need to do is to
>> encrypt /home which is under LVM. I use reiserfs.
>>
>> I would appreciate suggestion and pointers on what it is practical and
>> simple in order to accomplish this task with a minimum of downtime.
>>
>> Thanks,
>>
>> --
>> Valmor
>>
>
>
> Is it acceptable for you to have a commandline prompt for the password
> when booting? In that case you can use LUKS with the /etc/init.d/dmcrypt

I think so.

> init script. /etc/conf.d/dmcrypt should contain some examples. As you
> want to encrypt an LVM volume, the lvm init script needs to be started
> before this. As I see it, there is no strict dependency between those
> two scripts. You can add this by adding this line to /etc/rc.conf:
> rc_dmcrypt_after="lvm"
>
> For creating a LUKS-encrypted volume, look at
> http://en.gentoo-wiki.com/wiki/DM-Crypt

Currently looking at this.

>
> You won't need most of what is written there; just section 9,
> "Administering LUKS" and the kernel config in section 2, "Assumptions".
>
> Concerning downtime, I'm not aware of any solution that avoids copying
> the data over to the new volume. If downtime is absolutely critical, ask
> and we can work something out that minimizes the time.
>
> Regards,
> Florian Philipp
>

Since I am planning to encrypt only home/ under LVM control, what kind
of overhead should I expect?

Thanks,

--
Valmor

Am 13.03.2012 12:55, schrieb Valmor de Almeida:
> On 03/11/2012 02:29 PM, Florian Philipp wrote:
>> Am 11.03.2012 16:38, schrieb Valmor de Almeida:
>>>
>>> Hello,
>>>
>>> I have not looked at encryption before and find myself in a situation
>>> that I have to encrypt my hard drive. I keep /, /boot, and swap outside
>>> LVM, everything else is under LVM. I think all I need to do is to
>>> encrypt /home which is under LVM. I use reiserfs.
>>>
>>> I would appreciate suggestion and pointers on what it is practical and
>>> simple in order to accomplish this task with a minimum of downtime.
>>>
>>> Thanks,
>>>
>>> --
>>> Valmor
>>>
>>
>>
>> Is it acceptable for you to have a commandline prompt for the password
>> when booting? In that case you can use LUKS with the /etc/init.d/dmcrypt
>
> I think so.
>
>> init script. /etc/conf.d/dmcrypt should contain some examples. As you
>> want to encrypt an LVM volume, the lvm init script needs to be started
>> before this. As I see it, there is no strict dependency between those
>> two scripts. You can add this by adding this line to /etc/rc.conf:
>> rc_dmcrypt_after="lvm"
>>
>> For creating a LUKS-encrypted volume, look at
>> http://en.gentoo-wiki.com/wiki/DM-Crypt
>
> Currently looking at this.
>
>>
>> You won't need most of what is written there; just section 9,
>> "Administering LUKS" and the kernel config in section 2, "Assumptions".
>>
>> Concerning downtime, I'm not aware of any solution that avoids copying
>> the data over to the new volume. If downtime is absolutely critical, ask
>> and we can work something out that minimizes the time.
>>
>> Regards,
>> Florian Philipp
>>
>
> Since I am planning to encrypt only home/ under LVM control, what kind
> of overhead should I expect?
>
> Thanks,
>

What do you mean with overhead? CPU utilization? In that case the
overhead is minimal, especially when you run a 64-bit kernel with the
optimized AES kernel module.

Measured on a Core i5:
time cat Video/*.* >/dev/null

real 0m42.918s
user 0m0.023s
sys 0m2.027s

That was a sequential read of roughly 3.5GB with empty caches. This
corresponds to the normal disk speed.

Regards,
Florian Philipp

On Tue, Mar 13, 2012 at 12:11 PM, Florian Philipp <lists@binarywings.net> wrote:
> Am 13.03.2012 12:55, schrieb Valmor de Almeida:
>> On 03/11/2012 02:29 PM, Florian Philipp wrote:
>>> Am 11.03.2012 16:38, schrieb Valmor de Almeida:
>>>>
>>>> Hello,
>>>>
>>>> I have not looked at encryption before and find myself in a situation
>>>> that I have to encrypt my hard drive. I keep /, /boot, and swap outside
>>>> LVM, everything else is under LVM. I think all I need to do is to
>>>> encrypt /home which is under LVM. I use reiserfs.
>>>>
>>>> I would appreciate suggestion and pointers on what it is practical and
>>>> simple in order to accomplish this task with a minimum of downtime.
>>>>
>>>> Thanks,
>>>>
>>>> --
>>>> Valmor
>>>>
>>>
>>>
>>> Is it acceptable for you to have a commandline prompt for the password
>>> when booting? In that case you can use LUKS with the /etc/init.d/dmcrypt
>>
>> I think so.
>>
>>> init script. /etc/conf.d/dmcrypt should contain some examples. As you
>>> want to encrypt an LVM volume, the lvm init script needs to be started
>>> before this. As I see it, there is no strict dependency between those
>>> two scripts. You can add this by adding this line to /etc/rc.conf:
>>> rc_dmcrypt_after="lvm"
>>>
>>> For creating a LUKS-encrypted volume, look at
>>> http://en.gentoo-wiki.com/wiki/DM-Crypt
>>
>> Currently looking at this.
>>
>>>
>>> You won't need most of what is written there; just section 9,
>>> "Administering LUKS" and the kernel config in section 2, "Assumptions".
>>>
>>> Concerning downtime, I'm not aware of any solution that avoids copying
>>> the data over to the new volume. If downtime is absolutely critical, ask
>>> and we can work something out that minimizes the time.
>>>
>>> Regards,
>>> Florian Philipp
>>>
>>
>> Since I am planning to encrypt only home/ under LVM control, what kind
>> of overhead should I expect?
>>
>> Thanks,
>>
>
> What do you mean with overhead? CPU utilization? In that case the
> overhead is minimal, especially when you run a 64-bit kernel with the
> optimized AES kernel module.

Rough guess: Latency. With encryption, you can't DMA disk data
directly into a process's address space, because you need the decrypt
hop.

Try running bonnie++ on encrypted vs non-encrypted volumes. (Or not; I
doubt you have the time and materials to do a good, meaningful set of
time trials)

--
:wq

Am 13.03.2012 17:26, schrieb Michael Mol:
> On Tue, Mar 13, 2012 at 12:11 PM, Florian Philipp <lists@binarywings.net> wrote:
>> Am 13.03.2012 12:55, schrieb Valmor de Almeida:
>>> On 03/11/2012 02:29 PM, Florian Philipp wrote:
>>>> Am 11.03.2012 16:38, schrieb Valmor de Almeida:
>>>>>
>>>>> Hello,
>>>>>
>>>>> I have not looked at encryption before and find myself in a situation
>>>>> that I have to encrypt my hard drive. I keep /, /boot, and swap outside
>>>>> LVM, everything else is under LVM. I think all I need to do is to
>>>>> encrypt /home which is under LVM. I use reiserfs.
>>>>>
>>>>> I would appreciate suggestion and pointers on what it is practical and
>>>>> simple in order to accomplish this task with a minimum of downtime.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> --
>>>>> Valmor
>>>>>
>>>>
>>>>
>>>> Is it acceptable for you to have a commandline prompt for the password
>>>> when booting? In that case you can use LUKS with the /etc/init.d/dmcrypt
>>>
>>> I think so.
>>>
>>>> init script. /etc/conf.d/dmcrypt should contain some examples. As you
>>>> want to encrypt an LVM volume, the lvm init script needs to be started
>>>> before this. As I see it, there is no strict dependency between those
>>>> two scripts. You can add this by adding this line to /etc/rc.conf:
>>>> rc_dmcrypt_after="lvm"
>>>>
>>>> For creating a LUKS-encrypted volume, look at
>>>> http://en.gentoo-wiki.com/wiki/DM-Crypt
>>>
>>> Currently looking at this.
>>>
>>>>
>>>> You won't need most of what is written there; just section 9,
>>>> "Administering LUKS" and the kernel config in section 2, "Assumptions".
>>>>
>>>> Concerning downtime, I'm not aware of any solution that avoids copying
>>>> the data over to the new volume. If downtime is absolutely critical, ask
>>>> and we can work something out that minimizes the time.
>>>>
>>>> Regards,
>>>> Florian Philipp
>>>>
>>>
>>> Since I am planning to encrypt only home/ under LVM control, what kind
>>> of overhead should I expect?
>>>
>>> Thanks,
>>>
>>
>> What do you mean with overhead? CPU utilization? In that case the
>> overhead is minimal, especially when you run a 64-bit kernel with the
>> optimized AES kernel module.
>
> Rough guess: Latency. With encryption, you can't DMA disk data
> directly into a process's address space, because you need the decrypt
> hop.
>

Good call. Wouldn't have thought of that.

> Try running bonnie++ on encrypted vs non-encrypted volumes. (Or not; I
> doubt you have the time and materials to do a good, meaningful set of
> time trials)
>

Yeah, that sounds like something for which you need a very dull winter
day. Besides, I've already lost a poorly cooled HDD on a benchmark.

Regards,
Florian Philipp

On Tue, 13 Mar 2012 17:49:40 +0100, Florian Philipp wrote:

> Besides, I've already lost a poorly cooled HDD on a benchmark.

Better than losing it on real data.


--
Neil Bothwick

Why do they call it a TV set when you only get one?

On Tue, Mar 13, 2012 at 12:49 PM, Florian Philipp <lists@binarywings.net> wrote:
> Am 13.03.2012 17:26, schrieb Michael Mol:
>> On Tue, Mar 13, 2012 at 12:11 PM, Florian Philipp <lists@binarywings.net> wrote:
>>> Am 13.03.2012 12:55, schrieb Valmor de Almeida:
>>>> On 03/11/2012 02:29 PM, Florian Philipp wrote:
>>>>> Am 11.03.2012 16:38, schrieb Valmor de Almeida:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I have not looked at encryption before and find myself in a situation
>>>>>> that I have to encrypt my hard drive. I keep /, /boot, and swap outside
>>>>>> LVM, everything else is under LVM. I think all I need to do is to
>>>>>> encrypt /home which is under LVM. I use reiserfs.
>>>>>>
>>>>>> I would appreciate suggestion and pointers on what it is practical and
>>>>>> simple in order to accomplish this task with a minimum of downtime.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> --
>>>>>> Valmor
>>>>>>
>>>>>
>>>>>
>>>>> Is it acceptable for you to have a commandline prompt for the password
>>>>> when booting? In that case you can use LUKS with the /etc/init.d/dmcrypt
>>>>
>>>> I think so.
>>>>
>>>>> init script. /etc/conf.d/dmcrypt should contain some examples. As you
>>>>> want to encrypt an LVM volume, the lvm init script needs to be started
>>>>> before this. As I see it, there is no strict dependency between those
>>>>> two scripts. You can add this by adding this line to /etc/rc.conf:
>>>>> rc_dmcrypt_after="lvm"
>>>>>
>>>>> For creating a LUKS-encrypted volume, look at
>>>>> http://en.gentoo-wiki.com/wiki/DM-Crypt
>>>>
>>>> Currently looking at this.
>>>>
>>>>>
>>>>> You won't need most of what is written there; just section 9,
>>>>> "Administering LUKS" and the kernel config in section 2, "Assumptions".
>>>>>
>>>>> Concerning downtime, I'm not aware of any solution that avoids copying
>>>>> the data over to the new volume. If downtime is absolutely critical, ask
>>>>> and we can work something out that minimizes the time.
>>>>>
>>>>> Regards,
>>>>> Florian Philipp
>>>>>
>>>>
>>>> Since I am planning to encrypt only home/ under LVM control, what kind
>>>> of overhead should I expect?
>>>>
>>>> Thanks,
>>>>
>>>
>>> What do you mean with overhead? CPU utilization? In that case the
>>> overhead is minimal, especially when you run a 64-bit kernel with the
>>> optimized AES kernel module.
>>
>> Rough guess: Latency. With encryption, you can't DMA disk data
>> directly into a process's address space, because you need the decrypt
>> hop.
>>
>
> Good call. Wouldn't have thought of that.
>
>> Try running bonnie++ on encrypted vs non-encrypted volumes. (Or not; I
>> doubt you have the time and materials to do a good, meaningful set of
>> time trials)
>>
>
> Yeah, that sounds like something for which you need a very dull winter
> day. Besides, I've already lost a poorly cooled HDD on a benchmark.

Sounds like something we can do at my LUG at one of our weekly
socials. The part I don't know is how to set this kind of thing up and
how to tune it; I don't want it to be like Microsoft's comparison of
SQL Server against MySQL from a decade or so ago, where they didn't
tune MySQL for their bench workload.

--
:wq

On Tue, Mar 13, 2012 at 05:11:47PM +0100, Florian Philipp wrote:

> > Since I am planning to encrypt only home/ under LVM control, what kind
> > of overhead should I expect?
>
> What do you mean with overhead? CPU utilization? In that case the
> overhead is minimal, especially when you run a 64-bit kernel with the
> optimized AES kernel module.

Speaking of that...
I always wondered what the exact difference was between AES and AES i586. I
can gather myself that it's about optimisation for a specific architecture.
But which one would be best for my i686 Core 2 Duo?
--
Gruß | Greetings | Qapla'
I forbid any use of my email addresses with Facebook services.

A pessimist is an optimist who's given it some thought.

Am 13.03.2012 18:45, schrieb Frank Steinmetzger:
> On Tue, Mar 13, 2012 at 05:11:47PM +0100, Florian Philipp wrote:
>
>>> Since I am planning to encrypt only home/ under LVM control, what kind
>>> of overhead should I expect?
>>
>> What do you mean with overhead? CPU utilization? In that case the
>> overhead is minimal, especially when you run a 64-bit kernel with the
>> optimized AES kernel module.
>
> Speaking of that...
> I always wondered what the exact difference was between AES and AES i586. I
> can gather myself that it's about optimisation for a specific architecture.
> But which one would be best for my i686 Core 2 Duo?

From what I can see in the kernel sources, there is a generic AES
implementation using nothing but portable C code and then there is
"aes-i586" assembler code with "aes_glue" C code. So I assume the i586
version is better for you --- unless GCC suddenly got a lot better at
optimizing code.