#7361 Signing infrastructure for aarch64
Opened 3 years ago by pbrobinson. Modified 3 months ago

  • Describe what you need us to do:

There are now aarch64 systems that are shipping with secure boot enabled so we need to be able to sign all the parts of the boot path (shim/grub2/kernel) like we do on x86_64 now. To do this we need the infrastructure (HSM, smart cards etc) to be able to do this.

I'm not sure how the signing keys etc are setup, whether we already have enough smart cards etc so this is a ticket to cover all of the various HW/infrastructure components.

  • When do you need this? (YYYY/MM/DD)

Sooner the better but some what flexible.

  • When is this no longer needed or useful? (YYYY/MM/DD)

  • If we cannot complete your request, what is the impact?

There's the possibility of being unable to run on some HW due to secure boot requirements.

Metadata Update from @bowlofeggs:
- Issue priority set to: Waiting on Assignee (was: Needs Review)
- Issue tagged with: request-for-resources

3 years ago

So, the bkernel x86_64 boxes are using smart card readers that attach via USB.

I do not know, but I suspect the moonshot chassis has no USB to connect to, so we would need to move to mustangs for building. Do they have USB?

@smooge do you know the hardware you got for this? we should be able to check the bkernel boxes.

We will then need @pjones to prep a smart card with the needed info on it and get it to us?

Yes, the mustang HW has USB onboard, we'd probably want to get SSDs for the ones we use thought.

The signing smart card fits into a USB connector like this

I think the SSD item you are mentioning is for a different reason? As in "We can possibly take the SSD's out of the ARM calxeda's to put in Mustangs at the next visit?" versus an SSD being used inside a mustang for signing.

@smooge I understand the USB smart card. I meant SSD in the context of storage to replace the slow single HDDs currently in the mustangs to speed up builds. We could possibly use the ones in the calxeda, but I suspect they're already quite old.

Metadata Update from @smooge:
- Issue assigned to smooge

3 years ago

So, we can't really get more of the smart cards in question, but I've been investigating alternatives, and I think we can do this with yubikeys. Is there a strong preference in terms of form factor between yubikey and yubikey nano?

My first through is to go with the nano just because they're harder to casually remove from machines, but obviously those of yall who actually have to touch the hardware might have your own concerns either way that I'm not aware of.

Just another note here - I also have a preference for the nano because they don't have NFC.

Metadata Update from @smooge:
- Issue tagged with: security

3 years ago

I tagged this security so it gets on @puiterwijk queue

Sorry, I replied to @pjones on IRC, and nano's would be perfect.

Metadata Update from @kevin:
- Issue tagged with: backlog

3 years ago

So I think the latest update for this is that @pjones has provided the new signing HW to @kevin and it's awaiting a DC visit. I believe that HW should work with the new Lenovo aarch64 HW?

Next physical visit looks to be in June 2020 after we move the hardware to a new location.

Metadata Update from @smooge:
- Assignee reset

2 years ago

@kevin @smooge can we please make sure this is on the list for the DC visit please.

I can do so, but I will need a non NFC yubikey or whatever hardware is expected. [The newer yubikeys seem to come with NFC and other wireless doogads]

A few things:

  • We are not sure when/if the next DC visit will be. Due to COVID19, we are attempting to do as much as we possibly can remotely. There may not be a DC visit for a long time.

  • I talked with @pjones the other day and he indicated there might be some new setup for this and asked me to not deploy the yubikeys that I have yet (or possibly at all).

So, lets actually come up with a plan here. First, I guess we will to ask @pjones (here or, if you prefer email ?) what the signing setup will be like, and then we need to figure out how we can implement that without actually having a site visit (or at least in case we don't have any anytime soon).

So some details from pjones just for reference.

<pjones> might need more than one signing key on there, and I haven't gotten far enough yet to know if I can do that with the devices I gave nirik
<pjones> probably if that happens I'll move the signing keys to softhsm with its db living on a luks device and use the hardware key to unlock the luks device.
<pjones> I'm assuming those machines don't have tpms, but also using them may be more trouble than it's worth

The x86 builders do have tpm I think: [Mon Mar 23 14:20:13 2020] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2)

No idea on the aarch64 ones.

Metadata Update from @smooge:
- Issue tagged with: high-gain, high-trouble, ops

2 years ago

The x86 builders do have tpm I think: [Mon Mar 23 14:20:13 2020] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2)

No idea on the aarch64 ones.

"ls /dev/tpm*" would tell.

Can we have a status update on this in general. We now have aarch64 HW which supports secure boot, and the DC move is long over. It would be really useful to get this issue fixed.

From the infra side we are ready to move this forward again anytime.

We need to know from @pjones what the plan is for what hardware we need/how to get it to the DC, etc.

Mailed pjones about this to come up with a plan.

No answer, will try and catch him on irc.

Metadata Update from @zlopez:
- Issue priority set to: Waiting on External (was: Waiting on Assignee)

8 months ago

PM'ed @pjones about this. Perhaps this is the year we will get this done. ;)

Metadata Update from @kevin:
- Issue priority set to: Waiting on Assignee (was: Waiting on External)

8 months ago

I was actually speaking with him about this earlier in the week and asked him to update details here.

ok. Pinging again here. ;)

Perhaps @rharwood or @javierm might have some news?

Trivia: The email of @pbrobinson asking for this is the very oldeest email in my work inbox. :)

I can't speak to this issue specifically, but: we'll be swamped probably until at least May, so unfortunately probably no movement before then.

Metadata Update from @kevin:
- Issue tagged with: blocked

3 months ago

Login to comment on this ticket.

Boards 1
ops Status: Backlog