[9fans] kenfs
i put a new version of the kenfs code we're running at coraid on sources. /n/sources/contrib/quanstro/src/myfs. we continue to see good performance and the most serious problem encountered so far is that the default route was configured incorrectly requiring a creative dynamic route for sntp. this version fixes a locking problem in send and recv when called spllo and a few bugs with odd configurations. it also deprecates devsd code. the huge size of the myricom firmware lead to devices and ethernet controllers. these are controlled by tables in $conf/etherctlr.c and $conf/devtab.c. this has reduced the size of the kernel built for the soekris 4501 (aska) to 177994 bytes compressed. finally, the partition code has been reworked so that fdisk or prep partitions may be used in addition to old-style partitions. this allowed the boot code to use a Device instead of a one-off construct for the nvr file. thus the nvr file for aska is nvr=ph0"9fat"!fs.nvr where ph0"9fat" is a regular Device and fs.nvr is a fat file name. the same syntax may be used in filsys declarations. the main filesystem on my new (unfinished) fs is declared as filsys main cpe2.0"kcache"e2.1 since i need just a few gb of cache, using an fdisk partition allows me to archive linux junk to the rest of that partition without opening an lba accountancy. for performance reasons, it would make less sense for the cache and worm to share a partitioned target. the floppy as been temporarly (?) broken by this change. if anyone is interested in a soekris 4501 fs, contact me off list. judging by the size of my worm, a 4GB CF should be enough to run for several years. or, use a small boot CF and an aoe target. - erik
Re: [9fans] a challenge
> I saw something even more bizarre last night on busy box: it looked the punctuation is wrong there, i think: > I saw something even more bizarre last night: busy box and you could just stop there
Re: [9fans] Non-stack-based calling conventions
On 22-Feb-08, at 3:32 PM, Douglas A. Gwyn wrote: I don't understand what good it does to map Plan 9 object code into Linux files. Is there a Linux filetype for Plan 9 that invokes a system-call interpreter, or what? No, I just write a handler for interrupt 0x64 that calls either an existing linux syscall (it works for some of them) or a custom in- kernel routine (for the more 'exotic' plan 9 syscalls). Yes, the project is currently aimed at x86 only. -- Anant
Re: [9fans] a challenge
> It's just amazing the kind of stuff that the gnu guys are wrapping > around the kernel to try and bail the boat out. I guess when you're sinking you do whatever it takes. Imagine what it's like for Microsoft... ++L PS: MS-DOS didn't have all this trouble, I sometimes wonder if all this additional security isn't exactly the opposite of what's needed. I feel the same about cars with electronics and air bags, which is hardly surprising because there are incredible parallels between the car industry and the computer industry. But the issue of security is terribly ambiguous.
Re: [9fans] Small GCC steps...
> The big challenge is to get it back to the gcc core so we don't have a > full port each time. There's a lot to do. Just to play catch-up is a bit of a mission, specially if it's not clear how everything fits together. I still need to (a) get the APE library ported to GCC, which I presume I can do with the 3.0 version, there have been significant changes and some useful files (mkconfig, mksyslib) have not made into the distribution; (b) identify the changes in GCC 3.0 from its release, which is also no trivial task; (c) apply the changes to GCC 4.2.3 - which is the most recent release - and verify that a new release can be generated successfully. I then need to go all the way back and try to regenerate GCC 4.2.3 (or later) from a pristine Plan 9 release, there are always odd bits that sneak into the woodwork (like the mk* files) and only resurface as problems. Finally, I need to wrap the whole lot into some reliable mechanism to reproduce all my efforts with none of the errors. And don't nobody say autoconf, right now! On the other hand, a reliable "config.h" file for Plan 9 that describes truthfully what does apply to Plan 9 and/or APE would be nice to have. Sometime in this process I probably need to get a copyright assignment with the FSF, before I can submit any changes to GCC. I guess Bell Labs may have to tackle that aspect, too. ++L
Re: [9fans] a challenge
On Fri, Feb 22, 2008 at 10:23 AM, andrey mirtchovski <[EMAIL PROTECTED]> wrote: > well, i checked the source. turns out bash 3.2 drops privileges if uid > != euid and requires the -p flag to allow itself to run in setuid > mode: I saw something even more bizarre last night on busy box: it looked like some library and/or bash was looking for a file called /etc/sudo_test or some such. It's just amazing the kind of stuff that the gnu guys are wrapping around the kernel to try and bail the boat out. ron
Re: [9fans] a challenge
well, i checked the source. turns out bash 3.2 drops privileges if uid != euid and requires the -p flag to allow itself to run in setuid mode: $ cp /bin/bash . $ sudo chown root bash $ sudo chmod 4755 bash $ ./bash -p # id uid=500(andrey) gid=500(andrey) euid=0(root) groups=500(andrey) # whoami root # that doesn't make me like Plan 9 any less, you know :) On Fri, Feb 22, 2008 at 10:53 AM, ron minnich <[EMAIL PROTECTED]> wrote: > here is a challenge. I realize it's linux but I think this is the > right group to ask anyway; I think you'll appreciate the humor in it. > So far few I have talked to have gotten it. > > There is a file, called /bin/bash. > > You are allowed to do this as root. > cp this file to /tmp. Do something to it to make it so that, when you > are not root, you can run the file in /tmp and get a root shell. > > Don't assume the obvious. And please don't post "that's trivial" until > you have actually done it. > > ron >
Re: [9fans] a challenge
Nope. On Feb 22, 2008, at 12:57 PM, Pietro Gagliardi wrote: I don't have Linux, but I'll see if Mac OS X has that vulnerability. On Feb 22, 2008, at 12:53 PM, ron minnich wrote: here is a challenge. I realize it's linux but I think this is the right group to ask anyway; I think you'll appreciate the humor in it. So far few I have talked to have gotten it. There is a file, called /bin/bash. You are allowed to do this as root. cp this file to /tmp. Do something to it to make it so that, when you are not root, you can run the file in /tmp and get a root shell. Don't assume the obvious. And please don't post "that's trivial" until you have actually done it. ron
Re: [9fans] a challenge
> here is a challenge. I realize it's linux but I think this is the > right group to ask anyway; I think you'll appreciate the humor in it. > So far few I have talked to have gotten it. > > There is a file, called /bin/bash. > > You are allowed to do this as root. > cp this file to /tmp. Do something to it to make it so that, when you > are not root, you can run the file in /tmp and get a root shell. > > Don't assume the obvious. And please don't post "that's trivial" until > you have actually done it. > > ron On Debian, all you have to do is this as root: cp /bin/bash /tmp/sh chmod u+s /tmp/sh Then you can run /tmp/sh as any user and get euid root. It seems that you can ONLY do this if you rename bash to sh. John
Re: [9fans] a challenge
I don't have Linux, but I'll see if Mac OS X has that vulnerability. On Feb 22, 2008, at 12:53 PM, ron minnich wrote: here is a challenge. I realize it's linux but I think this is the right group to ask anyway; I think you'll appreciate the humor in it. So far few I have talked to have gotten it. There is a file, called /bin/bash. You are allowed to do this as root. cp this file to /tmp. Do something to it to make it so that, when you are not root, you can run the file in /tmp and get a root shell. Don't assume the obvious. And please don't post "that's trivial" until you have actually done it. ron
[9fans] a challenge
here is a challenge. I realize it's linux but I think this is the right group to ask anyway; I think you'll appreciate the humor in it. So far few I have talked to have gotten it. There is a file, called /bin/bash. You are allowed to do this as root. cp this file to /tmp. Do something to it to make it so that, when you are not root, you can run the file in /tmp and get a root shell. Don't assume the obvious. And please don't post "that's trivial" until you have actually done it. ron
Re: [9fans] Small GCC steps...
well, I think this will be useful. The big challenge is to get it back to the gcc core so we don't have a full port each time. ron
[9fans] Small GCC steps...
> Bootstrap complete - make "quickstrap" to redo last build, > "restage1" through "restage3" to rebuild specific stages, > or "cleanstrap" to redo the bootstrap from scratch. > # I'm hoping at least Ron will have something encouraging to say :-) It's not that I believe we ought to go this way, but I see the pragmatic value of GCC and G++. Maybe I ought to follow brucee's lead and set up a closed mailing list for interested parties? I redirect mail from unknown sources to a folder I inspect irregularly, sometimes infrequently, although many 9fans are already whitelisted. I'm not sure what the best way to get the details from me would be for anyone else. ++L PS: The next step is to try this on GCC 4.2.3 unless somebody has a better idea.
Re: [9fans] Non-stack-based calling conventions
On Fri, Feb 22, 2008 at 7:01 AM, Douglas A. Gwyn <[EMAIL PROTECTED]> wrote: > Eris Discordia wrote: > > do Plan 9 compilers output COFF object files? > > No, it has its own format. Actually Plan 9 is interesting > in that some of the work traditionally done by the compiler > was made the responsibility of the linker. > like douglas said, the linkers will do the job and output COFF for you. iru
Re: [9fans] Non-stack-based calling conventions
Lluís Batlle wrote: > Maybe someone in this list can provide a good example of coroutines use? Check out http://en.wikipedia.org/wiki/Coroutine for examples and discussion.
Re: [9fans] Non-stack-based calling conventions
Brantley Coile wrote: > ... For the Cyber 17/18 the instructions could > be pc relative and didn't have to be relocated when linked together, > at least not for the call/return scenario. Also, the 1700 linking and program loading were done at the same time, the linker had to traverse threaded references and perform relocation on those that needed it. I created a portable implementation of the linker some time ago (the assembler is on hold until my retirement). > All was much simpler than today. Although in a virtual-memory environment no relocation is needed at program load time.
Re: [9fans] ctags on plan 9 with acme-friendly tags
Steve Simon wrote: > there was somthing which analysed C and produced a call graph in the form > of input for dot(1) years ago, the problem was a complex program produced a > complex graph... I think there are quite a few programs of that kind these days; Doxygen seems to come to mind.. For C++, there are class browsers. The problem, as you noted, is that poorly structured large programs tend to produce poorly structured large call graphs. Whenever I have gotten involved with analyzing such code prior to making significant changes, I've found it easier to redesign and recode it from scratch, using the old code only for reference concerning existing data formats, etc.
Re: [9fans] Non-stack-based calling conventions
maht wrote:
> For the C version there's all sorts of pushing and popping return
> addresses and arguments on to the stack
> float
> sqr(x float)
> {
> return x * x;
> }
> float
> hyp(x float, y float)
> {
> return sqrt(sqr(x) + sqr(y));
> }
[Assuming that the code is corrected and the types made compatible
with the argument to sqrt.]
The extra overhead occurs only because of the support for full
recursion, with private instance data. Many C compilers dating
back to around 1980 will in-line the calls to sqr, so the effect is:
hyp:mul r2,r2,r2
mul r3,r3,r3
add r2,r3,r2
jmp sqrt
It's hard to imagine anything more efficient (except when hyp
itself can be in-lined.) Details of course depend on the machine
architecture and linkage convention; the above is modeled loosely
after the M*CORE, which is very nice in this respect.
Re: [9fans] Non-stack-based calling conventions
"Federico G. Benavento" wrote: > ... but who wants to be a wannabe anyways? Maybe a has-been wannabe has wanted to be?
Re: [9fans] Non-stack-based calling conventions
Anant Narayanan wrote: > Just as an observation (may not be related to the thread), all the > executable file formats that Linux currently supports, have page- > aligned sections in the file! ... > That means, all the loader really does is mmap the sections into the > right memory locations. What next, maybe also put in the BSS in the > file so you wouldn't have to allocate that either ;) Ssh, somebody may hear you and decide to do it. Conceptually it's not a bad idea, in environments where you can spare the wasted space. As I recall, using the VM system to map files in Unix goes back to 4BSD; we used to page-align buffer addresses in order to get the kernel to perform faster data transfers. > Hence, writing the loader for Plan 9's a.out proved to be a challenge. > I ended up writing a user-space program that padded out the required > gap between TEXT and DATA before asking the kernel to execute it. > Suboptimal, but it works. > If anyone has any ideas as to how I can improve the situation, i'll be > grateful. I don't understand what good it does to map Plan 9 object code into Linux files. Is there a Linux filetype for Plan 9 that invokes a system-call interpreter, or what?
Re: [9fans] Non-stack-based calling conventions
Eris Discordia wrote: > do Plan 9 compilers output COFF object files? No, it has its own format. Actually Plan 9 is interesting in that some of the work traditionally done by the compiler was made the responsibility of the linker.
Re: [9fans] Non-stack-based calling conventions
Brantley Coile wrote: > Early Control Data machines, like many machines > of the era, used the return address to find the parameters. > This meant that you put he parameters in the instruction > stream right after the call to the subroutine. > ... Yes, a lot of minicomputers did that in those days. Even on the PDP-11, which had nice support for stack operations, some system- call conventions involved embedding parameters in-line. Unix did that too, although at some point an "indirect" call was added to fetch the parameter block from a pointed-to location. If you have and CDC Cyber 18 (or 1700) system software, I am desperate to obtain a copy for use with my 1700 emulation.
Re: [9fans] GCC etc.
On Thu, 21 Feb 2008 20:54:11 +, lucio wrote: > I have made small progress getting dhog's GCC to compile itself. > Briefly, I needed a "mv" that did not barf on a "-f" option, a copy of > "head" I stole from NetBSD and a fresh version of "gmake". > > I used APE, a "mkfile" and the 3.81 sources of gmake to produce > "/386/bin/gnu/make" which is an improvement on the version in the > "gnubin" archives. > > I'm not sure whether anyone would actually want the "gmake" at this > stage, or later when the exercise is more advanced. If you do, let me > know, I'll dump it on sources. As someone who has submitted bug reports against gmake, little things like "here is a vaild makefile that causes gmake to go into an infinite loop using 100% of one CPU", I strongly suggest getting the source from CVS. I have tried to pursuade the maintainer that he should push out a new release to fix this bug, but he doesn't see it as important enough. When I first submitted the bug, with an example Makefile it was against 3.80. Then gmake just built too much. The same Makefile against 3.81 causes the loop. Pity about the lack of regression testing.
