Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
soc:2009:oremanj:journal:week5 [2009/06/24 18:56] rwcr |
soc:2009:oremanj:journal:week5 [2009/06/26 22:26] (current) rwcr |
||
|---|---|---|---|
| Line 91: | Line 91: | ||
| I've got a busy week and a half ahead of me! | I've got a busy week and a half ahead of me! | ||
| + | Earlier today Michael finished reviewing all the commits on my mainline-review branch except the three 802.11-specific ones; I've updated yesterday's commit list with the current state of things. | ||
| + | |||
| + | ==== Thursday, 25 June ==== | ||
| + | WPA is truly a horribly complicated beast. The more I learn about it, the more I realize I need to implement... ah well. I do feel as though I'm getting a handle on things, at least, and spent today working on ancillary code: | ||
| + | * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=f16216a4e4382d1e0b680ac917f4e290eaa1b602| | ||
| + | [802.11] Detect secured networks properly, and find errors better]] | ||
| + | * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=8c249f0dc339bc416f5acf1b73a546dcb8591275| | ||
| + | [digest] Add HMAC-SHA1 based pseudorandom function and PBKDF2]] | ||
| + | * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=f358af4c5266b654b4572ffcd9306eb24593a7f2| | ||
| + | [eap] Add handlers for EAPOL decapsulation and EAP demultiplexing]] | ||
| + | |||
| + | Things I still need to do include implementing the 4-Way Handshake, generating the PTK, checking the Michael MIC, and the nuts-and-bolts methods of TKIP key mixing and CCMP encryption. | ||
| + | |||
| + | One thing I discovered today while browsing the Linux ''wpa_supplicant'' source code is that the RSN information element and 4-Way Handshake documented in the IEEE standard are not supported by many "WPA" devices that were shipped prior to the time IEEE 802.11i (the WPA amendment) was finalized. Instead, they use an information element under the "vendor-specific" heading with a different format, and a slightly different handshake as well. Judging by ''wpa_supplicant'' the old way seems to be simpler, but I haven't been able to find any documentation on it other than the source code. When I run hostapd in WPA1 mode, gPXE thinks it's WEP, so that's another thing I'll need to figure out and fix. | ||
| + | |||
| + | ==== Friday, 26 June ==== | ||
| + | Most of the major bits of WPA have yet to be completed, but I've got enough ancillary stuff written that I think I should be able to dive in and have at least one WPA encryption scheme implemented by mid-next week. Commits: | ||
| + | * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=7fe87e2161ebd947a39ff8015fb45486a7140f0b|[802.11] Revamp RSN IE processing]] | ||
| + | * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=b17f562c91ff1745f50d0ba58eea385fcd7cf732|[802.11] Miscellaneous structural and API changes for encryption code]] | ||
| + | * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=ec70a5225b8062d11b4b2161af91f0ec21527161|[802.11] Start hashing out how WPA is going to work]] | ||
| + | |||
| + | The issue I noted in the last paragraph of yesterday's entry was not quite so bad as it seemed; after accounting for different header bytes and different version numbers, for gPXE's purposes the bulk of the WPA and RSN information elements can be parsed identically. Huzzah. The two versions still have some respective idiosyncracies in the handling of the 4-Way Handshake (which is next up on the list of things to write), but the ''wpa_supplicant'' code is a good reference for that. | ||
| + | |||
| + | I now offer an interlude of Cool Linker Tricks. | ||
| + | |||
| + | One of the things I did today was move all the helper functions that will only be needed when some encryption method is supported into a separate file, ''sec80211.c'', so they don't bloat the code size in wireless builds that don't use encryption. There's one chink in that: the main wireless probe code needs to be able to differentiate fully between the various types of secured network even if they're not all supported, as WPA looks like WEP to a client that knows nothing about WPA. So ''net80211_probe_step()'' has to call ''sec80211_detect()'', but we don't want that call to pull in ''sec80211.c'' if nothing else needs it. | ||
| + | |||
| + | Enter a very handy and underused linker feature: weak symbols! | ||
| + | |||
| + | Suppose you have a function, ''check_snazzy()'', that needs to be called from the ''base.o'' module only if the module containing it, ''snazzy.o'', is compiled in for another reason. It's a one-off, so using a linker table would be overkill; instead, you can do in ''snazzy.h'' | ||
| + | int check_snazzy() __attribute__ (( weak )); | ||
| + | In ''snazzy.c'' the function is defined as normal, without the weak attribute; it's only the external declaration that's weak, not the definition. But in ''base.c'' you can do | ||
| + | void check_things() { | ||
| + | /* ... */ | ||
| + | if ( check_snazzy ) { | ||
| + | int snazziness = check_snazzy(); | ||
| + | /* ... */ | ||
| + | } else { | ||
| + | DBG ( "snazziness not enabled" ); | ||
| + | } | ||
| + | /* ... */ | ||
| + | } | ||
| + | If ''snazzy.o'' would not be pulled into the link by an ordinary ("strong") symbol reference, a weak reference alone isn't going to be enough to pull it in. Instead, the linker defines ''snazzy.o'''s referenced weak symbols to be ''NULL'' pointers, and code that wants to conditionally use ''check_snazzy()'' just needs to test it against ''NULL'' before using it. While this example is obviously contrived, the technique can be very useful. | ||
| + | |||
| + | This is rather messy, of course; the fewer symbols with an implicit "might-be-NULL" attached the better. But for fairly tightly-coupled source files that need to be separated for size reasons, one or two weak functions can provide an excellent interface between the two. | ||
| + | |||
| + | While we're in the Cool Linker Tricks department, there's also something called a "weak alias", which serves a completely different purpose: providing one implementation of an API function while allowing it to be superseded without complaint by another object file. I haven't seen anything in gPXE that really needs this, but to give an example of how it //could// be used, gPXE core defines a simple ''memcpy()'' function that doesn't know about any architecture-specific optimizations, but only declares its prototype if the preprocessor macro ''%%__HAVE_ARCH_MEMCPY%%'' hasn't been defined by architecture-specific includes; that allows architecture-specific string functions to be used instead, using either ''#define'' or an inline implementation, but no symbol can be named ''memcpy'' because the linker would complain. A way around that would be: | ||
| + | /* in core string code */ | ||
| + | void * core_memcpy ( void *dest, const void *src, int len ) { | ||
| + | /* ... */ | ||
| + | } | ||
| + | | ||
| + | void * memcpy ( void *dest, const void *src, int len ) | ||
| + | __attribute__ (( weak, alias ( "core_memcpy" ) )); | ||
| + | Then architecture-specific code could just define ''memcpy'' directly, no preprocessor tricks needed, and it would supersede the core version. Again, I don't think anything needs this at this point, but it's cool to know - maybe it'll even come in handy someday! :-) | ||
