Re: Recent libpciaccess changes

[Samuel Thibault]

Joan Lledó, le lun. 07 févr. 2022 23:08:55 +0100, a ecrit:
> > Samuel suggested on IRC that we could make it try the x86 map range 
> > function first
> > and then fall back to hurd method, is there any problem with that?
> 
> I don't have the time now to study it, but I'd say that would bypass the
> protection set from the parent arbiter, since it would test the permissions
> the current user has over "mem", before testing the permissions in the file
> system created by the parent arbiter.

That is fine, since libpciaccess will notice that the user has no
permissions over "mem". That being said,

> Is there a way to detect, from the hurd_create() function, when is your
> scenario running?

> yes, it should use the x86 backend, but it calls
> pci_system_x86_create() at [1], does that call fail in your scenario?

His scenario is within the pci-arbiter, so !strcmp(netfs_server_name,
"pci-arbiter") should be properly detecting it, and thus use the x86
backend, it's not expected that it doesn't happen so. I checked the
code:

   0x0806b40c <+28>:      mov    $0x81d606c,%eax  (&netfs_server_name)
   0x0806b412 <+34>:      test   %eax,%eax
   0x0806b414 <+36>:      je     0x806b437 <pci_system_hurd_create+71>
   0x0806b416 <+38>:      mov    (%eax),%eax      (netfs_server_name)
   0x0806b418 <+40>:      test   %eax,%eax
   0x0806b41a <+42>:      je     0x806b437 <pci_system_hurd_create+71>
   0x0806b41c <+44>:      sub    $0x8,%esp
   0x0806b41f <+47>:      lea    -0x7077a(%ebx),%edx
   0x0806b425 <+53>:      push   %edx
   0x0806b426 <+54>:      push   %eax
   0x0806b427 <+55>:      call   0x8048270 (strcmp)
   0x0806b42c <+60>:      add    $0x10,%esp
   0x0806b42f <+63>:      test   %eax,%eax
   0x0806b431 <+65>:      je     0x806b568 <pci_system_hurd_create+376> 
(x86_create)
   0x0806b437 <+71>:      sub    $0x8,%esp
   0x0806b43a <+74>:      push   $0x1c
   0x0806b43c <+76>:      push   $0x1
   0x0806b43e <+78>:      call   0x80aee30 <calloc>
   [etc.]

(gdb) p &netfs_server_name
$2 = (char **) 0x81d606c <netfs_server_name>
(gdb) p netfs_server_name
$1 = 0x81650ae "pci-arbiter"

So it's properly accessing netfs_server_name.

Possibly it's actually pci_system_x86_create that fails?
Perhaps x86_enable_io()?

Putting prints would help to make sure where things start to go
unexpectedly.

Samuel