how to completely crash minix - Minix

This is a discussion on how to completely crash minix - Minix ; hi everybody there is a serious bug in minix, i believe to see what i mean, just try the following: in /usr/src/servers/is/dmp_kernel.c go into any of the dmp functions, comment its body out and instead insert: for (i=0;i Then compile, ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 23

Thread: how to completely crash minix

  1. how to completely crash minix

    hi everybody
    there is a serious bug in minix, i believe
    to see what i mean, just try the following:

    in

    /usr/src/servers/is/dmp_kernel.c

    go into any of the dmp functions, comment its body out and instead
    insert:

    for (i=0;i<100000000;i++) printf("Hello, this will crash the system");

    Then compile, install and restart is and then press the function that
    triggers that function which you just modified. You will see a couple
    of repeats of the string (as expected) but ultimately, the system will
    completely freeze. I jnow this function isnt particularly useful, but
    this crash sure is completely inappropriate.. i was trying to do
    something elsde when i found this out..
    i haev tried this both in qemu and bochs. bochs just crashes minix,
    but in qemu, the qemu inside the vm is so serious, it actually freezes
    my host os and i have to restart x!!! (linux)


  2. Re: how to completely crash minix

    > Then compile, install and restart is and then press the function that
    > triggers that function which you just modified. You will see a couple
    > of repeats of the string (as expected) but ultimately, the system will
    > completely freeze. I jnow this function isnt particularly useful, but
    > this crash sure is completely inappropriate.. i was trying to do
    > something elsde when i found this out..


    I know plenty of ways to make Minix crash by changing it. If you modify
    the operating system, it's not called a bug.

    The way the different servers (FS, IS and PM) communicate and interact
    may can be complex and may simply not allow what you're doing. If such
    things are not currently done in the release version of such a server,
    it's not a bug.

    If you can reproduce it without changing the OS, from a user program
    rather than a server which is part of the OS, then it would be a bug.

    Still it might be interesting to know exactly why this is happening, so
    if you find something, please let us know. With more information about
    the problem, maybe some unknown actual bugs may be found.

  3. Re: how to completely crash minix

    On Sep 6, 7:14 pm, "Erik van der Kouwe" wrote:
    > > Then compile, install and restart is and then press the function that
    > > triggers that function which you just modified. You will see a couple
    > > of repeats of the string (as expected) but ultimately, the system will
    > > completely freeze. I jnow this function isnt particularly useful, but
    > > this crash sure is completely inappropriate.. i was trying to do
    > > something elsde when i found this out..

    >
    > I know plenty of ways to make Minix crash by changing it. If you modify
    > the operating system, it's not called a bug.


    Well, without modifying the kernel. The Minix kernel is supposed to
    survive just about *any* server crash. That's what the microkernel
    architecture is said to be all about, and this target has obviously
    not been met.

    >
    > The way the different servers (FS, IS and PM) communicate and interact
    > may can be complex and may simply not allow what you're doing. If such
    > things are not currently done in the release version of such a server,
    > it's not a bug.


    I found this error when I tried to rewrite an exercise in the osdi
    book under the current MINIX version. The exercise concists of keeping
    track in the kernel of the number of messages sent from each process
    to other processes and then print out this matrix when a function key
    is hit. My first thought was indeed that this was because I had
    modified the kernel, but then I recompiled the original (official)
    kernel I had got from the site and only modified the information
    server as described above and it still crashed. I also found out that
    printing a short string many times does not crash the system but a
    long string does, so something like

    for (i=0;i<1000000;i++) printf("H");

    does NOT crash but

    for (i=0;i<1000000;i++) printf("Hello, this will crash");

    will crash.

    I also found out that this bug (yes it definitely IS a bug) is not
    present in the book version of minix, I mean, the MINIX version that
    came on the CD that came with the book, so I've decided to stick with
    the book while studying MINIX, because there seem to have been too
    many changes already...


  4. Re: how to completely crash minix

    On Sep 6, 7:14 pm, "Erik van der Kouwe" wrote:
    > > Then compile, install and restart is and then press the function that
    > > triggers that function which you just modified. You will see a couple
    > > of repeats of the string (as expected) but ultimately, the system will
    > > completely freeze. I jnow this function isnt particularly useful, but
    > > this crash sure is completely inappropriate.. i was trying to do
    > > something elsde when i found this out..

    >
    > I know plenty of ways to make Minix crash by changing it. If you modify
    > the operating system, it's not called a bug.


    Well, without modifying the kernel. The Minix kernel is supposed to
    survive just about *any* server crash. That's what the microkernel
    architecture is said to be all about, and this target has obviously
    not been met.

    >
    > The way the different servers (FS, IS and PM) communicate and interact
    > may can be complex and may simply not allow what you're doing. If such
    > things are not currently done in the release version of such a server,
    > it's not a bug.


    I found this error when I tried to rewrite an exercise in the osdi
    book under the current MINIX version. The exercise concists of keeping
    track in the kernel of the number of messages sent from each process
    to other processes and then print out this matrix when a function key
    is hit. My first thought was indeed that this was because I had
    modified the kernel, but then I recompiled the original (official)
    kernel I had got from the site and only modified the information
    server as described above and it still crashed. I also found out that
    printing a short string many times does not crash the system but a
    long string does, so something like

    for (i=0;i<1000000;i++) printf("H");

    does NOT crash but

    for (i=0;i<1000000;i++) printf("Hello, this will crash");

    will crash.

    I also found out that this bug (yes it definitely IS a bug) is not
    present in the book version of minix, I mean, the MINIX version that
    came on the CD that came with the book, so I've decided to stick with
    the book while studying MINIX, because there seem to have been too
    many changes already...


  5. Re: how to completely crash minix

    "Erik van der Kouwe" wrote:

    > I know plenty of ways to make Minix crash by changing it. If you modify
    > the operating system, it's not called a bug.


    I have to admit that at first glance I also arrived at your conclusion.
    Nonetheless, if sancho1980's assertions are true (I haven't tried it
    myself), then, having in mind minix's claims of reliability and
    auto-regeneration, it sure does fit rather nicely with the very definition
    of software bug.


    Rui Maciel

  6. Re: how to completely crash minix

    Op Fri, 07 Sep 2007 15:26:55 +0100, schreef Rui Maciel:

    > "Erik van der Kouwe" wrote:
    >
    >> I know plenty of ways to make Minix crash by changing it. If you modify
    >> the operating system, it's not called a bug.

    >
    > I have to admit that at first glance I also arrived at your conclusion.
    > Nonetheless, if sancho1980's assertions are true (I haven't tried it
    > myself), then, having in mind minix's claims of reliability and
    > auto-regeneration, it sure does fit rather nicely with the very
    > definition of software bug.
    >
    >
    > Rui Maciel


    I think that the kernel doesn't use the printf function but has its own
    way of printing to the condole.


  7. Re: how to completely crash minix

    On Sep 8, 3:31 pm, wim letzer wrote:
    > Op Fri, 07 Sep 2007 15:26:55 +0100, schreef Rui Maciel:
    >
    > > "Erik van der Kouwe" wrote:

    >
    > >> I know plenty of ways to make Minix crash by changing it. If you modify
    > >> the operating system, it's not called a bug.

    >
    > > I have to admit that at first glance I also arrived at your conclusion.
    > > Nonetheless, if sancho1980's assertions are true (I haven't tried it
    > > myself), then, having in mind minix's claims of reliability and
    > > auto-regeneration, it sure does fit rather nicely with the very
    > > definition of software bug.

    >
    > > Rui Maciel

    >
    > I think that the kernel doesn't use the printf function but has its own
    > way of printing to the condole.


    I think you're not getting my point: by making a change to the
    information server (btw, a really harmless change), I can make the
    whole MINIX system crash. Everything is dead afterward. No way out.
    Not even for the kernel. That is exactly the kind of error that
    shouldn't be even possible with a microkernel structure. If you can
    make the kernel crash by screwing up your servers, then you might as
    well go back to a monolithic kernel. To ask who uses which function in
    order to print to the console is completely beside the point. There is
    a bug in the kernel, that's all I wanted to say. I have no clue where
    the bug lies, but it must have been added recently, because as I said
    ealier, this error does not come up in older versions of MINIX 3.


  8. Re: how to completely crash minix

    On Sep 8, 6:14 pm, sancho1980 wrote:
    > On Sep 8, 3:31 pm, wim letzer wrote:
    >
    >
    >
    > > Op Fri, 07 Sep 2007 15:26:55 +0100, schreef Rui Maciel:

    >
    > > > "Erik van der Kouwe" wrote:

    >
    > > >> I know plenty of ways to make Minix crash by changing it. If you modify
    > > >> the operating system, it's not called a bug.

    >
    > > > I have to admit that at first glance I also arrived at your conclusion.
    > > > Nonetheless, if sancho1980's assertions are true (I haven't tried it
    > > > myself), then, having in mind minix's claims of reliability and
    > > > auto-regeneration, it sure does fit rather nicely with the very
    > > > definition of software bug.

    >
    > > > Rui Maciel

    >
    > > I think that the kernel doesn't use the printf function but has its own
    > > way of printing to the condole.

    >
    > I think you're not getting my point: by making a change to the
    > information server (btw, a really harmless change), I can make the
    > whole MINIX system crash. Everything is dead afterward. No way out.
    > Not even for the kernel. That is exactly the kind of error that
    > shouldn't be even possible with a microkernel structure. If you can
    > make the kernel crash by screwing up your servers, then you might as
    > well go back to a monolithic kernel. To ask who uses which function in
    > order to print to the console is completely beside the point. There is
    > a bug in the kernel, that's all I wanted to say. I have no clue where
    > the bug lies, but it must have been added recently, because as I said
    > ealier, this error does not come up in older versions of MINIX 3.


    I think the problem is very simple. The MINIX designers have to
    specify what is trusted computing base (that part which must be
    perfect in order for a system to ensure key properties). In case of
    Linux, TCB is formed by kernel and perhaps by several user-space
    programs. In case of MINIX, the proposed illusion, is that TCB is
    completely formed by microkernel. If this is the goal, than what you
    have found is a bug and should be sent to bugs@minix3.org. If IS is
    part of TCB, then it is not a bug. But in that case we know that TCB
    is somewhat larger than the microkernel. Actually, size of TCB matters
    rather than what runs in kernel space and what runs in user-space.

    I believe.


  9. Re: how to completely crash minix

    All,

    On 2007-09-05, sancho1980 wrote:
    > hi everybody
    > there is a serious bug in minix, i believe
    > to see what i mean, just try the following:
    >
    > in
    >
    > /usr/src/servers/is/dmp_kernel.c
    >
    > go into any of the dmp functions, comment its body out and instead
    > insert:
    >
    > for (i=0;i<100000000;i++) printf("Hello, this will crash the system");
    >
    > Then compile, install and restart is and then press the function that
    > triggers that function which you just modified. You will see a couple
    > of repeats of the string (as expected) but ultimately, the system will
    > completely freeze. I jnow this function isnt particularly useful, but
    > this crash sure is completely inappropriate.. i was trying to do
    > something elsde when i found this out..


    I'm running 'current' (of course). If I do what you describe (on real
    hardware) (of course), my systems keeps running (in fact I'm writing
    this post using it). Top shows this as the first few lines:

    load averages: 2.26, 0.77, 0.26
    45 processes: 3 running, 42 sleeping
    Mem: 851664K Free, 842380K Contiguous Free
    CPU states: 0.83% user, 40.83% system, 58.33% kernel, 0.00% idle

    PID USERNAME PRI NICE SIZE STATE TIME CPU COMMAND
    [ -2] root 0 92K RUN 0:54 58.33% system
    7 root 14 -16 152K RUN 0:34 29.17% tty
    9 root 14 -13 84K 0:09 7.50% log
    4 root 4 -8 212K 0:01 2.50% vfs
    297 driver 3 -10 224K 0:01 1.67% is

    ... which is pretty reasonable.

    The other posters to this thread are right in general - it's
    easy to fiddle with system servers causing Minix to break which
    can't really be called a bug in Minix.

    > i haev tried this both in qemu and bochs. bochs just crashes minix,


    If Minix really hangs/crashes, in this case, that shouldn't happen. If
    you do this kind of stuff while other parts of the system are waiting
    for a reply to a message, then strange behaviour can be expected - most
    bits of Minix can't yet deal with the message protocol not being obeyed.
    But that doesn't apply to these functions; IS is just running in its
    down time and nobody is waiting for it. So nothing horrible should
    happen.

    > but in qemu, the qemu inside the vm is so serious, it actually freezes
    > my host os and i have to restart x!!! (linux)


    Well, that can't be Minix's fault.

    =Ben



  10. Re: how to completely crash minix


    Ben Gras wrote:

    >> but in qemu, the qemu inside the vm is so serious, it actually freezes
    >> my host os and i have to restart x!!! (linux)

    >
    > Well, that can't be Minix's fault.


    I've been on the verge of writing that for some days: Given that the
    host OS freezes or seems to freeze (it's only X ...), I wonder wether
    that isn't a bug in the emulators' display emulation or the X server
    of the host system which can't take a huge amount of high speed output
    from the simulated Minix.

    My suggestion is that the OP tries the bug on real hardware and see
    what happens.

    Regards -- Markus




  11. Re: how to completely crash minix

    wim letzer wrote:

    > I think that the kernel doesn't use the printf function but has its own
    > way of printing to the condole.


    I believe that that is perfectly irrelevant. The only relevant question here
    is if a server crash does in fact takes the whole OS down.


    Rui Maciel

  12. Re: how to completely crash minix

    On Sep 9, 3:40 pm, Matej Kosik wrote:
    > I think the problem is very simple. The MINIX designers have to
    > specify what is trusted computing base (that part which must be
    > perfect in order for a system to ensure key properties). In case of
    > Linux, TCB is formed by kernel and perhaps by several user-space
    > programs. In case of MINIX, the proposed illusion, is that TCB is
    > completely formed by microkernel. If this is the goal, than what you
    > have found is a bug and should be sent to b...@minix3.org. If IS is
    > part of TCB, then it is not a bug. But in that case we know that TCB
    > is somewhat larger than the microkernel. Actually, size of TCB matters
    > rather than what runs in kernel space and what runs in user-space.


    The design (according to the various design documents) has always been
    to have the Operating System interface (TCB) consist of the
    Microkernel, the FS, the PM and the reincarnation server. Having to
    rid only 4000 lines of kernel code of bugs is a bit exaggerated as a
    bug in the file system can be just as lethal as a bug in the kernel.
    On the other hand there are less lethal bugs the file system can have
    since it has less privileges. Therefore it does actually make a
    difference to have the FS/PM/RS running outside the kernel in terms of
    reliability when you assume code is not perfect (Linux et al. assume
    it is).

    Marco


  13. Re: how to completely crash minix

    Hi Marco

    On Sep 12, 12:55 am, "ma...@few.vu.nl" wrote:
    > On Sep 9, 3:40 pm, Matej Kosik wrote:
    >
    > > I think the problem is very simple. The MINIX designers have to
    > > specify what is trusted computing base (that part which must be
    > > perfect in order for a system to ensure key properties). In case of
    > > Linux, TCB is formed by kernel and perhaps by several user-space
    > > programs. In case of MINIX, the proposed illusion, is that TCB is
    > > completely formed by microkernel. If this is the goal, than what you
    > > have found is a bug and should be sent to b...@minix3.org. If IS is
    > > part of TCB, then it is not a bug. But in that case we know that TCB
    > > is somewhat larger than the microkernel. Actually, size of TCB matters
    > > rather than what runs in kernel space and what runs in user-space.

    >
    > The design (according to the various design documents) has always been
    > to have the Operating System interface (TCB) consist of the
    > Microkernel, the FS, the PM and the reincarnation server. Having to
    > rid only 4000 lines of kernel code of bugs is a bit exaggerated as a
    > bug in the file system can be just as lethal as a bug in the kernel.
    > On the other hand there are less lethal bugs the file system can have
    > since it has less privileges.


    The fact that a given component has less privileges is not important
    when it has the same authority as kernel. PM and FS belong to Minix
    trusted computing base (each of them can easily crush kernel by
    zeroing it out or writing various mischievious data therein). Due to
    UNIX nature, it is unrealistic to assume, that PM or FS could be
    outside TCB (you need processes working, you need filesystem, or at
    least virtual file system and some real file system working). So
    switching to microkernel architecture does not help here.

    So the first question is, what you think forms your TCB? Is it only
    - your microkernel
    - system task
    - clock task
    - disk driver
    - FS
    - RS
    - IS
    - PM
    ?

    Nothing more? If nonthing more, this already seems realistic (albeit
    looks slightly worse than the advertised 4000 lines of code).

    However, if any kind of device driver can cause deadlock, crushing
    (zeroing out) the kernel or other denial of service in the whole OS,
    all the drivers are part of TCB. I am somewhat skeptical whether you
    have succeeded to extract device drivers from TCB. If yes, I
    congratulate. There is one last thing to evaluate: the price you have
    to pay. Couldn't all this (minimizing TCB) be done more elegantly by
    using decent (object-capability) programming languages? If not, why?


    > Therefore it does actually make a
    > difference to have the FS/PM/RS running outside the kernel in terms of
    > reliability when you assume code is not perfect (Linux et al. assume
    > it is).
    >
    > Marco


    Matej


  14. Re: how to completely crash minix

    Matej Kosik wrote:
    > Hi Marco


    > On Sep 12, 12:55 am, "ma...@few.vu.nl" wrote:
    > The fact that a given component has less privileges is not important
    > when it has the same authority as kernel. PM and FS belong to Minix
    > trusted computing base (each of them can easily crush kernel by
    > zeroing it out or writing various mischievious data therein). Due to
    > UNIX nature, it is unrealistic to assume, that PM or FS could be
    > outside TCB (you need processes working, you need filesystem, or at
    > least virtual file system and some real file system working). So
    > switching to microkernel architecture does not help here.


    The only part of Minix capable of writing in the kernel's memory space is
    the kernel itself. The MM has the right to touch other processes' memory
    areas, but all this goes through the kernel. I can't recall if this is
    actually implemented right now, but it is very easy for the kernel to deny
    a request from the MM to write data into kernel space.

    Oh, and you don't need a file system or memory manager to have a working
    operating system. It all depends on what you need to do with your OS: it
    is very well possible to create a boot image that contains all necessary
    processes already created in the kernel's process table. If you know in
    advance that none of these processes will ever stop nor will they ever
    fork or need their memory image changed, you don't need a PM. Your tiny
    system doesn't necessarily need a file system either: by setting the right
    flags in the kernel, processes can communicate to device drivers directly
    through Minix' message passing primitives. All you need are some user
    space device drivers, the kernel and one or more precreated processes.
    What use would this have? An embedded OS in household appliances.

    > So the first question is, what you think forms your TCB? Is it only
    > - your microkernel
    > - system task
    > - clock task
    > - disk driver
    > - FS
    > - RS
    > - IS
    > - PM
    > ?


    I'd say: microkernel, system task, clock task, reincarnation server (if
    you need process management).

    > Nothing more? If nonthing more, this already seems realistic (albeit
    > looks slightly worse than the advertised 4000 lines of code).


    > However, if any kind of device driver can cause deadlock, crushing
    > (zeroing out) the kernel or other denial of service in the whole OS,
    > all the drivers are part of TCB. I am somewhat skeptical whether you
    > have succeeded to extract device drivers from TCB. If yes, I
    > congratulate. There is one last thing to evaluate: the price you have
    > to pay. Couldn't all this (minimizing TCB) be done more elegantly by
    > using decent (object-capability) programming languages? If not, why?


    Object-capable programming languages do not prevent user (programmer)
    error, they only try to prohibit the ones that are easy to make. This does
    not prevent errors altogether, as Bjarne Stroustrup said: "C makes it
    easy to shoot yourself in the foot. C++ makes it harder, but when you do,
    it blows away your whole leg". In other words: an object-oriented device
    driver may very well still deadlock or bork up in some way and thereby
    damage/destroy the kernel. If the driver operates outside the kernel, the
    system remains responsive so you can kill and reinstantiate the driver.

    Regards,

    Jens

    --
    Jens de Smit
    Student Computer Science | Vrije Universiteit Amsterdam
    jfdsmit@few.vu.nl | http://www.few.vu.nl/~jfdsmit
    "[In the end, people] get furious at IT that the goddamn magic isn't working"
    -- Stewart Dean

  15. Re: how to completely crash minix

    > The only part of Minix capable of writing in the kernel's memory
    > space is the kernel itself.


    Actually everyone can, although it is always done through the kernel.

    Just try this command:
    cat /dev/zero > /dev/kmem

    This resets your computer, showing that the kernel memory is indeed
    overwritten (this may only be possible for the root though).

  16. Re: how to completely crash minix

    On Sep 12, 1:54 pm, "Erik van der Kouwe" wrote:
    > > The only part of Minix capable of writing in the kernel's memory
    > > space is the kernel itself.

    >
    > Actually everyone can, although it is always done through the kernel.
    >
    > Just try this command:
    > cat /dev/zero > /dev/kmem
    >
    > This resets your computer, showing that the kernel memory is indeed
    > overwritten (this may only be possible for the root though).


    Device drivers in Minix (latest published version available on CD)
    have the *authority* to overwrite any part of RAM. You can do that
    either as shown above. Or you can write your device driver that does
    exactly that. It does not matter. The problem is that have such
    authority even though they do not need it. An example of excess of
    authority. Unless you remove this deficiency, all drivers must be
    regarded as part of TCB and thus must be perfect. It is so because
    their unperfectness not only can cause that some services (related to
    the particular device) are not available (such as bluetooth
    communication) but also that other, unrelated, services may be
    crippled (such as sound card, harddisk contents, the whole kernel).

    Another problem is that any device driver can cause deadlock (denial
    of service) of the whole operating system. For example:

    #include "../drivers.h"

    void main(void)
    {
    message mess;

    while (TRUE)
    receive(ANY, &mess);
    }

    Unless any driver has an authority to cause such effects all drivers
    are part of TCB because we have to trust them that they "obey the
    rules". Am I right?

    PS: I am using latest Minix installable from CD.


  17. Re: how to completely crash minix

    On Sep 12, 11:57 am, "J.F. de Smit" wrote:

    snip

    >
    > Object-capable programming languages


    > do not prevent user (programmer)
    > error, they only try to prohibit the ones that are easy to make. This does
    > not prevent errors altogether, as Bjarne Stroustrup said: "C makes it
    > easy to shoot yourself in the foot. C++ makes it harder, but when you do,
    > it blows away your whole leg". In other words: an object-oriented device
    > driver may very well still deadlock or bork up in some way and thereby
    > damage/destroy the kernel. If the driver operates outside the kernel, the
    > system remains responsive so you can kill and reinstantiate the driver.


    You a right. But I did not mean object-oriented language. This is not
    enough or it is irrelevant. I meant object-capability language. Such
    languages enable programmers to refer to other objects (or functions
    or procedures) with unforgeable capabilities.

    Here are some examples (I am aware of). Not all can be used for same
    purposes:
    http://www.erights.org/
    http://www.hpl.hp.com/techreports/20...-2006-116.html
    http://altair.sk:60001/mediawiki/index.php/Tamed_Pict

    What is wrong for example with "Tamed Pict"? It provides the
    programmer with the ability to create processes (albeit not *hardware*
    processes), it provides decent message passing mechanisms.
    Additionally, since it is an object-capability language, even though
    the whole operating system is part of a single hardware process,
    inside it is split into many components each of which must obey
    different security policy. So there is no need to rely on hardware
    processes and some primitive message passing utilities such as Minix
    SEND, RECEIVE, SENDREC, ECHO, NOTIFY.

    I admit. None of these languages is mature but I do not think that
    they would be inherently wrong choice (instead of C). Speed is not the
    only aspect. The difference is in elegance of communication and your
    possibilities to enforce different security policies and the ability
    to follow the principle of the least authority *without* decreasing
    the overall elegance of the whole system.

    Why for example PM has the authority to erase your harddisk? Does it
    need such an authority? I figure, that at present nobody bothered to
    properly constrain authorities of various Minix components because it
    would lead to clunky code. What's worse, such code would be part of
    TCB.

    I am asking out of curiousity what you think about these languages
    because I do not understand why they are disregarded. They do not
    support everything why might need but unless someone starts using them
    for real projects, they will never ripe.

    Regards




  18. Re: how to completely crash minix

    In article <1189601276.454387.5360@50g2000hsm.googlegroups.com>,
    Matej Kosik wrote:
    >Device drivers in Minix (latest published version available on CD)
    >have the *authority* to overwrite any part of RAM.


    In the lastest SVN version that is now disabled by default. In the
    3.1.3a you can start a driver with that privilege disabled.

    >Another problem is that any device driver can cause deadlock (denial
    >of service) of the whole operating system. For example:
    >
    > #include "../drivers.h"
    >
    > void main(void)
    > {
    > message mess;
    >
    > while (TRUE)
    > receive(ANY, &mess);
    > }



    In SVN-current, this should have no effect on INET. An ethernet driver
    can do whatever it likes, and INET will just ignore it after the first time it
    does something wrong. You can restart the ethernet driver to get it going
    again.

    The same thing is scheduled for the filesystem, but it not clear when that
    will be done.


    --
    That was it. Done. The faulty Monk was turned out into the desert where it
    could believe what it liked, including the idea that it had been hard done
    by. It was allowed to keep its horse, since horses were so cheap to make.
    -- Douglas Adams in Dirk Gently's Holistic Detective Agency

  19. Re: how to completely crash minix

    On Sep 12, 3:25 pm, Matej Kosik wrote:
    > On Sep 12, 11:57 am, "J.F. de Smit" wrote:
    >
    > snip
    >
    >
    >
    > > Object-capable programming languages
    > > do not prevent user (programmer)
    > > error, they only try to prohibit the ones that are easy to make. This does
    > > not prevent errors altogether, as Bjarne Stroustrup said: "C makes it
    > > easy to shoot yourself in the foot. C++ makes it harder, but when you do,
    > > it blows away your whole leg". In other words: an object-oriented device
    > > driver may very well still deadlock or bork up in some way and thereby
    > > damage/destroy the kernel. If the driver operates outside the kernel, the
    > > system remains responsive so you can kill and reinstantiate the driver.

    >
    > You a right. But I did not mean object-oriented language. This is not
    > enough or it is irrelevant. I meant object-capability language. Such
    > languages enable programmers to refer to other objects (or functions
    > or procedures) with unforgeable capabilities.
    >
    > Here are some examples (I am aware of). Not all can be used for same
    > purposes:http://www.erights.org/http://www.hp...php/Tamed_Pict
    >
    > What is wrong for example with "Tamed Pict"? It provides the
    > programmer with the ability to create processes (albeit not *hardware*
    > processes), it provides decent message passing mechanisms.
    > Additionally, since it is an object-capability language, even though
    > the whole operating system is part of a single hardware process,
    > inside it is split into many components each of which must obey
    > different security policy. So there is no need to rely on hardware
    > processes and some primitive message passing utilities such as Minix
    > SEND, RECEIVE, SENDREC, ECHO, NOTIFY.
    >
    > I admit. None of these languages is mature but I do not think that
    > they would be inherently wrong choice (instead of C). Speed is not the
    > only aspect.


    And when we talk about speed, the native language communication is
    always far more efficient than communication between two hardware
    processes. Some trivial "measurements" are mentioned for example here:

    http://altair.sk:60001/mediawiki/upl.../Backwater.pdf
    on page 127.

    Although speed of message passing is not critical when it is
    sufficiently cheap when compared to the overall work that is done in
    between to message-sends, the fact that it is cheaper than what Minix
    gives us need not to be neglected---mostly when opponents of
    Microkernel approach often operate with this argument. Within these
    silly measurements (anyone can make more realistic ones):
    - Passing of a single message in Pict takes 37 CPU cycles
    - Passing of a single message in RMoX (Occam on Raw Metal, that is
    very similar to Backwater approach) takes 80 CPU cycles
    - Passing of a single message in Minix takes takes 1455 CPU cycles
    - Passing of a single message in Singularity takes 2462 CPU cycles

    Personally, I do not see a single reason why to use hardware processes
    and C. I am curious about other peoples opinion why language-based
    approach could be wrong path.

    > The difference is in elegance of communication and your
    > possibilities to enforce different security policies and the ability
    > to follow the principle of the least authority *without* decreasing
    > the overall elegance of the whole system.
    >
    > Why for example PM has the authority to erase your harddisk? Does it
    > need such an authority? I figure, that at present nobody bothered to
    > properly constrain authorities of various Minix components because it
    > would lead to clunky code. What's worse, such code would be part of
    > TCB.
    >
    > I am asking out of curiousity what you think about these languages
    > because I do not understand why they are disregarded. They do not
    > support everything why might need but unless someone starts using them
    > for real projects, they will never ripe.
    >
    > Regards




  20. Re: how to completely crash minix

    On Sep 12, 3:21 pm, phi...@ue.aioy.eu (Philip Homburg) wrote:
    > In article <1189601276.454387.5...@50g2000hsm.googlegroups.com>,
    > Matej Kosik wrote:
    >
    > >Device drivers in Minix (latest published version available on CD)
    > >have the *authority* to overwrite any part of RAM.

    >
    > In the lastest SVN version that is now disabled by default. In the
    > 3.1.3a you can start a driver with that privilege disabled.
    >
    > >Another problem is that any device driver can cause deadlock (denial
    > >of service) of the whole operating system. For example:

    >
    > > #include "../drivers.h"

    >
    > > void main(void)
    > > {
    > > message mess;

    >
    > > while (TRUE)
    > > receive(ANY, &mess);
    > > }

    >
    > In SVN-current, this should have no effect on INET. An ethernet driver
    > can do whatever it likes, and INET will just ignore it after the first time it
    > does something wrong. You can restart the ethernet driver to get it going
    > again.
    >
    > The same thing is scheduled for the filesystem, but it not clear when that
    > will be done.



    Unfortunately, I am not able to upgrade from Minix 3.1.2a to SVN
    trunk. Whenever I do that, I end up with unmountable root filesystem.

    /dev/c1d0: No such file or directory

    If you generate new CD image (or even better, publish a QEMU image), I
    will be able to check it. You say that the above program when loaded
    as a driver will not cause denial of service after someone requests
    services of such a that driver?

    >
    > --
    > That was it. Done. The faulty Monk was turned out into the desert where it
    > could believe what it liked, including the idea that it had been hard done
    > by. It was allowed to keep its horse, since horses were so cheap to make.
    > -- Douglas Adams in Dirk Gently's Holistic Detective Agency




+ Reply to Thread
Page 1 of 2 1 2 LastLast