On Wed, 23 Mar 2005 23:10:18 +0100, Sven Luther wrote: > On Wed, Mar 23, 2005 at 03:13:32PM -0500, Andres Salomon wrote: >> OTOH, I have hardware that's already not supported by sarge (VIA video >> chipset that's only supported by xorg). As much as the security team is >> loathe to support multiple kernels, it does seem like having multiple >> kernels in d-i is the safest way to support this sort of thing. We get >> this for free in sarge, by having 2.4 and 2.6 kernels. In the future, it >> might be worth having multiple 2.6 kernels, or decoupling drivers from >> core kernel stuff (core kernel stuff is generally fairly easy to see >> regressions in, so there's no need to have multiple version of that). > > What about building module specific packages, which divert the broken modules > and replace them. This would even upto a point work for remote vulnerabilities > limited to modules in d-i, as it would be easier to supply those .udebs prior > to getting online or enabling the vulnerable module. >
What constitutes a "broken" module? Or do you mean giving the admin the ability to install multiple module packages in parallel? If modules were decoupled from core, the ABI suddenly becomes even more important. There are a lot of other issues to consider on the topic. The main reason I like the idea of decoupling drivers is, I can see when something in core is broken. It may take a lot of tracing through code, but in the end, it makes sense (the notable exception being the arch/ subdir). With drivers, if something is broken, it tends to come down to some hardware bug, or incorrect usage of a device; that sort of thing needs people w/ hardware to test, vendor specs and errata, etc. As such, it typically means regressions galore during large updates. Core updates thus end up being safer, so doing them during, say, a stable release is not something I would overly worry about. Driver updates are another matter entirely. > Do you have an idea whta proportion of security issues involve modules, > and not the core part as you put above ? > Well, I'd basically break up "core" by subdirectories; everything but the drivers/ subdir would be in core. Most of the (publicized) security issues are outside of drivers/; they've been in fs/, mm/, rarely in arch/, etc. People seem to put more effort into security holes that affect everyone, versus holes that only affect people w/ a specific card. That's not to say there aren't holes in drivers; for example, I noticed the following yesterday: http://gkernel.bkbits.net:8080/netdev-2.6/[EMAIL PROTECTED] Looks like a potential security hole to me. Will it be publicized? Probably not; it would be hard to exploit (I'm assuming someone would have to be on the local network to work around the gateway ensuring frames don't exceed the MTU), would only affect a small subset of Linux users, and someone would actually have to go through the trouble of making sure it actually *can* be exploited. There are plenty of these types of fixes all over the drivers/ subdir; there certainly have been publicized drivers/ holes (see Brad Spengler's advisories for moxa and so on), but they're typically easy to spot and fix (integer overflows in ioctls, etc). The holes in core generally get publicized, assigned CAN#s, etc; and those are the ones we (debian, ubuntu, redhat, etc) fix. They also tend to be a bit more complex; races in mmap, elf header mishandling, smbfs's crackheaded code doing wacky stuff, and so on. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
