[gPXE] Fwd: interrupt and serial

[Luca]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://etherboot.org/pipermail/gpxe/attachments/20100209/7dfd2eaa/attachment.html