| |||||||||||||
Wrong nameWrong namePosted Jan 17, 2008 9:56 UTC (Thu) by NAR (subscriber, #1313)Parent article: A kernel security hole
Maybe the name of the variable shouldn't be 'flag'. It's really the type of the variable (i.e. it's a flag), but it's name should indicate what it's used for (i.e. dir_access_mode - I don't know, how that's variable is used, so it's probably a wrong name).
(Log in to post comments)
Wrong name Posted Jan 17, 2008 10:45 UTC (Thu) by ms (subscriber, #41272) [Link]
Maybe people should actually use sensible types. At the very least, [Bool] would be
preferable, though obviously unbounded. It should really be a record with meaningful names:
data OpenFlags =
{ flagName1 :: Bool
, flagName2 :: Bool
, ...
}
data OpenAccMode =
{ modeName1 :: Bool
, ...
}
And then, oh look, 1) we have meaningful names 2) the fact it's a bit mask is obvious and 3),
and most importantly, you can't get them the wrong way round as the type of may_open is:
may_open :: NameIData -> OpenAccMode -> OpenFlags -> IO Int
Once again, this bug is simply a result of relying on a prehistoric language.
Wrong name Posted Jan 17, 2008 11:04 UTC (Thu) by njs (guest, #40338) [Link] What language would you suggest? For some reason the programming language geeks who understand why powerful type systems are useful also only care about hyper-abstract functional languages, which are nice and all but have serious limitations when it comes to writing a kernel, don't have compilers for most architectures, etc.
Wrong name Posted Jan 17, 2008 11:48 UTC (Thu) by ms (subscriber, #41272) [Link] Well there's no hiding it, I'm a Haskell fan. GHC does support the more standard architectures (x86, sparc, ppc - see http://haskell.org/ghc/download_ghc_682.html). As for performance, I really think that the choice of C in general is a premature optimisation. I would argue that it would be easier and quicker and much safer to write the kernel in a much higher-level language like Haskell and then invest time in making the compiler and optimiser really staggeringly clever. On the other hand, I'm in no way speaking from experience, so I guess like with most academics, the world will look the other way... Incidentally, the reason why powerful type-systems tend to only appear in functional languages is that imperative languages just allow the programmer too much madness to permit a really powerful type system. Scala pretty much contains everything you can get away with in an imperative language and even there, I'm unaware that anyone's actually proved it sound.
Wrong name Posted Jan 17, 2008 12:14 UTC (Thu) by tialaramex (subscriber, #21167) [Link] I would argue that it would be easier and quicker and much safer to write the kernel in a much higher-level language like Haskell and then invest time in making the compiler and optimiser really staggeringly clever. It's not obvious to me that this would work, nor that if it did work it would fix a sufficiently broad category of problems to be worthwhile, and nor that if it did work, AND fixed a broad category of problems, it would actually take comparable time (if it takes 10 years to do what used to take six weeks then you've shot yourself in the foot because 10 years is too late). It's also not obvious that Linux Kernel developers (often expert in C and low-level hardware stuff) would make good compiler designers, since these are largely unrelated skills. No-one has, to my knowledge, been stopping people from actually developing these staggeringly clever compilers over the decades since LISP and C were the state of the art. It's even regarded as a genuinely interesting problem (unlike Operating systems which have been largely treated as a commodity) so you could get funding to work on it.
Wrong name Posted Jan 17, 2008 21:27 UTC (Thu) by droundy (subscriber, #4559) [Link] "I would argue that it would be easier and quicker and much safer to write the kernel in a much higher-level language like Haskell and then invest time in making the compiler and optimiser really staggeringly clever." I'm also a big fan of Haskell, but wouldn't really want the kernel to be written in Haskell. It's a wonderful language, and adding more static type-checking to the kernel would be great, but for the kernel, performance should be everything (well, almost everything). I think the kernel devs have it right: add static checks to C (via sparse). David
high level kernel code Posted Jan 18, 2008 21:49 UTC (Fri) by giraffedata (subscriber, #1954) [Link] I agree with your view, but I don't like the phrasing, "compiler and optimizer." The optimizer is an intrinsic part of the compiler -- it's only in low level languages such as C that a user can have a concept of the natural object code, which can be distinguished from optimized code.The compiler has to be thought of as something that writes machine code, not something that translates source code into machine code. Then it makes sense to say people should spend their time making compilers that write efficient code rather than writing efficient code themselves.
Wrong name Posted Jan 17, 2008 11:10 UTC (Thu) by jonth (subscriber, #4008) [Link] Yeah, let's rewrite the kernel in Java. Or C#. Or Haskell. Can someone give me a mainstream example of a kernel written in anything other than C or assembler? I would be surprised. Maybe someone's done one in C++, but it doesn't address the concerns above. J
Kernels in other languages Posted Jan 17, 2008 12:05 UTC (Thu) by tialaramex (subscriber, #21167) [Link] Haiku (which possibly doesn't count as mainstream) uses lots of C++ including in the kernel and device drivers. It barely works (still isn't self-hosting after more than six years) and its performance is miserable, but there you are, an example of something other than C or assembler.
Kernels in other languages Posted Jan 17, 2008 12:20 UTC (Thu) by ms (subscriber, #41272) [Link] There are 3 kernels in Haskell, in various states of development and/or (dis)repair. House: http://programatica.cs.pdx.edu/House/ seL4: http://www.ertos.nicta.com.au/research/sel4/ Kinetic: http://www.ninj4.net/kinetic/ I think seL4 is the most active at the moment.
Kernels in other languages Posted Jan 17, 2008 12:29 UTC (Thu) by jonth (subscriber, #4008) [Link] Hardly mainstream, but I have to say I didn't expect to see anything in Haskell. I doff my cap. Does anyone know how fast these things go?
Kernels in other languages Posted Jan 17, 2008 15:14 UTC (Thu) by mrfredsmoothie (subscriber, #3100) [Link] They go to 11.
Wrong name Posted Jan 17, 2008 12:25 UTC (Thu) by NAR (subscriber, #1313) [Link] Once again, this bug is simply a result of relying on a prehistoric language.I'm afraid it's not. I agree that C could be improved with a bitfield type like this:
bitfield accessMode {
bit open;
bit write;
...
};
but wrongly named variables of same types would still lead to these kind of errors.
Wrong name Posted Jan 17, 2008 12:29 UTC (Thu) by ms (subscriber, #41272) [Link] No no. The problem is these parameters should not have the same type.
Wrong name Posted Jan 17, 2008 13:06 UTC (Thu) by BenHutchings (subscriber, #37955) [Link] They could be changed to enumerated types, but that wouldn't automatically help much because conversion between integer and enumerated types is implicit in C. Perhaps sparse would have caught it though.
Wrong name Posted Jan 17, 2008 14:28 UTC (Thu) by nix (subscriber, #2304) [Link] It could have been made more obvious, and thus more likely to be rapidly spotted, by making sure that FMODE_WRITE and MAY_WRITE had different *values* which overlapped with something quite different in the other flag: but if that had been thought of, this bug would never have happened because people would have been paying extra attention to it anyway.
Wrong name Posted Jan 17, 2008 16:17 UTC (Thu) by tbellman (guest, #49983) [Link] Except that it wouldn't have helped. The buggy code used FMODE_WRITE to check the bit in the variable 'flag'; the correct code uses MAY_WRITE to check the bit in the variable 'acc_mode'. The buggy code did use the correct access mechanisms for the variable it looked at, so no amount of BDSM type control would have helped.
Wrong name Posted Jan 17, 2008 13:06 UTC (Thu) by guus (subscriber, #41608) [Link] C already supports bitfields:
struct accessMode {
int open:1;
int write:1;
...
};
Bitfields Posted Jan 17, 2008 14:57 UTC (Thu) by zlynx (subscriber, #2285) [Link] But the kernel doesn't appear to use bitfields much. I seem to remember that it's something to do with GCC and miserable performance on non-x86 arch's.
|
|||||||||||||