[gPXE] Fwd: interrupt and serial
Peter Scheie
peter at scheie.homedns.org
Sat Feb 13 11:40:53 EST 2010
I am interested in your code for comparing the https server's cert. Your
situation sounds similar to mine: I can provide the server's cert to gpxe during
the initial setup (we'll be installing gpxe on the local disk and booting that
and then chaining another script over https) so I just need to be able to
compare the cert that the server provides to the one on the local disk.
Peter
Luca wrote:
> On Tue, Feb 9, 2010 at 6:48 AM, Stefan Hajnoczi <stefanha at gmail.com> wrote:
>
>> On Tue, Feb 9, 2010 at 2:22 PM, Luca <lucarx76 at gmail.com> wrote:
>>>> Let's discuss your setup and use case more. Perhaps there is an
>>>> existing solution or we can come up with a generic solution that can
>>>> be merged into mainline gPXE.
>>>>
>>> I have an environment with several workstations, which I want to gPXE
>> boot.
>>> I have an environment with one DHCP server.
>>> When gPXE starts, it gets from the DHCP server the path of the image it
>>> should download.
>>>
>>> I want gPXE to be sure it's talking to the right server. So I modified a
>>> little bit the gPXE TLS code. I assume gPXE has the certificate of the
>> HTTPS
>>> server it's going to talk to. During the TLS handshake, when the server
>>> sends its certificate, I have gPXE validating it. If the certificate sent
>> by
>>> the server is the one gPXE has then gPXE knows it is talking to right
>>> server.
>>>
>>> I have different HTTPS servers, and I want to be free to add a new one
>>> whenever I need. So I do not want to have this certificate compiled into
>>> gPXE. That's why when gPXE starts I want gPXE to talk to a serial server
>>> and get the certificate of the HTTPS is going to talk to.
>> Other users have expressed interest in certificate validation and I
>> think this is a general problem.
>>
>> I know little about how TLS works, but would it be possible to solve
>> this by using a certificate authority instead of comparing against
>> specific certificates? When a client connects to a server, it will
>> check that the server's certificate has been signed by the certificate
>> authority? That way you can support as many servers as you like, but
>> they must be signed by the certificate authority (you).
>>
>
> This is definitely an option. Option that I did consider.
> It requires more changes in gPXE's code though that's why I was looking for
> something else. But if there is no other way, using a CA authority is a
> solution.
>
> Essentially if I have the server certificate in gPXE, during the tls
> handshake it's just a matter of comparing the certificate the server sends
> to gPXE with the one gPXE has.
> If they match, encrypt everything with the public key contained in the
> server certificate so that only the real server can decrypt the content.
>
>
>>>> What are the constraints of your setup? Do you have a DHCP server?
>>>> Can you set the boot filename handed out by the DHCP server?
>>>>
>>> The communication between the serial server and gPXE is secure, while the
>>> communication between gPXE and the DHCP is over an open channel. That's
>> why
>>> I do not want to pass this information to gPXE as a DHCP option.
>> This is an interesting scenario: you do not trust the LAN. What if
>> the DHCP server hands out a http, tftp, etc URL instead of a HTTPS URL
>> with your code in place? I guess you have explicitly disabled all
>> other protocols, including plain HTTP.
>>
>>
> Yes I disabled all other protocols but HTTPS. gPXE won't boot anything
> unless it comes from an HTTPS server gPXE trusts (i.e. gPXE has a copy of
> server certificate or, if I add CA, CA confirms the certificate is ok).
>
>
>> I am interested in your thoughts about secure network booting. At the
>> moment there are no "best practices" on the wiki.
>>
>>
> Happy tho share with the gPXE community.
>
>
>>>> When gPXE starts it could send a 'hello' message over the serial port
>>>> and wait for a response. The server would respond with the
>>>> configuration. I don't think there is a technical limitation
>>>> preventing one from implementing this config-over-serial approach.
>>>>
>>> That's what I'm doing right now. The problem I have is that as I use
>>> polling, sometimes I looses characters sent by the server (I do very few
>>> operations when I get a character, but still sometimes I miss some
>>> characters). This would not happen if I used interrupts.
>> Without seeing the code I can't be sure what is going on. However,
>> adding interrupt handlers to the mix is not going to make the code go
>> any faster. If you currently have a tight receive loop and it is
>> missing characters, then something is wrong. Is the baud rate set
>> correctly on the serial port?
>>
>>
> If I had interrupts, I could stop anything I'm doing every time I get a new
> character and put it into a buffer and then go back to what I'm doing. So I
> shouldn't miss any character.
> If I use polling, even if the loop is tight, if I get more characters while
> I'm in the loop, I might miss something (when I poll the serial might be too
> late).
> But I might be wrong so having the interrupts would not change the
> situation.
>
> Yes the baud rate is set correctly. Most of the time (I would say 90% of the
> time) it works. But sometimes I miss characters.
>
>
>> Stefan
>>
>
> Luca
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> gPXE mailing list
> gPXE at etherboot.org
> http://etherboot.org/mailman/listinfo/gpxe
More information about the gPXE
mailing list