Dailydave mailing list archives
Re: Kernel 'developer' makes fuzzy FUD (RH Episodes: Volume 1)
From: L.M.H <lmh () info-pull com>
Date: Mon, 13 Nov 2006 16:30:07 +0100
I'm just wanting to see how you take advantage of this without root privileges or physical access to the machine.
Using Fedora Core, RHEL, and friends. That's how you take advantage :-) Ah, and Open Solaris development branch already does auto mounting, AFAIK.
I worked with LMH on fsfuzzer from March 5-8. The program was a great idea and started off as a 50 line shell script. My goal at the time was to get it to the point that it could create its own image
Usability work.
so that it could be tested to see if there were any problems in the kernel.
Already did before you had a single copy. Usability work didn't do anything to that part, except some automation. Period.
LMH had been playing with it
(...)
before we met and had found an ISO9660 problem (and maybe some others).
Only ISO9660? You miss JFS, etc. on purpose? or accidentally? Anyway.
Anyways, during those 3 days the program was able to create its own filesystem images and became much more useful. At the time, only ext2/3,
Define useful, please. It already did the job since the start. You made it monkey-compatible. Like putting a photo of a banana in a big button that turns on the propulsion of a rocket, without rocket science being involved.
iso9660, and the msdos file systems worked. I tested those and found nothing interesting. (This was also back in 2.6.14 kernel days.)
Well, interesting? from the perspective of a QA lead? While this is not being a personal attack at all, I would like to know what arguments you had by that time, to decide when an issue was 'interesting' or not. Lemme say, that when we met, you barely had an idea on the concept of fuzzing applied to kernel testing and other software. Being a QA lead, that's certainly a good question begging to be answered. And please don't argue that you knew it by the name of 'fault injection' or some other fancy marketing buzz-wording. Unless you're just a manager, that is. (No offense to managers out there, I've already met quite a few ones who rock, hint at some German mates).
This fall, I was curious how things were looking in the new 2.6.18 kernel and learned how to setup some more file systems and wanted to see if populating the image better and adding extended attribute operations would show new bugs. So, I added those to fsfuzzer. Sure enough there were new bugs I hadn't seen before. So, the next issue is how to give a corrupted image for someone to study and fix the problem. I added the code to let you replay the tests and got some more kernel developers involved since the kernel was not robust in the face of corrupt images.
OK, step-by-step. More usability work (which I appreciated). On the new bugs, thanks for clarifying. BTW, the replay code is still broken on real kernel panics, you need to transmit the image over network to a machine unless you want sync to mess up the streams.
or did you find them on your own and kept them private to redhat only?I found these bugs and filed bugzilla #'s 209907, 211237, 211668 before the month of kernel bugs was ever announced. I did mention to LMH that I was releasing a new version of fsfuzzer that did find and reproduce all these bugs and a few more that are not public.
Finally, you're getting to the hot spot. Nice. OK, please clarify why you mentioned *LITERALLY* the 'month of kernel bugs (nov. 1)' in that bug report. Maybe because of that conversation we had where you denied interest and effort to track the issues found? Maybe because you were playing a double-side game? Maybe because you didn't have any facts to support your argument ('"I found these bugs")? Gotta love plausible deniability, right? You knew about the MoKB, because I had the decency to tell you in advance. My fault. I should have probably developed a plot to abduct and feed you to crocodiles instead. That way I wouldn't have to waste my time replying to BS.
Sigh, these are bugs *I found* and we are getting people to fix these robustness issues. As for my response, how would you feel given the above?
Demonstrate you found them. And please don't try to play with the credibility hype (heard enough already). I've given enough evidence to support what I say. I won't bother replying anymore, as it seems rather useless. If you have any technical matters to discuss, I'll be more than happy to check. Just keep out of trying to cheat at me next time. It's not wise to give BS in turn of help from someone that doesn't need anything from you (aka uninterested help). Have a nice day. _______________________________________________ Dailydave mailing list Dailydave () lists immunitysec com http://lists.immunitysec.com/mailman/listinfo/dailydave
Current thread:
- Kernel 'developer' makes fuzzy FUD (RH Episodes: Volume 1) L . M . H (Nov 11)
- Re: Kernel 'developer' makes fuzzy FUD (RH Episodes: Volume 1) PERFECT . MATERIAL (Nov 11)
- Re: Kernel 'developer' makes fuzzy FUD (RH Episodes: Volume 1) L . M . H (Nov 11)
- Re: Kernel 'developer' makes fuzzy FUD (RH Episodes: Volume 1) Steve Grubb (Nov 12)
- Re: Kernel 'developer' makes fuzzy FUD (RH Episodes: Volume 1) Gadi Evron (Nov 12)
- Re: Kernel 'developer' makes fuzzy FUD (RH Episodes: Volume 1) Steve Grubb (Nov 12)
- Re: Kernel 'developer' makes fuzzy FUD (RH Episodes: Volume 1) L . M . H (Nov 13)
- Re: Kernel 'developer' makes fuzzy FUD (RH Episodes: Volume 1) Steve Grubb (Nov 17)
- Re: Kernel 'developer' makes fuzzy FUD (RH Episodes: Volume 1) L . M . H (Nov 17)
- Re: Kernel 'developer' makes fuzzy FUD (RH Episodes: Volume 1) Gadi Evron (Nov 12)
- Re: Kernel 'developer' makes fuzzy FUD (RH Episodes: Volume 1) PERFECT . MATERIAL (Nov 11)
- Re: Kernel 'developer' makes fuzzy FUD (RH Episodes: Volume 1) Steve Grubb (Nov 12)