davmor2 | cyphermox: I don't see the press enter to continue on amd64 vivid on a secureboot and uefi install, (full disk wipe and install) after the cd has been ejected | 12:19 |
---|---|---|
cyphermox | davmor2: yeah, that's bug 966480, I don't think it's just uefi installs | 13:33 |
davmor2 | cyphermox: nice | 13:38 |
robert_ancell | I'm trying to add support for using a TPM to store the LUKS key for full disk encryption. The good news is I can now convert a stock LUKS trusty install into a TPM LUKS system with a few commands. The challenge now is to make all this easy to setup from ubiquity. | 22:56 |
cyphermox | robert_ancell: I suspect you don't have a way to virtualize the TPM bits? ie. vTPM on Xen? | 22:57 |
cyphermox | note that I know next to nothing about TPM ;) | 22:57 |
robert_ancell | cyphermox, There is a QEMU project to virtualize/passthrough TPM but it seems that there's no progress there (and it looked like too much work for me to help get done in time) | 22:58 |
robert_ancell | I bought a PC with TPM for testing | 22:58 |
cyphermox | yeah, I saw it too but passthrough... | 22:58 |
robert_ancell | Yeah, it's pretty hard to work on without such a PC | 22:58 |
cyphermox | kind of means you'll break your tpm if things don't work as you expect | 22:58 |
robert_ancell | yep :) | 22:58 |
cyphermox | ;) | 22:58 |
robert_ancell | I've reinstalled this box many times due to breaking things like that :) | 22:59 |
robert_ancell | So the problems I'm trying to work on now are a) Adding UI to ubiquity to take ownership of the TPM during install (i.e. set the passwords for it) and b) Set up the LUKS partition with TPM on install | 22:59 |
robert_ancell | So I think a) is not *too* hard once I work out the right places to update in Ubiquity | 22:59 |
robert_ancell | b) is a bit harder - I think the code that actually does this is in debian-installer / partman-crypto but that doesn't seem to support anything other than vanilla LUKS installs | 23:00 |
cyphermox | my suggestion would be to leave breadcrumbs, log all you can, start by doing a noop but logging what it should have been doing | 23:00 |
cyphermox | so yeah, a) would be all in ubiquity | 23:00 |
cyphermox | b) would be partman-crypto, I think, as you mentioned | 23:01 |
robert_ancell | cyphermox, and is it OK for ubiq to take new dependencies on libtss to do this functionality? | 23:01 |
robert_ancell | libtspi I mean | 23:01 |
cyphermox | robert_ancell: would it need libtspi or would that be in partman-crypto instead? | 23:02 |
robert_ancell | cyphermox, for the setting up of the TPM I don't think it makes sense to put that in partman-crypto, since it's not specifically related to the partitioning | 23:02 |
robert_ancell | i.e. it's "hey, you have this TPM that's not been set up - would you like to do that?" | 23:02 |
cyphermox | sure | 23:02 |
robert_ancell | cyphermox, so if the work is in partman-crypto, I should be able to test that with a text based install before working on the ubiq frontend right? | 23:04 |
cyphermox | yes | 23:04 |
robert_ancell | What's the easiest way to do that? | 23:04 |
cyphermox | maybe use a preseed that goes to add a PPA (or some archive somewhere) to update any packages you need to the right versions you want to test; from a d-i preseed/early_command | 23:07 |
robert_ancell | cyphermox, if I modify partman-crypto, that would ideally go upstream to Debian. Do you know how receptive they are to changes? | 23:09 |
cyphermox | robert_ancell: I don't see why it would be a major issue, TPM is useful. | 23:10 |
robert_ancell | cyphermox, ok, thanks. I'll try and make partman-crypto smart enough to set up a TPM enabled LUKS partition and see if I can get that change to my test PC via a PPA. I'm sure I'll be back with more questions tomorrow :) | 23:11 |
cyphermox | means you'll need to fix things up in d-i itself too to originally setup the TPM, what will go in ubiquity | 23:11 |
robert_ancell | yeah | 23:11 |
cyphermox | robert_ancell: feel free, I'll help however I can | 23:12 |
cyphermox | robert_ancell: do you already have the commands/steps you need to do this listed somewhere? | 23:12 |
robert_ancell | cyphermox, actually the debian-installer source package seems very light on content - is that where a "setup TPM" module would go or is there some other subpackage? | 23:12 |
robert_ancell | cyphermox, I have my whiteboard at https://docs.google.com/a/canonical.com/document/d/1AOWYAHGbwzxHCknNPWwqMke0Fpnxqwad8fcT-IudluY/edit . That will only be visible to people from Canonical. | 23:13 |
robert_ancell | (but it doesn't contain anything secret) | 23:13 |
cyphermox | robert_ancell: you got me there, I'm not sure. cjwatson: where do you suggest initial TPM bringup could go for d-i ^ ? | 23:15 |
infinity | robert_ancell: We have a pretty strict policy about not asking unnecessary questions in the installer. If every machine with a TPM is going to suddenly get a new (and confusing to 99% of people) question, that's not ideal. | 23:16 |
cyphermox | ah, maybe hw-detect? | 23:16 |
robert_ancell | infinity, from the UI (ubiquity) I was thinking there'd be a checkbox / button for when you do the LUKS setup and you have a TPM to use that. | 23:17 |
robert_ancell | I'll ask design too but I suspect they'll be too busy to choose | 23:17 |
robert_ancell | cyphermox, hw-detect looks promising | 23:18 |
infinity | robert_ancell: Sure, for LUKS, that makes sense, but you were talking about "general TPM setup", which implies that somewhere outside encrypted filesystem setup, you're going to say "it looks like you have a TPM module, let's make it go!" | 23:19 |
infinity | robert_ancell: Which would be pretty much a non-starter, I think. | 23:19 |
cyphermox | robert_ancell: if setting up the TPM for use doesn't require any prompt and isn't going to break anything already installed and using the TPM (ie, other OS) | 23:20 |
robert_ancell | infinity, right - that's where I'm not sure how the interface between d-i and ubiquity works. If we add general TPM support to d-i can we make ubiquity skip that step if it knows you're not doing LUKS with TPM? | 23:20 |
infinity | robert_ancell: The "no superfluous questions" thing applies to d-i too. | 23:20 |
robert_ancell | infinity, ah, ok | 23:21 |
cyphermox | robert_ancell: for ubiquity, I don't think we currently have any hidden-by-default-unless-you-have-the-hardware checkboxes, but that could probably go under the use crypto one. | 23:21 |
infinity | robert_ancell: Though, we manage it in d-i by making hard/useless questions be low priority, so you only see them in 'expert' mode. | 23:21 |
robert_ancell | infinity, I would think TPM would count as expert | 23:21 |
robert_ancell | i.e. most people aren't going to care | 23:21 |
infinity | Well, and if done right, you should be able to trip the template from partman-crypto. | 23:22 |
robert_ancell | infinity, you can have questions with dependencies? | 23:22 |
infinity | So, hw-detect should see if the part is installed, store that little nugget of info away, and then when partman-crypto comes along,, it can check the state of "does it exist" and "was it already set up", and do the right thing according to the answer to each. | 23:23 |
robert_ancell | awesome | 23:23 |
infinity | robert_ancell: templates don't have deps, but they're called manually via shell scripting, at least in some cases. | 23:23 |
infinity | So, more like a state machine. You ask debconf questions, and based on results you get back, you trigger new behaviour in other bits, which can include asking more questions. | 23:24 |
infinity | robert_ancell: If you're familiar with using debconf from a normal dpkg standpoint, it's that, minus apt-utils. Meaning, no early template extraction (though, I guess preseeding is the logical equivalent), just lots of postinsts running, querying debconf, triggering more templates, lather, rinse, repeat. | 23:26 |
robert_ancell | I'm already past the boundaries on my debconf knowledge :) | 23:27 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!