1 |
On Sun, 2007-04-08 at 14:28 +0000, Nelson Batalha wrote: |
2 |
> I chose Luks, since seems genkernel is supporting it (no docs though), |
3 |
> however this will force us to use two loops, (performance issues?). An |
4 |
> alternative is loop-aes -> one loop only. |
5 |
|
6 |
Why do you need two loops? I'm just asking, since I don't know the |
7 |
details of the differing methods and have only looked over the patches |
8 |
as I've applied them for correctness, not for functionality. Also, make |
9 |
sure there aren't any patches assigned to genkernel that won't help with |
10 |
this. There's at least one or two more LUKS-related patches/bugs in |
11 |
bugzilla. |
12 |
|
13 |
> On gk arguments we would add initramfs a cryptsetup binary with |
14 |
> --initramfs-overlay; we would also add a custom initrc that would put our |
15 |
> encrypted squashfs file in a loop, and cryptsetup would unencrypt it in a |
16 |
> different loop - and call it our root. |
17 |
|
18 |
OK. You're already steering off course. If you add cryptsetup to |
19 |
boot/kernel/$kname/packages, genkernel will include it with --luks, so |
20 |
you don't need to do anything in an initramfs overlay. We also do |
21 |
decryption in genkernel already. |
22 |
|
23 |
> The patch to catalyst would allow us to write a script to convert the |
24 |
> squashfs in a encrypted one. First we knew the final squashfs size, so it |
25 |
> would just create a file with dd with that size from /dev/zero. Then it |
26 |
> would mount this file in a loop, cryptsetup would use it and open it in a |
27 |
> different loop, and then we would mksquashfs the contents in it. |
28 |
|
29 |
I'm not sure I'm following, but everything that goes into the squashfs |
30 |
is already available to catalyst. We don't need to copy it all *again* |
31 |
since it is at (by |
32 |
default) /var/tmp/catalyst/tmp/default/livecd-stage2-whatever already. |
33 |
|
34 |
> Any problems, comments or alternatives? Would you accept this patch? My bash |
35 |
> is ok now, gonna take some time to write the python stuff. |
36 |
|
37 |
I would accept it if it were done right. You'll want to look more into |
38 |
both what catalyst and what genkernel are already capable of doing. I |
39 |
would much rather incorporate the support in catalyst directly, rather |
40 |
than adding yet another spec file key that isn't necessarily a |
41 |
single-purpose key. |
42 |
|
43 |
-- |
44 |
Chris Gianelloni |
45 |
Release Engineering Strategic Lead |
46 |
Alpha/AMD64/x86 Architecture Teams |
47 |
Games Developer/Council Member/Foundation Trustee |
48 |
Gentoo Foundation |