[bug #48890] mach-defpager isn't properly marked important

[Brent Baccala]

Follow-up Comment #2, bug #48890 (project hurd):

I tried again with the mach-defpager from savannah's git tree and it worked
correctly.  Looks like a problem with the Debian package.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: exec server behavior

[Richard Braun]

On Thu, Aug 25, 2016 at 12:20:45PM +0200, Richard Braun wrote:
> I started thinking about these only a couple of weeks ago, and so far
> the only solutions my limited brain can come up with is to either use
> the client context (by perhaps passing its root) but that could cause
> security issues, or have a third-party like auth (or proc or whatever)
> store enough of this context that the server can use it.

Of course the problem with these approaches is making sure the user
context can be trusted by the server, something that other systems such
as Plan9 don't have to deal with, allowing them to implement solutions
like the factotum.

-- 
Richard Braun

Re: RFC: Lightweight synchronization mechanism for gnumach v3

[Samuel Thibault]

Hello,

We have an issue with the kernel implementation :)

When lock debugging is enabled (MACH_LDEBUG set to 1 in configfrag.ac),
simple_lock uses _simple_lock to check using simple locks correctly.

It happens that vm_map_lock_read, i.e. lock_read, calls
check_simple_locks(): no simple lock is supposed to be taken.

So vm_map_lock_read can't come after simple_lock (>lock).

It seems we could just invert the locking, could you check on that?

Samuel

Re: exec server behavior

[Richard Braun]

On Wed, Aug 24, 2016 at 07:24:16PM -1000, Brent W. Baccala wrote:
> So, I'll modify libpager to handle multiple clients.  Not trivial, but it
> seems necessary and correct.

Don't start that immediately, wait for more discussions. I'm not so
sure it would make sense to support more than one client.

> One question is whether the exec server really needs to do a vm_map to
> examine an ELF header.  A simple read would suffice.  Which should be
> preferred?

I agree that read should be preferred. In a completely separate
non-existent issue, it would be the only way to support nommu systems.

> A more serious question is why the exec server is running on the server
> side at all.  Shouldn't it be running on the client?  Then the only network
> operation it would need is to map the one file that it's trying to execute.
> 
> Examining diskfs_S_file_exec reveals some interesting behavior.  The file
> server caches a port to its exec server, so the same exec server gets used
> by all of its clients!  Furthermore, it gets the exec server in the first
> place by looking up _SERVERS_EXEC in its own name space, not the client's!
> 
> Shouldn't the exec server be looked for in the client's name space?

You're getting into the same kind of "light virtualization" issues we
have with e.g. chroot. Many operations are done by servers, from their
execution context, and this breaks that kind of behaviour.

I started thinking about these only a couple of weeks ago, and so far
the only solutions my limited brain can come up with is to either use
the client context (by perhaps passing its root) but that could cause
security issues, or have a third-party like auth (or proc or whatever)
store enough of this context that the server can use it.

-- 
Richard Braun

[bug #48890] mach-defpager isn't properly marked important

[Samuel Thibault]

Follow-up Comment #1, bug #48890 (project hurd):

As reported by Svante Signell:

“
On one of my KVM boxes:
ps e | grep mach-defpager
root11  - Ssfo  0:00.03 /hurd/mach-defpager

cut -d ' ' -f 26,27 /proc/11/stat
0 0
”

Happens to me too on all the systems I have access to.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: [bug #48890] mach-defpager isn't properly marked important

[Svante Signell]

On Thu, 2016-08-25 at 01:10 +, Brent Baccala wrote:
> URL:
>   
> 
>  Summary: mach-defpager isn't properly marked
> important
> 

> 'important' processes report their startcode and endcode fields as 0
> in their
> /proc/PID/stat files.
> 
> mach-defpager isn't properly flagging, as can be easily verified:
> 
> 
> ps e | grep mach-defpager
> 
> cut -d ' ' -f 26,27 /proc/11/stat

On one of my KVM boxes:
ps e | grep mach-defpager
root11  - Ssfo  0:00.03 /hurd/mach-defpager

cut -d ' ' -f 26,27 /proc/11/stat
0 0