Crispin Cowan wrote: > I conferred with Greg, and determined that we're saying the same thing, but I'm not > saying it as well :-) Great. > ... and that appears tobe a proposal to substantially expand the scope of this > project. > > * Architecturally, this coupling makes sense, because both tracing and security > need extensive hooking. > * Politically, it is much more questionable. Linus said he would accept a security > module abstraction. He said nothing about a trace facility. > > I don't wanna risk the acceptability of the LSM project by expanding its scope. If > you (Karim) want to float this past Linus, I suggest that you ask him. If he says > yes, then I'm all in. > > I don't mean to be harsh. Architecturally, it makes a lot of sense to combine thease > features. It is just politically difficult. So really, if you can get Linus' buy-in, > go for it. Well yes, definitely there are political differences. Which, as you point out, takes nothing away from the fact that the requirements are almost identical. > > > > I'm not sure LTT actually compares to Paradyn. It seems to me that > > the purposes are different. In LTT, the hooking portion is but a > > small part of the whole toolset. We need the hooks to retrieve > > meaningfull information about the system's behavior. The collected > > information is then fed to the analysis tool which provides the > > user with a view of the dynamic behavior of the system. > > That actually sounds kinda similar to Paradyn. I disagree as to the hooking part, the dynamic hooking part is a very central theme of their research as can be attested by their web-site and papers. I agree about the "feeding an analysis" tool part, but see below. > > > As you point out, Paradyn aims dynamic performance profiling and optimization. > > But LTT isn't aimed at dynamic optimization. Instead, it is aimed at: > > -Dynamic behavior reconstruction > > -Performance measurement > > -Synchronization-problem solving > > -Security auditing > > -Intrusion detection > > I think you bound "dynamic" to the wrong scope. Paradyn is about achieving performance > optimization through performance modeling. They do that through behavior > reconstruction & performance measurement. The "dynamic" part is to allow dynamic > change of the parts of the program being profiled. I'm not sure I got this wrong, check out their web-page and the paper you refer to. They put a lot of emphasis on the dynamic modification part. Even the "project overview" section puts a lot of emphasis on the dynamic modification and, obviously, performance measurement. Of course all this has to do with "reconstruction & performance measurement" as you point out, but I didn't say the contrary. I see no reference on their site, though, on any effort to provide a tool that provides the user with a clear view of the dynamic behavior of the system at each point in time, compared to what is provided by LTT's visualization tool (http://www.opersys.com/LTT/screenshots.html). Jointly, I hardly see how anyone could use Pardyn to solve a synchronization problem or do any form of security auditing ... Performance is THE focus of ParaDyn whereas Performance is ONE OF THE focuses of LTT. Cheers, Karim =================================================== Karim Yaghmour karymat_private Embedded and Real-Time Linux Expert =================================================== _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Thu Apr 19 2001 - 01:25:08 PDT