Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Subterfuge with Subterfugue 97

Posted by michael from the playing-in-the-sandbox dept.
toadnine writes "Things you never imagined you could do with Python and a 2.4 kernel... check out SUBTERFUGUE. (Source: Need To Know)." A blue pill for applications.
This discussion has been archived. No new comments can be posted.

Subterfuge with Subterfugue More

Subterfuge with Subterfugue

Comments Filter:

  • here is the first few lines of that Web site... (Score:4, Informative)

    by Anthony Boyd ( 242971 ) on Saturday April 06, 2002 @01:15AM (#3294743) Homepage

    In case of slashdot effect, here's the summary:

    SUBTERFUGUE is a framework for observing and playing with the reality of software; it's a foundation for building tools to do tracing, sandboxing, and many other things. You could think of it as "strace meets expect."

    Features

    • simple interface for writing tools
    • can follow, rewrite, and annul system calls
    • can follow, rewrite, and annul signals (with limits)
    • follows whole process (and thread) trees
    • can follow across fork, vfork, and clone
    • has a fairly good wait4 emulation
    • can follow job control (with limits)
  • Can somebody please explain to me the benefit of doing this in Python?
    I'm not trolling, I just fail to see why they decided to use Python.

    • Because this is exactly the sort of thing python is good for. It's clean and encourages reuse, and it's easy to write quickly, even for relatively slow programmers.

      In this case it was probably the C integration that made it work really well.

    • I'm not a programmer, nor am I in the computer/tech industry, but even I have been able to program in Python without too much problem. As the other reply states, Python is easy. Not fast but easy. And, if speed is needed, you can always prototype with Python and add the speed later.

      Just my 2-cents.
      • Python is easy. Not fast but easy.
        It's generally slower, but that doesn't necessarily mean it's slow. I've been using it to do manipulation and search of massive genome files, and it can be quite fast if you think carefully about what you're doing.

        Much of the time, speed of implementation counts for more than speed of execution.

        Mike

    • Re:What is the point? (Score:3, Insightful)

      by krmt ( 91422 )
      Aside from the obvious speed of development and ease of programming, there seem to be two big advantages. That I can tell.

      The first is that the options you pass to trick the program are actually python code, if you look at the tutorial on the site.

      The second is that you can easily extend the thing to write new tricks without recompilation. The tutorial actually demonstrates how the current tricks are written so that you can write your own. Granted, you could do this just as well in C or whatever, but this way the program can be directly modified with ease and no recompiles. This is important both to the original developer and the user who wants to extend it (which will be plenty of users, I'm sure).

      Overall, he says that a lot of the code will be moved in to C at some point for additional speed, but I'd imagine that prototyping your trick in python first will be the standard. Hmmm... it might finally be time for me to sit down and learn Python after doging it for years.

    • Re:What is the point? (Score:2, Informative)

      by mkcmkc ( 197982 )
      Can somebody please explain to me the benefit of doing this in Python?
      The other replies have hit on most of the reasons:
      • Ease of Implementation: SUBTERFUGUE required a lot of trial and error to get working (such as it does) and was written mostly during hours of the night when I really needed to be sleeping instead. Implementing it in any other language, excepting perhaps Lisp, would simply have taken more time than I had.
      • Ease of Use: One of the primary design goals was to enable a user with an idea to try it out in very short order, just the way that we use shell tools like bash, tr, sort, etc, to do real-time prototyping.
      • And finally, Python just plain rocks.

      Mike

    • It was easier that way. Rewritting to C would help performance quite a bit, but I'm not going to do that, and I guess Mike is not going to do that, either. Pavel
  • Does the kernel need to be patched?

    Cuz if it doesn't one could easily make this very useful for multimedia work. Add GIMP text to movie while compressing to mpeg.
    • Um how's that offtopic? I have some questions since I can't get to the site.

      Christ don't moderators read before they mod. Wait, /.ers don't read before they comment.

      Um, as I was saying...
    • I suppose you *could* do that, conceivably, by trapping syscalls, figuring out which ones hold the image data (which would require either analysing the data that's being read or written, or making your code highly specific to the version of the software it modifies), and modifying it inline... but it'd be a hideously difficult thing to do, and slow as hell.

      In short, that's not what this is good for.

      If you want to add your text to a movie while compressing it, there are already good plugin-based frameworks for doing that sort of thing (I won't name names since it depends on whether you're trying to do streaming compression, compression to disk, etc)... but even writing your own framework to do the overlay and passing the result into an MPEG encoder yourself would be much, much easier than trying to do syscall-level interception of the data.
    • SUBTERFUGUE runs on the vanilla 2.4 kernel. (Patches were required for previous versions, but they were wrapped into 2.4)

      It would be potentially useful for trying out ideas like this, but as another poster noted, it's not really intended for permanent implementations of such things.

      Mike

  • Our faith in the superiority of *nix security is somewhat misplaced, though. For the coming battle, *nix is almost as defenseless as scorned Windows.

    I for one have to agree... though i am no kernel hacker i have at least given a laymans browse through some networking code and from my opinion(a programming student) the *nix kernel and general code of the *nix's does not haven more defense against hacking...

    i kind of agree with thos that say that *nix is apred because there is much less motivation to hack it... not many script kiddies run it so they would rather us windows to nuke windows... as soon as the long predicted switch over to linux happens (however quickly) then *nix WILL have the same problems as win...

    i think this is the type of project that we as a commmunity should really try to rally around and help out...

    'nother quote...

    The primary goal of SUBTERFUGUE is to help you keep control of your computer

    so if you can help do so now... and please everyone we need to look into the security issues before they become vulerabilities...
    • OK. You know the one about the chain, don't you?

      "A chain is only..."

      That's where *nix has (or seems to, anyway) have it all over Windows in reference to secutity. I have several processes on my XP laptop that run with root privs, and do so by default unless I want to really do some hacking and change the privs they have. (I can do it, but have much better things to do) A buffer overflow later I can be hacked to death.

      (Aside: To all "yuo skr1p7 k1d33z", I'm behind a good firewall. And patched to the 9s. :-P)

      Only having tight, secure networking code does not good security make, though it is probably the most important. The whole must be designed to be secure or it all falls down.

      Soko
    • i have at least given a laymans browse through some networking code and from my opinion(a programming student) the *nix kernel and general code of the *nix's does not haven more defense against hacking... Haven more defense? Speak English boy!

    • The code isn't the big difference where security is concerned; the design philosophy is. Looking at the code will help with the small things (buffer overflows, &c) -- but in terms of being generally more secure on a large scale with software that's spent significantly more time in the field (and thus which has had the obvious implementation issues worked out), design issues become substancially more important.

      A system with a good design won't require checks to be spread throughout the implementation; rather, they'll be at well-defined points. Assumptions (as to what kind of input to accept, for instance) will be well-defined, explicit where necessary, and documented. Much of this is not the kind of thing you pick up from looking at the low-level code.

      Finally, a reminder: For a long time, UNIX was the only game in town. It hosted the huge university servers and was having security issues addressed in all likelihood well before you were born. It's thus rather funny to see one saying that Windows appears more vulnerable because it is attacked more -- as UNIX systems were handling attacks long before Windows even existed.

      Spend five years or so actually doing design and implementation work; then maybe you'll be qualified to make the kind of statement you just did.
    • lemme explain some things...
      well i dont really understand why i was modded flamebate because i meant no flaming... i simply wish for *nix to get more secure... i beleive that this new tehcnology will help very much... and i was quoting from the article itself and then agreeing to it...

      also as for my personal experiance in programming i have been learning to program for over 5 years now and what i meant was that I actually have taken a look at some of the code unlike many security experts who gain their entire base of knowloedge form a user standpoint... i believe that right NOW *nix is more secure but who knows what would happen if there was a flood of people going over to use it...

      what i meant was that there would be a bigger motivation to hack it... right now not many people wanna try and mess with *nix but i beleive that *nix needs to prepare... i have not seen very much actual security defense other than sinply 'ive never been hacked' which makes me afraid...

      my point is that *nix IS more secure NOW but who knows where it will go in the FUTURE... i just wish it stays as secure as it is now... im just kinda tired of people putting blind faith in *nix... i put my faith in it too but thats because i have looked into some wide spread problems and i think that *nix is the answer and we must all try and help... no flame intended

  • Application Firewall (Score:5, Interesting)

    by lcorc79 ( 549464 ) on Saturday April 06, 2002 @01:56AM (#3294810) Homepage
    Very interesting - this sounds like the tools to create application-level firewall I've alwys wanted. (putting on Asbestos suit, yes I use Windows) I wish something like this was available for the Windows platform, although I'd doubt the closed-source nature of the MS system calls etc would make this reasonable for anyone other than M$ to create, and I doubt they'll be exposing these sorts of tools for developers any time soon.

    Firewalls like ZoneAlarmPro let the user keep an eye on which programs are accessing the network, but don't provide much more granularity than that - and do nothing to protect/inform the user about what the application may be doing locally (filesystem access, etc). With a tool like this, a very granular application-level firewall could be created that would enable you to peek at the app down to any level, whether you wanted to know exactly which network connections it was making (each individual socket - rather than ZoneAlarmPro's "yes, allow this to access the network" which then lets the app do any connections it wants), or whether you wanted to see which files it accessed and/or prevent that access.

    Sounds great! :)
    • the granular information you want can be found using the utilities at www.systeminternals.com - though these only monitor filesystem, network, etc. activity and do not forestall villainy.
      • the granular information you want can be found using the utilities at www.systeminternals.com - though these only monitor filesystem, network, etc. activity and do not forestall villainy

        Yes, I actually use several of these (particularly RegMon lately) and love them - but as you pointed out they are only good for external observation, not for altering the 'reality' of the applications environment as Subterfuge apparently can do, or for preventing an access as a Firewall can/should. But I guess knowing who's spying on you and how is a good first step, even if we can't prevent it yet ;)

    • Very interesting - this sounds like the tools to create application-level firewall I've alwys wanted.
      Paraphrasing from the page: "it is slow. About 10x slower than normal. Running Netscape under subterfuge is like running Netscape remotely and displaying it over a 28.8 connection".

      yes I use Windows
      Never mind... you won't notice the difference.
      • Heh, yeah, I've done remote X desktops over a 14.4 before (I was just playing around with it all at the time, luckily I had no real work to do!). But I was speaking more about the technology and toolsets in general rather than the specific implementation.

        The site mentions that speed is *not* their primary goal here, but rather simplification of the development of Tricks. But they also say that they expect speed to improve - and of course if it were written in a lower level language it could be optimized further, etc. We've also got to take into consideration Moore's law, etc - I just think the technology here is interesting and could make my granular "Application Firewall" a much simpler (and closer) reality ...

    • Norton purchased the rights to WRQ's AtGuard(tm) product, and now markets it as their own. It can restrict network access on a per port and a per application basis.

      While there are a few annoying bugs still seemingly in the product (from my viewpoint anyway; the most annoying one being that launching "C:\Program Files\Directory\Item.exe", "C:\Progra~1\Direct~1\Item.exe", "C:\Program Files\Direct~1\Item.exe", etc., all are treated as seperate applications), for the most part, it works. It has privacy controls to block HTTP referers, cookies, trojan blocking (although if a legit application binds to a trojan port, watch out), etc.

      And if I did not mention, while this product was called AtGuard, it worked on Windows 95/98 back in 1999 [wrq.com], and still works on Windows XP, so it has been around. Now if only someone made a product with the file restriction permissions per application that Subterfugue seems to do...

    • In the commercial software world there is software for Windows that acts as an app. level firewall. It is OKENA's [okena.com] StormWatch [okena.com] software solution. I have received training in this software and it is able to control the following application access attempts:

      - Access to the Network
      - Access to the Registry
      - Access to the File System
      - Access to the Windows OS (OLE, DCOM, ActiveX etc.)

      For each of these, you can set very fine grained controls. For example, you can restrict "Notepad" to only be able to access .txt files, no registry, no network. Or you can allow some registry keys, but not others.

      Generally a very good piece of software, I watched it catch Nimda purely through its behavior, not a signature.

    • Check out Tiny Trojan Trap [tinysoftware.com]. It seems to be exactly what you're looking for.
    • I like Tiny Personal Firewall [tinysoftware.com] a lot better than zone alarm or blackice. :) It's free (for personal use), and gives you fine grained control over the network connections your applications make. You can restrict them to certain ip's and / or port combinations, including incoming / outgoing traffic. They also have a program called Tiny Trojan Trap, which is a sandbox'ing type program, I haven't checked it out, but it sounds neat.

      my .02 cents.

  • ummm... (Score:2, Informative)

    by hajmola ( 82709 )
    i think you mean red pill, Neo.

    • "... you take the blue pill: the story ends. You wake up in your bed and believe whatever you want to believe. You take the red pill: you stay in wonderland, and I show you how deep the rabbit-hole goes."

      As the blub states: "A blue pill for applications." You can get the applications to "believe whatever you want [them] to believe".

  • This looks like it would be a very good test
    suite tool box, from the looks of it you could
    use this to stress test your application in all
    sorts of ways. Want to know how your app deals
    with some level of network or system misbehavior,
    it would be very easy to write a pass through
    script that would mangle 1 in 300 characters read
    off the wire, or produce a randomised map of
    'bad' sectors on the storage volume that
    can be written to but not read from.

    Bad signals, subtly wonky devices etc. would all
    be trivially easy to emulate, this is a tool you
    would want if you really want to make your
    app bulletproof.

    • YES! (Score:1)

      by mkcmkc ( 197982 )
      Exactly. Excellent! One of the practical uses for SUBTERFUGUE would be to simulate environments that are difficult to create in reality. How do you regression test behavior under disk-full conditions? You can actually fill the disk, but what a pain in the ass.

      Although it hasn't been done yet, it'd be possible to write a fake-ptrace trick (along the lines of qtrace aka mec) which would allow you to fake a disk full while running the program in question under gdb (or strace or whatever).

      Mike

  • Well... I'm writing this while extremely intoxicated.... So Mod me down if wrong

    Wouldn't writing Kernel code in a higher level language put it in more of a position to be "used in a manner not intended"

    The higher up the language scale you go you get more and more vauge with your literal meanings of code...

    By adding more and more layers you open yourself up to more and more exploits at the Kernel level... So why re-invent the wheel.... It works... It works well.... So why change...
    • Yes, you are intoxicated. This was meant for high-level control of programs for testing purposes, unless I misread it. It was not meant to be running all the time as a sort of imitation of kernel-level sandboxes. It was to simulate conditions, test stuff, etc.
      • Basically, yes, though perhaps the sandbox usage could eventually more production.

        In any case, it's not any kind of security hole, because it doesn't rely in any way on anything but vanilla kernel behavior. (It is a "security" headache to an application that's planning to do something sneaky, but that's intended.)

        Mike

        • There is something sort of like this in the kernel of one of the BSDs (OpenBSD?) that would create a sandbox, called jail. You'd have to google around for more information, though.
  • It's programs like these that make some people so queasy about Open Source.

    Sure, it's very interesting that Linux has a system interface that's so straightforward that it can be easily manipulated in sort-of-real-time by a simple scripting language, and I'm sure you have to be root to run it, but somehow the fact that somebody's already put together something like this, even just as a proof-of-concept, really makes me less confident about Linux, not more.

    Maybe it's just the whole Matrix-like undertones.*

    *ObGeekFiction: Actually, the first literary reference that came to my mind was Hiro's "BigBoard" in Snow Crash. (Looks like someone is working on the Metaverse [geocrawler.com] too...)

    • but somehow the fact that somebody's already put together something like this, even just as a proof-of-concept, really makes me less confident about Linux, not more.

      So let me get this straight... Because the system is more-or-less fully documented and has straightforward and clean APIs that allow you to poke and prod at it in a well-defined manner you are less confident about the OS? I'm sure glad you don't design cars or houses or medical equipment, that's for damn sure.

    • You're trolling, but I'll bite.

      Sure, it's very interesting that Linux has a system interface that's so straightforward that it can be easily manipulated in sort-of-real-time by a simple scripting language

      People have already pointed out the 'application firewall' use, and probably the fantastic debugging uses. It's not just interesting, it's dang useful. Think about how people could use it to chase down possible buffer overflows. Force the system to return something other than what your program expects. How does it respond? Gracefully? Die an ugly death? Maybe I should fix that... :-)

      and i'm sure you have to be root to run it

      Maybe not. So long as it's enabled in the kernel, you should be able to make use of it. strace and truss and their ilk have been doing the 'trace system calls' thing for years. This is just more powerful.

      but somehow the fact that somebody's already put together something like this really makes me less confident about Linux, not more.

      Already? I have no clue what you're talking about. Linux has been around for more than a decade. Python's been around for almost a decade too. Unix has been around in some form since the late 60's. Already in the 2.4 kernels? They've been around for more than a year.

      • Yes, right on.

        Root is not required, though it may be run as root. It makes use of nothing not already present in the Linux 2.4 kernel; nothing needs to be enabled. It really doesn't do anything you couldn't do yourself with gdb, if you were really clever and patient. :-)

        Mike

  • Capability OS's (Score:2, Interesting)

    by loz ( 64114 )
    The author states that Windows is flawed by design, the same can be said about *nix. That why sf exists, it's a hack to cover up the design flaw.

    Take a look at capability operating systems [google.com]. That how the design flaw should really be solved.

    loz

    • Re:Capability OS's (Score:5, Interesting)

      by digitalEric ( 527320 ) on Saturday April 06, 2002 @10:33AM (#3295279)

      Yes, a pure capability system is the state-of-the-art in computer security (assuming you have an intelligent way of handing out capabilities -- a problem I have not seen the solution to yet).

      But, you should note that if you can run a per-system call check (which Subterfuge seems to let you), you can implement a capability system on top of UNIX! The whole point of Subterfuge is that you can insert your own algorithm for deciding if process P can perform action A. This allows you to implement ACL's, capabilities, or whatever you can think up! The speeed will be underwhelming (though much optimization is possible), but it will work, right now, with all of your existing programs.

      Show me a pure capability system that does this, and I will eat my hat (and then run said system). Bonus points if it supports all the hardware Linux runs on.

      ps, for a good introduction to capabilities the state of such operating systems research visit the EROS website [eros-os.org] and visit the "introductory essays" section.

      • Re:Capability OS's (Score:3, Informative)

        by HiThere ( 15173 )
        Except, if I understand correctly, that this is basically a debugger, and that it isn't a part of the OS Kernel.

        It seems more like a system emulation package that runs in user space, and within which a program can be executed (by the emulator). The emulator then passes any calls it chooses to the system in a normal way, traces what it chooses, throws any it chooses into the bit bucket, etc.

        Sounds like a nice tool, but not an OS kind of system.

        • Except, if I understand correctly, that this is basically a debugger, and that it isn't a part of the OS Kernel.
          No, though it does its magic using the same techniques that a debugger would (ptrace, currently). It is not part of the kernel--correct.
          It seems more like a system emulation package that runs in user space, and within which a program can be executed (by the emulator).
          It's not really an emulator, it's an interposition tool. It interposes itself right on the user/kernel boundary, though it is itself outside of the kernel.
          Sounds like a nice tool, but not an OS kind of system.
          It's not a replacement for global capabilities. (Nor are they a replacement for it!)

          Mike

    • I wouldn't call Unix flawed in the sense that I think you mean. Its design is sound. It is limited in handling the user-vs-application problem, but it's probably better than anything else available. Windows-plus-Office, on the other hand, is in a completely different league--its design is like a magnet for bad luck.

      I don't know enough about capabilities to have much of an opinion. It seems like a useful feature, though it's pretty coarse-grained and requires root assistance.

      SUBTERFUGUE does many things--it wasn't intended to address this problem exlusively or in an optimal way.

      Mike

  • prototype fault-tolerant file system (Score:5, Interesting)

    by ericnewton ( 46030 ) on Saturday April 06, 2002 @08:36AM (#3295036)
    I used subterfugue to intercept system calls like "read" and "write" for arbitrary programs. Then I fowarded these system calls to Recall [fault-tolerant.org] which replicated the requests.

    I got it working in a couple of days. Working in a high-level language and all in user-space really simplified the task.

  • Wasn't someone working on embedding a Perl interpreter in the Linux kernel a while ago? And/or rewriting all of /bin as Perl scripts using the kernel-based interpreter? Did anything ever come of this , umm, cunning plan?

    • Re:Perl in the Linux kernel? (Score:5, Informative)

      by Shiny Metal S. ( 544229 ) on Saturday April 06, 2002 @11:45AM (#3295515) Homepage

      Wasn't someone working on embedding a Perl interpreter in the Linux kernel a while ago? And/or rewriting all of /bin as Perl scripts using the kernel-based interpreter?

      I haven't ever heard about it, until I read your comment. After a quick Google searching I found some info about it.

      In the Summer 2000 issue of The Perl Journal, Simon Cozens wrote Perlix, The Perl Operating System [samag.com] article:

      It started, as so many of these things do, with one of those interminable debates between programmers. You know what I mean. They usually end up with one party shouting something like "Well, fine, I don't care if it's impossible, I'm going to do it anyway!"

      This time around, it was me, and the topic in question was an operating system user-space comprised of non-GNU components. An operating system consists of two components: the kernel, like Windows or Linux, which talks to the hardware and directs the action, and the user-space, which is all the programs that you see and use: a shell, Explorer, programs to list directories, move files, read your mail, play games, and so on.

      On "free" operating systems, a sizeable proportion of the essential user-space - not the really high-level things like web browsers, but the basic stuff that gets the system up and running - comes from the GNU project, and it was these programs that I wanted to replace.

      Don't get me wrong. This wasn't an anti-GNU jihad. But someone had told me it wasn't possible, which was precisely the incentive I needed to get stuck into an idea I'd had a while ago.

      Any sensible person would use BSD code here -- the BSD project derived their utilities from de-commercialized sources of Unix, and evolved independently of GNU. But that would be easy. And it wouldn't be fun. If you're going to prove a point, do it with style. So I was going to do it with Perl. [...] [samag.com]

      Very interesting text, he mentions Tom Christiansen's Perl Power Tools: The Unix Reconstruction Project [perl.com] - "Our goal is quite simply to reimplement the classic Unix command set in pure Perl, and to have as much fun as we can doing so." I like the simple version of cat [perl.com]:

      #!/usr/bin/perl -w
      print while <>;

      Simon Cozens also writes about Gregor Purdy's Perl Shell [focusresearch.com] (psh) - "The Perl Shell is a shell that combines the interactive nature of a Unix shell with the power of Perl. The goal is to eventually have a full featured shell that behaves as expected for normal shell activity. But, the Perl Shell will use Perl syntax and functionality for control-flow statements and other things." - and about Claudio Calvelli's Linux filesystem written in Perl (PerlFS), but the link [assurdo.com] is dead and I couldn't find the new PerlFS home page (anyone knows it?).

      On 2000-09-26 the SF Project: Perlix Kernel [sourceforge.net] was registered by Bill Dahab [sourceforge.net]. The Perlix.sf.net [sourceforge.net] homepage is empty, the Development Status is Planning. The stats [sourceforge.net] show more activity a year ago. Here's the summary:

      Perlix is to be an POSIX compliant operating system based on the more graceful language of Perl, in stead of the uglier C. This specific project is to make a kernel written in Perl, and other core components for this operating system

      Let me also quote the latest news [sourceforge.net] about Perlix:

      Posted By: rydor
      Date: 2001-08-05 14:19
      Summary: Ok, the deal with perlix

      For one thing, work has not yet really begun on the perlix kernel, at most it's been in speculation. The main thing, is that this project really needs Perl6 to go ahead. Also, is needed (i don't really know if Perl6 will allow it) is direct memory writing via perl. If anyone wants to hack it into Perl 5, that would be great. One thing that may be very helpful, is to load Perl into system memory. From there Perl should run fast enough on a more high end computer to support a kernel. Another thing that has been thought about is since a Perl kernel would be relatively dynamic, have on the fly kernel upgrades, via a special script to be written. So if you want to swap in a new network driver that works better, you use this script, and the script would somehow through that driver in quickly. Anyway, If anyone is interested in joining for planning this out, either email me at Rydor@dahab.com or post to the board here, but posting to that board will probably take me a lot longer to figure out that you've done so. Anyway, hopefully we can get this figured out enough to get off the ground, and I hope the project will be lots of fun.

      I also found Greg McLearn's Perl Operating System: Initial Planning Stage [uwaterloo.ca] from 2001-11-23:

      The first order of business is to make a bootable Perl kernel. Basically, this will consist of the Perl 4 core components being hacked into a state whereby it can be loaded into memory after booting and executed. In the initial stages, any Perl code to be executed will be stored as a string and handed to the interpreter module. In later stages, the Perl code will be executed from an arbitrary memory buffer.

      Making the Perl 4 core components bootable is easier said than done. A memory-management system will have to be created to replace that found in a standard Unix system. As well, any dependency on the I/O subsystem will have to be removed or replaced.

      I am basing the initial design on Perl 4 because the source code is far easier to understand and modify. Perl 4 does not contain many oddities currently found in the Perl 5 runtime (such as OOP and macro-hell). [...] [uwaterloo.ca]

      It sounds very interesting and I'm going to find out more about the current stage of Perlix/PerlOS development (if any). If anyone knows something interesting, please let us know.

  • Neat hack, but... (Score:4, Informative)

    by Salamander ( 33735 ) <jeff.pl@atyp@us> on Saturday April 06, 2002 @09:10AM (#3295080) Homepage Journal

    People seem to be assuming that subterfugue is kernel code. I just looked at the source, and it's not. It depends on some kernel patches for 2.3.x, but subterfugue itself is a user-level syscall interceptor. When they refer to sf as the subterfugue driver, they mean "driver" in the mushy sense of "anything that's not an application is a driver", not in the precise sense of something that gets loaded into the kernel. Also, only programs (and their descendants) run explicitly via subterfugue are affected at all; it doesn't hook in at a level that allows it to operate on arbitrary processes.

    Subterfugue is basically a Python wrapper for strace, so you can inspect and modify syscalls and their arguments in Python instead of in C. Yes, it's neat, but not nearly as neat as being able to implement real drivers or network protocols or filesystems in Python (like this [lwn.net]).

    • People seem to be assuming that subterfugue is kernel code. I just looked at the source, and it's not. It depends on some kernel patches for 2.3.x, but subterfugue itself is a user-level syscall interceptor.
      Correct, but note that no patches are required for 2.4. It's meant to run on a vanilla kernel, just like 'strace'.
      When they refer to sf as the subterfugue driver, they mean "driver" in the mushy sense of "anything that's not an application is a driver", not in the precise sense of something that gets loaded into the kernel.
      Actually, by "driver" I just meant that 'sf' is the ringmaster that manages and applies all the tricks, sort of like dejagnu is a driver for regression tests. As you note, this has nothing to do with kernel drivers.
      Also, only programs (and their descendants) run explicitly via subterfugue are affected at all; it doesn't hook in at a level that allows it to operate on arbitrary processes.
      Correct and construed as a benefit. SUBTERFUGUE was meant to ride herd on a single program or perhaps a small set, leaving the rest of the system alone. This means, for example, that it doesn't require any special privileges and that the rest of the system is unaffected by it.

      Sometimes you do want to do things on a system level, and there are several other tools out there that take this approach. The right tool for the right job.

      Subterfugue is basically a Python wrapper for strace, so you can inspect and modify syscalls and their arguments in Python instead of in C. Yes, it's neat, but not nearly as neat as being able to implement real drivers or network protocols or filesystems in Python (like this [lwn.net]).
      FUSE (and several other tools like it) is cool. It's solving a different problem. As above, different tools for different tasks.

      Mike

  • Just what the Unix world needs... (Score:4, Interesting)

    by connorbd ( 151811 ) on Saturday April 06, 2002 @09:23AM (#3295107) Homepage
    ... trap patching.

    This is one of those nasty little types of hacks that was the main inspiration for Apple going to OS X. To those of you who don't know much about it, every version of MacOS Classic to be seen by the public has a mechanism for subverting system calls that has seen especially heavy use since System 7 (rumor has it that the majority of upgrades to the system have been done this way, at least up until OS 8.5 or so, because no one knows how to operate the Classic build scripts anymore). It's actually routine to short-circuit the Mac Toolbox when doing low-level programming.

    If you want some real strange fireworks, get an old (68k) Mac running some version of System 7 and a copy of an extension called Screwy. AFAIK it was written as a prank and will break every UI call in the system without actually crashing anything (at least not immediately). Really sick.

    /Brian
    • In its defense, I will point out that SUBTERFUGUE is meant as a tool for experimenting and prototyping, and to be used primarily by an end user (perhaps during a development process, as with strace). Obviously building software meant for distribution on top of it would probably be a blunder from an engineering perspective.

      Mike

    • Um, this all goes on in user space and is for software development. No one is going to be able to crash their machine with subterfugue, and the applications that they crash will be crashing for good reasons. So it's a little different from MacOS in that regard. It seems like a pretty elegant hack.

      And I always thought that the reason MacOS did so much trapping was just to keep things modular. Upgrades to the Toolbox might have required traps if the Toolbox resided on ROMs... And there's nothing essentially wrong with trapping the way MacOS did. The reason it felt dirty was because of the lack of protected memory. If an application didn't work well with some extension, it wouldn't necessarily die quietly.

      Am I full of it? Some Mac weenie want to correct me?
      • The point is that patching a trap is patching a trap whether it's protected or not. I realize it's isn't quite so dangerous on Unix; it's still skeevy software engineering if you don't have to do it. The mechanisms on MacOS Classic date back to 1981 and were originally designed for a 64K computer. It was a necessity at the time; the problem is that Apple didn't get anything remotely resembling a decent shared library format until ASLM (which sucked because it was tied to Apple's MPW tools, which few used); they later mostly junked it in favor of COM when OpenDoc shipped.

        Patching traps was skanky programming but it was necessary. That doesn't make it a good idea now, when on-chip caches are larger than the entire memory bank on the original Mac, which is why Apple did away with it completely rather than try to add equivalent functionality to Rhapsody/Darwin.

        All I can say is this: Subterfugue has its legitimate uses, most of which involve reverse-engineering and packet-sniffing (developing a Linux driver for an iPod comes to mind as one application). Any application developer who uses it in a program deserves to be hurt; "patching traps" and/or the equivalent is the API equivalent of a "come from" statement and anyone who feels that it's critical to serious application development is either perverse or lazy.

        /Brian

Slashdot Top Deals

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (10) Sorry, but that's too useful.

Close