Re: procfs

[olafBuddenhagen]

Hi,

On Thu, Dec 31, 2009 at 09:22:40AM +0530, Shakthi Kannan wrote:

>   # mkdir /proc # settrans -fgap /proc procfs

This is actually buggy: the relative path will work on the original
instance, but not when it is restarted from the passive translator
setting...

Just use

   settrans -c /proc /path/to/procfs

-c means the node will be automatically created. -fg is not needed, if
there was no translator on this node before. -p is the default, and the
active translator will be started automatically on first access, so no
-ap is necessary either.

Please try to actually understand the options of the settrans command,
rather than issuing some memorized string -- it's quite important to
understand them if you want to work effectively with the Hurd :-)

-antrik-

Re: cannot boot subhurd

[olafBuddenhagen]

Hi,

On Sat, Jan 02, 2010 at 12:54:33PM +0800, Da Zheng wrote:
> On 09-12-31 ??11:04, olafbuddenha...@gmx.net wrote:

> >> But it always worked before. I can also mount /dev/hd1 to my file
> >> system. 'settrans -a subhurd /hurd/ext2fs /dev/hd1' works on my
> >> system.
> > 
> > Have you put a filesystem on /dev/hd1 without partitioning it?
> > That's certainly unusual... But if it is so, I guess that's not the
> > reason for the failure.

> I have used fdisk to create only one partition on that disk.

But then you still have a boot sector and probably a few empty sectors
before the start of the actual partition -- I don't see how ext2fs could
ever have mounted this...

Unless you actually did "mke2fs /dev/hd1" after partitioning -- which
*overwrote* the partition table you created with fdisk, and instead put
the filesystem directly on the unpartitioned disk.

> I tried to create /dev/hd1s1, but it doesn't work.

Err... What do you mean? You can't mke2fs /dev/hd1s1? Well, if indeed
you overwrote the partition table as described above, that's no wonder
:-)

> I finally got a working subhurd

Let us know what the problem was, and how you got around it :-)

> and I tested my modified subhurd with samuel's patch to auth. It seems
> working. I run subhurd for so many times, but didn't see subhurd hang
> in login.

That's great news! :-)

> But it does hang somewhere else. Maybe there are some other bugs in
> subhurd.

I see... Still, progress.

> I wonder if it's because the proc server in subhurd cannot run in a
> higher priority.

Doesn't seem too likely to me... If some protocol relies on proc being
scheduled before other processes, that would be *extremely* fragile.

Of course you could still test what happens if you set the higher
priority with some backdoor or a debugger or something. Perhaps the
lower priority indeed uncovers some kind of race condition... Though I
must say that other race conditions (like the auth one) seem more
likely.

-antrik-

Re: [bug #28446] No checks are made for unteminated strings in RPC messages

[olafBuddenhagen]

Hi,

On Fri, Jan 01, 2010 at 10:36:35PM +0100, Carl Fredrik Hammar wrote:
> On Thu, Dec 31, 2009 at 04:12:21AM +0100, olafbuddenha...@gmx.net wrote:
> > On Wed, Dec 30, 2009 at 07:42:21PM +, Carl Fredrik Hammar wrote:

> > > Strings in RPCs, such as the filename argument to a dir_lookup, are
> > > not checked if they are terminated by '\0'.  This could lead to the
> > > server segfaulting if it tries to read the string.
> > > 
> > > Making MIG check that strings are terminated seems like the proper
> > > fix.
> > 
> > AIUI, the first step would be implementing actual string support in MiG
> > at all...
> 
> MIG seems to already have some awareness of strings, atleast the client
> part uses a variant of strncpy() to copy the string into the message.

Could you please elaborate what code you are referring to exactly?

> It is hard to be certain that a translator isn't vounerable unless it
> has an explicit check, which I expect no translator currently have.
> For instance, I extfs returns ENAMETOOLONG because it I tested with a
> single component path, but it might be possible to get it to read past
> the end using many components, e.g. `././././', though I suspect
> this will return ELOOP.
> 
> Fixing MIG seems much easier and safer.

Yes -- but also more invasive... You'll have to find someone confident
enough to ack/commit the change :-)

If the change doesn't get commited for whatever reason, it would still
be nice to have (non-disputable) patches for the actual bugs...

-antrik-

Re: [bug #28446] No checks are made for unteminated strings in RPC messages

[Carl Fredrik Hammar]

Hi,

On Sat, Jan 02, 2010 at 08:12:17AM +0100, olafbuddenha...@gmx.net wrote:
> On Fri, Jan 01, 2010 at 10:36:35PM +0100, Carl Fredrik Hammar wrote:
> > On Thu, Dec 31, 2009 at 04:12:21AM +0100, olafbuddenha...@gmx.net wrote:
> > > On Wed, Dec 30, 2009 at 07:42:21PM +, Carl Fredrik Hammar wrote:
> 
> > > > Strings in RPCs, such as the filename argument to a dir_lookup, are
> > > > not checked if they are terminated by '\0'.  This could lead to the
> > > > server segfaulting if it tries to read the string.
> > > > 
> > > > Making MIG check that strings are terminated seems like the proper
> > > > fix.
> > > 
> > > AIUI, the first step would be implementing actual string support in MiG
> > > at all...
> > 
> > MIG seems to already have some awareness of strings, atleast the client
> > part uses a variant of strncpy() to copy the string into the message.
> 
> Could you please elaborate what code you are referring to exactly?

I was talking about the code generated for clients that copies a string
argument into messages to be sent to the client.  Sorry, I wrote this
in a bit of a hurry only using observations I had already made.

MIG does have a c_string type after all, which is used to define the
string_t type used in the Hurd.  Which explains how it can generate code
specific to strings.

> > It is hard to be certain that a translator isn't vounerable unless it
> > has an explicit check, which I expect no translator currently have.
> > For instance, I extfs returns ENAMETOOLONG because it I tested with a
> > single component path, but it might be possible to get it to read past
> > the end using many components, e.g. `././././', though I suspect
> > this will return ELOOP.
> > 
> > Fixing MIG seems much easier and safer.
> 
> Yes -- but also more invasive... You'll have to find someone confident
> enough to ack/commit the change :-)
> 
> If the change doesn't get commited for whatever reason, it would still
> be nice to have (non-disputable) patches for the actual bugs...

I haven't looked yet, but I can't imagine it being less invasive than
adding checks in *every* single program that receives strings in messages.
I didn't consider it before but this would also affect clients that gets
strings in the reply.

Regards,
  Fredrik

Re: cannot boot subhurd

[Da Zheng]

Hi,

On 10-1-2 下午3:06, olafbuddenha...@gmx.net wrote:
> But then you still have a boot sector and probably a few empty sectors
> before the start of the actual partition -- I don't see how ext2fs could
> ever have mounted this...
> 
> Unless you actually did "mke2fs /dev/hd1" after partitioning -- which
> *overwrote* the partition table you created with fdisk, and instead put
> the filesystem directly on the unpartitioned disk.
> 
>> I tried to create /dev/hd1s1, but it doesn't work.
> 
> Err... What do you mean? You can't mke2fs /dev/hd1s1? Well, if indeed
> you overwrote the partition table as described above, that's no wonder
> :-)
Yes, I did "mke2fs /dev/hd1". After partitioning, I tried to create hd1s1 device
file with MAKEDEV, but got the error "Unknown code P 6 while trying to determine
filesystem size" after I ran "mke2fs /dev/hd1s1".

In fdisk, I printed the information of all partitions, and see the device name
is called hd1p1, but I couldn't create a device file called hd1p1 with MAKEDEV.
> 
>> I finally got a working subhurd
> 
> Let us know what the problem was, and how you got around it :-)
I simply created another disk and copied all files in the main Hurd to that disk
with a little adjustment (I created device files and servers manually). It works
pretty well now.

I tried crosshurd. It doesn't work. Anyone maintains crosshurd?
>> I wonder if it's because the proc server in subhurd cannot run in a
>> higher priority.
> 
> Doesn't seem too likely to me... If some protocol relies on proc being
> scheduled before other processes, that would be *extremely* fragile.
> 
> Of course you could still test what happens if you set the higher
> priority with some backdoor or a debugger or something. Perhaps the
> lower priority indeed uncovers some kind of race condition... Though I
> must say that other race conditions (like the auth one) seem more
> likely.
I agree that lower priority isn't the direct cause of hangs, but if raising the
priority can solve the problem, we should do it.

Zheng Da

Re: cannot boot subhurd

[Michael Banck]

On Sat, Jan 02, 2010 at 10:46:20PM +0800, Da Zheng wrote:
> I tried crosshurd. It doesn't work. Anyone maintains crosshurd?

Yes.

Michael

Re: FOSDEM 2010

[Michael Banck]

On Thu, Dec 31, 2009 at 04:37:12AM +0100, olafbuddenha...@gmx.net wrote:
> Hi,
> 
> On Tue, Dec 22, 2009 at 10:01:41AM +0100, Thomas Schwinge wrote:
> 
> > FOSDEM 2010 is slowly approaching.
> > 
> > A few Hurd types have shown interest in meeting there, so I created
> > 
> > for coordination.  Beware that web-editing (and the whole of bddebian
> > HTTP) is still down due to this Perl crash I (or someone else, of
> > course) needs to have a look at.  But you can either use the Git
> > interface, cf.
> > , for
> > doing any changes, or tell me by email or on IRC (tschwinge on
> > freenode.net).
> 
> As the wiki is kinda-working again now, I think it's right to use
> http://www.bddebian.com/~hurd-web/community/meetings/fosdem_2010/ ?
> 
> Also, I think it would be good to mention that there will be an alt-os
> devroom, where we will surely hang out -- and hopefully could give a
> talk or two as well...

The submission deadline for the alt-os devroom has been extended till
the end of January 4th:

http://groups.google.com/group/rosetta-os/browse_thread/thread/16964e21bef27116

Francois Revol (the chairmain of the devroom) turned up in #hurd today
and requested submissions:

 I'd really like to see a Hurd demo :)

His email address is re...@free.fr.


Michael

Re: cannot boot subhurd

[Samuel Thibault]

Da Zheng, le Sat 02 Jan 2010 22:46:20 +0800, a écrit :
> Yes, I did "mke2fs /dev/hd1". After partitioning, I tried to create hd1s1 
> device
> file with MAKEDEV, but got the error "Unknown code P 6 while trying to 
> determine
> filesystem size" after I ran "mke2fs /dev/hd1s1".

Did you restart the kernel so it sees the new partition table?

Samuel

Re: cannot boot subhurd

[Da Zheng]

On 10-1-3 上午3:40, Samuel Thibault wrote:
> Da Zheng, le Sat 02 Jan 2010 22:46:20 +0800, a écrit :
>> Yes, I did "mke2fs /dev/hd1". After partitioning, I tried to create hd1s1 
>> device
>> file with MAKEDEV, but got the error "Unknown code P 6 while trying to 
>> determine
>> filesystem size" after I ran "mke2fs /dev/hd1s1".
> 
> Did you restart the kernel so it sees the new partition table?
> 
No, I didn't. The new partition isn't in the disk where Hurd runs. Do I still
need to restart the kernel?

Zheng Da