Re: no deprecation of /usr as a standalone filesystem
On Mon, Jun 01, 2009 at 05:13:16PM +0200, Goswin von Brederlow wrote:
> Pierre Habouzit <madcoder@madism.org> writes:
>
> > On Mon, Jun 01, 2009 at 01:11:20PM +0200, Goswin von Brederlow wrote:
> >> Josselin Mouette <joss@debian.org> writes:
> >> > > - LVM and/or RAID: no real reason nowadays to not use these for the root
> >>
> >> As long as debian does not provide support for kernel independent non
> >> breaking initramfs support (i.e. not regenerated on every whim and
> >> break) having / outside lvm and no initramfs is a real plus.
> >
> > You meant /boot right ?
>
> No, /. Where /boot is has no effect on wether you need an initrd or
> not. That only interests the bootloader.
Huh, I completely fail to see why not having / on LVM is a matter of
importance.
> >> You can not mount / nodev if you don't use udev. But you /usr you can.
> >> What I'm trying to say is that read-only is not the only option that
> >> can differ between / and /usr.
> >
> > What's the purposes of mounting /usr nodev as all directories there are
> > owned by root (or at least should be) ?
>
> Only allow what is neccessary. That way when accidentally some device
> node lands in /usr it still can't be abused. For example someone could
> sneak in a package into Debian that contains
>
> crw-rw-rw- 1 root kmem 1, 1 May 30 15:55 /usr/lib/rootkit/mem
> crw-rw-rw- 1 root kmem 1, 2 May 30 15:55 /usr/lib/rootkit/kmem
Think again, if I do such a package, I would obviously check with some
kind of trivial perl programm if the device containing /usr/lib/rootkit
is mounted with nodev, would use mount -o remount,dev on the problematic
mount point in the preinst, let the unpacking happen, and remount
properly in the postinst.
If you're root, nodev is useless. That's exactly why I mentioned the
fact that every single path in /usr is supposed to be root:root, IOW to
create a device there you *have* to be root, and nodev won't stop you.
> Cpu frequency scalled up all the way in both cases for the test:
>
> root@frosties:~# time dd if=/dev/sdc of=/dev/null bs=1M count=4096
> 4096+0 records in
> 4096+0 records out
> 4294967296 bytes (4.3 GB) copied, 46.6188 s, 92.1 MB/s
> dd if=/dev/sdc of=/dev/null bs=1M count=4096 0.01s user 8.35s system 17% cpu 46.737 total
>
> root@frosties:~# time dd if=/dev/mapper/sdc-crypt of=/dev/null bs=1M count=4096
> 4096+0 records in
> 4096+0 records out
> 4294967296 bytes (4.3 GB) copied, 56.5635 s, 75.9 MB/s
> dd if=/dev/mapper/sdc-crypt of=/dev/null bs=1M count=4096 0.02s user 8.66s system 15% cpu 56.806 total
>
> Despite that it says only 15% system is used in the case of sdc-crypt
> all the remaining cpu power is used up by:
>
> 2651 root -5 0 0 R 78.7 0.0 1:00.28 kcryptd
>
> Those 78% means that the cpu goes into full speed. The voltage and
> frequency is increased. The cpu fan spins up to a higher setting. The
> time spend in kcryptd is also stolen from e.g. gcc or ld. Compiling takes
> longer, esspecially the first time. The CPU stays in full speed for
> longer eating more power.
> For me the "takes longer" part is actually more important. That even
> holds when you are not running on battery. I don't have numbers on the
> battery life as I never compared the time with and without
> dm-crypt. Feel free to time it yourself.
The point is, unless you're loading pretty large stuff (IOW larger than
a few hundreds of kilobytes, say files of size > 512k) your figures are
wrong, because for small stuff (and it's most of what people are reading
from /usr) spining the hard disk is way slower than decrypting the data.
Raw performance is actually very far from what actually happens in real
life.
And if you really care about those extra bits of performance, then what
I'd do is _not_ to not encrypt /usr but rather to let / be unencrypted,
and to encrypt /var, /srv and /home, with the option to let /home be a
bind mount of /srv/home or similar if you don't want 3 partitions.
IOW even for this kind of optimization, you have a trivial workaround
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Reply to: