[Coco] Undocumented NitrOS9 system call (Boisy?)

Aaron Wolfe aawolfe at gmail.com
Wed Nov 4 22:32:41 EST 2015


BTW.. It looks like this call lets any user process read the contents of
any sector, so completely bypasses any filesystem permissions.. Any user
could read the contents of any file.  Not awesome from a security stance I
think.

On Wed, Nov 4, 2015, 10:27 PM Aaron Wolfe <aawolfe at gmail.com> wrote:

> In the rbf module you can see what SS.FDinf does:
>
> SSFDInf cmpb #SS.FDInf
> bne L056B
> lbsr L0D72 check for sector flush
> bcs Gst5FF
> ldb R$Y,u get MSB of sector #
> ldx R$U,u get LSW of sector #
> lbsr L0CEB read the sector
> bcs Gst5FF error, return
> ldu PD.RGS,y get register stack pointer
> ldd R$Y,u get length of data to move
> clra clear MSB
> bra L0564 move it to usr
>
> Basically just reading some bytes from the sector specified into your
> process memory, which makes sense given how the RBF file system works,
> basically a directory is just a file with the filenames and the lsn of the
> sector containing that file's descriptor.  Looks like you have the
> arguments correct to me.  Should work fine and much faster than opening
> files.
>
> On Wed, Nov 4, 2015, 9:19 PM Bill Pierce via Coco <coco at maltedmedia.com>
> wrote:
>
>> In messing with my directory read in MShell, I was looking at the NitrOS9
>> "dir" cmd to see if I could use that code to make my directory reads faster
>> by using ML code instead of C. My problem is I want to read the file
>> descriptor info for each dir entry when I read the dir (similar to "dir
>> -e").
>> I have a routine that does this, but it's so slow, I can't use it when
>> the dir is read. I use it when the user requsts file stats, then it reads
>> just that file's descriptor, but I really need them read all at once. To
>> read this info in C, inline in my program, it takes about 3 minutes on a
>> dir of 592 files (my cmds dir :-), and this is reading it into a memory
>> buffer. The nitrOS9 dir cmd scrolls the info on the screen in just a few
>> seconds, and with all the print stuff happening as well.
>> My program uses the getstat "SS.FD" call which returns the file
>> descriptor data, but to use this call, the file has to be opened. So my
>> program would have to open and close 592 files on my cmds dir to get all
>> the info in one shot.
>> In looking at the NitrOS9 dir cmd, it uses "SS.FDInfo", which according
>> to the changelog, is a new getstat that was added by Boisy in Nov of 2005.
>> I'm not sure if it was actually new, or just undocumented and never used
>> until then.
>> This call does not seem to require the file to be opened. The directory
>> itself is already open, so it seems to load each file descriptor location
>> from the tail end of the filename in the directory listing (bytes 30-32 of
>> the dir entry).
>> Now my question is... what are the calling parameters of this getstat?
>> The list in the dir cmd is:
>>
>> * Use SS.FDInf to get the file descriptor sector
>> pshs  u
>> lda   <dent+DIR.FD
>> ldb   #FD.Creat-FD.ATT
>> tfr   d,y
>> leax  <fdsect,u
>> lda   <dirpath
>> ldb   #SS.FDInf
>> ldu   <dent+DIR.FD+1
>> os9   I$GetStt
>>
>> dent is the 32 byte buffer in which the dir entry is stored. DIR.FD is
>> the last 3 bytes of this buffer (file descriptor offset). #FD.Creat-FD.ATT
>> is equivilent to 16 (size of the descriptor buffer). So from the above
>> listing, I'm assuming (after all regs are loaded) that:
>>
>> A=path
>> B=SS.FDInfo (getstat cmd)
>> Y: Y/MSB=MSB of file descriptor offset (24 bit) Y/LSB=Number of bytes to
>> retrieve
>> X=Address of destination buffer
>> U=LSW of file descriptor offset (24 bit)
>>
>> Does this seem correct to you NitrOS9 asm gurus?
>>
>>  If this is correct, I can do the equivilent in C or even asm and not
>> have to open and close every file in a dir as that's what's slowing down my
>> current method. This just seems to do direct reads from the file descriptor
>> without opening the file... correct? (Boisy maybe?)
>>
>>
>> Thanks :-)
>>
>>
>>
>> Bill Pierce
>> "Charlie stole the handle, and the train it won't stop going, no way to
>> slow down!" - Ian Anderson - Jethro Tull
>>
>>
>>
>> My Music from the Tandy/Radio Shack Color Computer 2 & 3
>> https://sites.google.com/site/dabarnstudio/
>> Co-Contributor, Co-Editor for CocoPedia
>> http://www.cocopedia.com/wiki/index.php/Main_Page
>> Global Moderator for TRS-80/Tandy Color Computer Forums
>> http://www.tandycoco.com/forum/
>>
>> E-Mail: ooogalapasooo at aol.com
>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> https://pairlist5.pair.net/mailman/listinfo/coco
>>
>


More information about the Coco mailing list