Libtool in a Alias episode

Gary reports that libtool was shown in an Alias episode.. Thats nice.. :) [Report]

Also, when searching for the file bt_curadj on google, it seems to be that of MySQL. So, the guys at Alias were using MySQL as their Echelon system. Cool..




transcripts from #hurd

These are transcripts from #hurd. This is here as I badly wanted to keep these notes., just in case i might need them. I should have put them into planner.. but could not reach the college servers. Once I reach them., I'll put these there...

Genereal KIP doubts:

The kernel interface page.. is that page modifiable from userspace?
c0le: nope. it's r-o
c0le: in fact, it's the very same frame mapped into every address space
marcus: ah.. well, then what use is it?? I mean., is that only to give your some info?? to save some syscalls to get the info?
c0le: it is that, but more
c0le: by having read only syscall stubs in the kip, you can do things like roll back or forward
c0le: you can execute kernel code in user space, without even entering the kernel
c0le: and the kernel can trust that code. ie, it can check the address to find out what is going on
that means., kernel authentic code.. right in user space.
and user code cannot modify it.
they have both, int based and sysenter/sysexit
you can switch with a compile time option
c0le: the KIP provides entry points for the system call
ah., ok. so for sysenter you just take those values and call the code.
how beneficial would it be to make some parameters of the KIP modifyable at userspace.. without calling a syscall..
there is nothing in it you want the user to modify
c0le: maybe you are looking for the utcb
that exists as well :)
utcb? i've no clue about that.
c0le: the kernel maps a small piece of data into an address space for every thread running in it - the user thread control block
c0le: that one is 512 bytes on ia32 per thread, and basically provides a shitload of virtual registers
so that is something you can usually modify, to get certain effects
effects which are local to the address space..
c0le: sure. actually, local to the thread
c0le: for example, you can do user-level thread switches this wau
hmm.. by changing some priority/ state parameter in the utcb?
well, you can get the stack pointer of the other thread in its utcb, then, for example
and perform a lazy context switch

Thread creation, and the hurd tasks, posix processes.:

well, i've another doubt. when a thread is being created.. you first obtain a address space., and then schedule it? or ?? how is it done?
creating a thread is just allocating a stack, and jumping on it in another execution context
who does the allocation? the L4?
c0le: you create a thread in a new address space. you configure the space. you activate the thread
c0le: address spaces in L4 are only created implicitely, and named via the thread id
c0le: so you create a new address space by creating a new thread, and assigning it to its own address space (space specifier == new thread id)
c0le: allocation of thread ids is completely up to you
c0le: then, for a new address space, the new thread is obviously inactive. you need to follow up with a space control system call, configuring the new space
c0le: you set the various parameters, including the area in which the kip is mapped, and the area into which utcbs are mapped
c0le: then you can activate the new thread for the first time, by assigning it a piece of the utcb area and some other stuff
c0le: the new thread will immediately page fault, obviously, as there are no mappings
c0le: page faults are implemented by changing the thread to make it appear as if it had sent a message to its pager thread
c0le: and the pager thread can install a mapping, and return it, or whatever
c0le: of course, for a completely new address space, the first thread must make an ipc to an external pager to allow it to actually run
c0le: so, you have to expect to receive a page fault message and reply to it with an fpage that you want to map or grant to the new space
from that point on, the new thread can run for the first time
hmm.. so this space specifier is what that is given as a task in the user manual?
c0le: I don't have the user manual in front of me, but you can say task instead of address space if you want, and it still makes sense
c0le: the L4.X2 spec doesn't mention the word task a single time, I think
a task only exists implicitely
you can name a task by any of the threads in it
consequently, when you destroy the last thread in a space, the whole space is destroyed
so., a pager for a thread is assigned at the time of the configuration of the utcb?? or the first thread for an address space?
c0le: it's part of the ThreadControl call
c0le: you set it at time of activation
c0le: in fact, you can change it at any time
c0le: the thread itself can change its pager at any time
c0le: it's part of the utcb, and defined as a r/w field
c0le: another local thread can also change it with the ExRegs call
hmm.. so the utcb is created by the kernel..??
yes, the utcb is kernel memory
it must be, because the kernel accesses it
ah.. ok., I get it. but some areas of it are user space modifyable?
well, as the utcb is normally smaller than a page, all areas are actually writeable
marcus: In hurd/startup.h:struct hurd_startup_data, you say of the task field (of type struct hurd_startup_cap): The task that is being started.
c0le: but nothing you can write to it can compromise security
but isn't that the task server?
c0le: you may mess up your own state seriously by writing to fields that are declared read only, though
hmm.. yeah., that is not a security problem.. i understand that.
a program misbehaves it ought to crash.
neal: It's the capability for the task being started
neal: ie, the cap identifies this task in the task server
neal and of course the server component of that cap is the task server
so the clan chief is the task server?
beside, clans and chiefs model has been dropped from L4.X2
so it is the task cap for itself?
neal you got it!
ok., i got a lil bit confused.. now., who creates the first task? the sigma0 ?
c0le: the kernel creates sigma0 and the rootserver
c0le: the first task must be loaded by the bootloader, and its information (physical memory, etc) is in the KIP.
c0le: the bootloader puts it into the KIP of the kernel image
c0le: there the kernel looks it up, and creates an address space from it and a thread, and runs it at the designated EIP
ok., so this address space goes about creating more address spaces for other servers?
c0le: if you want it to, sure. it's something you write.
c0le: the rootserver is the first part of your own OS
c0le: our rootserver creates new tasks for physmem, task and deva, our physical memory, task and device servers
c0le: and some stuff more

HURD task IDs and Posix process IDs.

here.. task implies address spaces?
or threads within a address space?
c0le: our task server associates a lot of info with a task
more than L4, less than POSIX
does the hurd maintain a process id different from the L4 task ids or address space specifier.. ???
i mean the task server of the hurd.
c0le: L4 doesn't have task ids
c0le: the task server indeed maintains task ids
c0le: but they are not like PIDs
c0le: we have a proc server to manage PIDs and the task id <-> PID mapping
ah. i get it.
and l4 identifies each running instance by its thread id?
well, yes
if you want to name a space in L4, you just name a thread in the space
it's implicit
as I said earlier
ok.. so there is two level mapping?? i mean., threadid to task id., which is in turn mapped into a process id..???
c0le: well, yes
c0le: except that the mapping thread id to task id is simple for us, as we encode the task id into the thread id (in the lower bits of the version id)
and this task id is maintained inside the hurd just to make the rest of hurd seem like it is running on a mach instead of a l4
mach doesn't even enter the picture
c0le: clearly _something_ must manage the thread ids
aw.. then why this task id? in the middle..
marcus: yes., i understand that. but why need a task id? we might as well, map thread ids directly to process ids?? well.. am i missing osmething??
c0le: well, the reason is that posix PIDs come with very specific semantics, which we don't want to be bound to
c0le: for example, POSIX says that if you do an exec(), the PID doesn't change
c0le: but it's much simpler to implement exec() by just creating a new task (== new task id), and then let that task steal over the process id of the old task
c0le: so, there is a separation of concepts
Yeah., i understand that.. but instead of creating a new task (which is not known to the l4) why not create a thread., and manage a mapping of thread ids to a respective process id?
c0le: oh, you mean why have task ids at all?
c0le: well, we want task-based protection
c0le: in particular in the IPC system
exactly., thats what i was asking.. why have task ids at all..
c0le: so, we use the task id of a thread to figure out if the sender is allowed to send a message or not. we don't control this at a per-thread level
ah.. so that a task is a abstraction of a group of threads..
c0le: yes