On April 8, 2014 at 3:57:57 AM, Michel Stempin ([email protected]) wrote: > Le 08/04/2014 08:37, Steven Barth a écrit : > > Applied, thanks. Will probably take care of AA later today. > > Does it mean that ther ewill be a new AA binary release, or just the sources > will be updated?
And will it have to be a new whole-image release or is there any way of shipping upgraded packages? Right at the current moment, OpenWrt AA has a version-numbering problem. A natural name for a hot-fix release for openssl would be 12.09.1, but there is already something else planned to be called "12.09.1" and I believe some users flashing AA-head over 12.09 would require network reconfiguration. It would be *really* *nice* if there was a "no reconfiguration required" hotfix for openssl. We could build an official patch package. For most router users, libssl.so is in squashfs, though. An upgraded libssl will eat a second 300k on ar71xx, and the 300k is from the uncompressed user storage area. How close to the edge of running out of space are people running AA? I started looked at using ELF hackery to get around creating a full copy. *If* you think patching tls1_process_heartbeat and dtls1_process_heartbeat is sufficient--and that is a significant "if"--it's possible to place a stub libssl.so on the /overlay filesystem which satisfies most of its symbol dependencies by DT_NEEDing /rom/usr/lib/libssl.so. For better or worse, /rom/usr/lib/libssl.so is linked -Bsymbolic. This means that users of tls1_process_heartbeat internal to the library do not go through the symbol table; they branch directly to the function. So it is not enough to just fix the symbol resolution. We need to include patched versions of all the internal callers...and then all *their* internal callers. It looks like we'd have to include a copy of at least ssl3_read_bytes, since that does a local "bal" call to tls1_process_heartbeat. But then what about callers of ssl3_read_bytes? It doesn't look like there are any direct calls. Then ssl3_read_bytes is only called via function pointer. So where does that pointer come from? The pointers appear to be in the writable .data section, where we could patch them at shim load time. That's good. Unfortunately, at the C source file level those references are specified in static-visibility data, such as several in t1_meth.o. So I don't know if there is any way of writing a shim in (relatively) pure C; there would have to be architecture-specific offset-based word patching, and I don't know if it's worth it for OpenWrt. There are more space-efficient ways of patching libssl via an /overlay shim on top of a /rom libssl. On MIPS, the single text page with a reference to tls1_process_heartbeat could have write-protection turned off and the opcode overwritten. But that becomes very architecture-specific, or somebody has to write a portable SVR4 ELF .text patcher system. Let us hope we do not have to be patching like that very often. If it makes anybody feel better, vendors of other network devices should be discussing something like this decision now too. Most vendors don't have to worry about user programs or a proliferation of ROM images, but some do... -- Jay Strong authentication just proves which chump is in front of the keyboard. _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
