Re: no deprecation of /usr as a standalone filesystem
Pierre Habouzit <madcoder@madism.org> writes:
> 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.
Because / on LVM requires an initramfs to start lvm.
>> >> 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.
Nodev prevents the device node from working. Doesn't phase mknod at all.
That means while you can still create device nodes and give them any
permissions you like nobody can use them.
>> 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.
Have you looked at the size of kde or gnome in the last, oh say, 5
years?
And you are wrong even for small files, or should I say esspecially?
On small files you seek, you read a chunk of encrypted data, you
decrypt it, you process it and only then the next chunk is
requested. With random access things like the disks read-ahead won't
decrypt the next block already while you process the current one.
> Raw performance is actually very far from what actually happens in real
> life.
Sure, real life is usualy an order slower.
> 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
And let anyone stealing my laptop steal my data too?
MfG
Goswin
Reply to: