keyring syscalls

uml-devel Michael Halcrow 4 participants 7 messages Nov 18, 2004 – Jan 25, 2005 1 message not in the archive User-mode Linux (UML)

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Blaisorblade

2004-11-18 18:33 UTC #1 lore raw

Quoted 11 lines · Michael Halcrow

Howdy folks,
I am attempting to use David Howells' new keyring in 2.6.10-rc2 UML and am getting a ``Function not implemented'' error with keyctl. I was getting that in my host kernel until I mucked with the __NR_* #define's in the userspace keyctl.c to align with the values in the 2.6.10-rc2 entry.S. I imagine that new syscalls require some magic in UML that I am unfamiliar with. I tried adding some entries to arch/um/include/sysdep-i386/syscalls.h for keyctl et. al., to no avail, but I'm kind of shooting the dark here.

Quoted 2 lines

Thanks,
Mike

Ok, please list the new syscalls - I see at least add_key() and request_key() too - are these three the only ones? I'll build the patch ASAP when getting your answer.

Signature · 14 lines

Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729



-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Michael Halcrow

author

2004-11-18 17:43 UTC #2 lore raw

Quoted 13 lines · Blaisorblade

Quoted 11 lines · Michael Halcrow
Howdy folks,
I am attempting to use David Howells' new keyring in 2.6.10-rc2 UML and am getting a ``Function not implemented'' error with keyctl. I was getting that in my host kernel until I mucked with the __NR_* #define's in the userspace keyctl.c to align with the values in the 2.6.10-rc2 entry.S. I imagine that new syscalls require some magic in UML that I am unfamiliar with. I tried adding some entries to arch/um/include/sysdep-i386/syscalls.h for keyctl et. al., to no avail, but I'm kind of shooting the dark here.

Quoted 3 lines

Ok, please list the new syscalls - I see at least add_key() and request_key() too - are these three the only ones? I'll build the patch ASAP when getting your answer.

Yes, those are the only three. Thanks!

Mike
.___________________________________________________________________.
Michael A. Halcrow
Security Software Engineer, IBM Linux Technology Center
GnuPG Fingerprint: 05B5 08A8 713A 64C1 D35D 2371 2D3C FDDA 3EB6 601D

"Never go to a doctor whose office plants have died."
- Erma Bombeck

Michael Halcrow

author

2005-01-25 21:54 UTC #3 lore raw

In reply to Blaisorblade

Quoted 4 lines · Blaisorblade

On Thursday 18 November 2004 17:09, Michael Halcrow wrote:
Ok, please list the new syscalls - I see at least add_key() and request_key() too - are these three the only ones? I'll build the patch ASAP when getting your answer.

I spent some more time today trying to implement these silly request_key, add_key, and keyctl syscalls in the 2.6.10 kernel, but I haven't had any luck. It would be a *tremendous* help for me in my filesystem development if I could just get these syscalls working in UML; it is much more tedious having to use kgdb in my debugging. I tried adding entries on to the end of the include/sysdep-i386/syscalls.h and the kernel/sys_call_table.c files. I also exported the symbols in os-Linux/user_syms.c. I am trying to work from the documentation here:

http://jdike.stearns.org/uml/arch-port.html

I am not entirely clear on the function that ``[ 222 ] = sys_ni_syscall,'' at the end of the table in syscalls.h is supposed to serve. Syscalls in UML contstitutes new territory for me.

I would assume that the __NR_* assignments in the UML environment are identical to those of the host system. That means that request_key, for example, maps to identifier 288 on the i386 architecture, right? The keyctl.c utility defines these syscall identifiers, so I need to make sure that I get the numbers right for the syscall table lookup.

Thanks,
Mike
.___________________________________________________________________.
Michael A. Halcrow
Security Software Engineer, IBM Linux Technology Center
GnuPG Fingerprint: 05B5 08A8 713A 64C1 D35D 2371 2D3C FDDA 3EB6 601D

Henrik Nordstrom

2005-01-25 22:21 UTC #4 lore raw

Quoted 3 lines · Michael Halcrow

I am not entirely clear on the function that ``[ 222 ] = sys_ni_syscall,'' at the end of the table in syscalls.h is supposed to serve.

This says that syscall number 222 is not implemented, which it isn't on i386 (not defined).

Quoted 1 line

Syscalls in UML contstitutes new territory for me.

Mostly the same as syscalls in any other architecture. A big table with function pointers to each syscall, indexed by the syscall number.

As each architecture has it's own syscall table but UML sharing the syscall numbers with the host architecture things get a little confusing sometimes. And in addition the UML syscall table often lags behind a little, missing the newer syscalls.

Note that the main syscall table is defined in arch/um/kernel/sys_call_table.c, the define in the include/asm/sysdep/syscalls.h is just the part of the syscall table which is specific to a certain host architecture.

To add a new generic syscall you should

1. Add it to asm-xxx/unistd.h of each architecture, except for um which
picks it up from the host architecture.
2. Add it to the syscall table of earch architecture, um included.

To add a new i386 only syscall you should

1. Add it to asm-i386/unistd.h
2. Add it to the i386 syscall table
3. Add it to um i386 specific syscall table in
asm-um/sysdep-i386/syscall.h

Quoted 1 line

I would assume that the __NR_* assignments in the UML environment are identical to those of the host system.

They are. UML directly includes unistd.h from the host architecture.

Quoted 2 lines

That means that request_key,
for example, maps to identifier 288 on the i386 architecture, right?

Which should have their appropriate _NR_xxx identifiers defined. For maintenance reasons the syscall table should be built using _NR_xxx identifiers, not the absolute numbers.

Regards
Henrik

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Blaisorblade

2005-01-25 22:38 UTC #5 lore raw

In reply to Michael Halcrow

Quoted 16 lines · Michael Halcrow

Quoted 4 lines · Blaisorblade
On Thursday 18 November 2004 17:09, Michael Halcrow wrote:
Ok, please list the new syscalls - I see at least add_key() and request_key() too - are these three the only ones? I'll build the patch ASAP when getting your answer.
I spent some more time today trying to implement these silly request_key, add_key, and keyctl syscalls in the 2.6.10 kernel, but I haven't had any luck. It would be a *tremendous* help for me in my filesystem development if I could just get these syscalls working in UML; it is much more tedious having to use kgdb in my debugging. I tried adding entries on to the end of the include/sysdep-i386/syscalls.h and the kernel/sys_call_table.c files. I also exported the symbols in os-Linux/user_syms.c. I am trying to work from the documentation here:

Quoted 5 lines

http://jdike.stearns.org/uml/arch-port.html
I am not entirely clear on the function that ``[ 222 ] = sys_ni_syscall,'' at the end of the table in syscalls.h is supposed to serve. Syscalls in UML contstitutes new territory for me.

Well, like

Quoted 3 lines

I would assume that the __NR_* assignments in the UML environment are identical to those of the host system. That means that request_key, for example, maps to identifier 288 on the i386 architecture, right?

Yes, because when a program says "I want to call the write() syscall", all it contains to identify the "write" syscall between all the existing ones is the __NR_write value... so it is very important that they never change (on the same architecture). As long as UML must emulate i386, the identifiers must match.

Quoted 5 lines

The keyctl.c utility defines these syscall identifiers, so I need to make sure that I get the numbers right for the syscall table lookup.
Thanks,
Mike

Well, it should be fixed in the -mm tree (and probably in 2.6.11-rc2-bk2, I guess, though it's not tested)... browse the patches at
http://user-mode-linux.sourceforge.net/patches.html.

It should be in next release...

Signature · 14 lines

Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Michael Halcrow

author

2005-01-25 22:46 UTC #6 lore raw

Quoted 5 lines · Blaisorblade

Quoted 1 line · Michael Halcrow
On Thu, Nov 18, 2004 at 06:39:26PM +0100, Blaisorblade wrote:
Well, it should be fixed in the -mm tree (and probably in 2.6.11-rc2-bk2, I guess, though it's not tested)... browse the patches at
http://user-mode-linux.sourceforge.net/patches.html.

I did notice that and tried to build it, but I had build errors. Specifically, the compiler complains that the PTRACE_SETOPTIONS symbol is undeclared in arch/um/kernel/process.c. If I include linux/ptrace.h and try again, then the new syscalls (vperfctr_*) are undeclared in arch/um/kernel/sys_call_table.c. I just gave up at that point; I'll wait for the official 2.6.11 release. In the meantime, I'll see if I can't backport the changes in the 2.6.11-rc2 patch to 2.6.10.

Blaisorblade

2005-01-25 23:02 UTC #7 lore raw

Quoted 8 lines · Michael Halcrow

Quoted 6 lines · Blaisorblade
Quoted 1 line · Michael Halcrow
On Thu, Nov 18, 2004 at 06:39:26PM +0100, Blaisorblade wrote:
Well, it should be fixed in the -mm tree (and probably in 2.6.11-rc2-bk2, I guess, though it's not tested)... browse the patches at
http://user-mode-linux.sourceforge.net/patches.html.

Quoted 5 lines

I did notice that and tried to build it, but I had build errors. Specifically, the compiler complains that the PTRACE_SETOPTIONS symbol is undeclared in arch/um/kernel/process.c. If I include linux/ptrace.h and try again, then the new syscalls (vperfctr_*) are undeclared in arch/um/kernel/sys_call_table.c.

Yes, that was fixed some patches later... Jeff added those syscalls to match -mm (since he works on that)... I made him notice and I thought I even posted a patch.

Quoted 2 lines

I just gave up at that
point; I'll wait for the official 2.6.11 release.

That *will* have to work.

Quoted 10 lines

In the meantime,
I'll see if I can't backport the changes in the 2.6.11-rc2 patch to 2.6.10.
Thanks,
Mike
.___________________________________________________________________.
Michael A. Halcrow
Security Software Engineer, IBM Linux Technology Center
GnuPG Fingerprint: 05B5 08A8 713A 64C1 D35D 2371 2D3C FDDA 3EB6 601D

Signature · 14 lines

Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel