bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Help to fix a bug on the arbiter


From: Joan Lledó
Subject: Help to fix a bug on the arbiter
Date: Fri, 10 Apr 2020 16:47:21 +0200 (CEST)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0

Hello,

I'm blocked trying to solve a bug I found in the option parsing of the
arbiter, at:

http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/pci-arbiter/options.c#n135

strtol() returns 0 if it wasn't able to convert the input, for instance,
-d jj will set h->curset->domain to 0, which means giving the permission
over the domain 0 and all it's devices. It's worst on system with no PCI
express, since the domain 0 is the only domain and therefore permission
over all devices on the system is granted.

I wrote a patch to solve it, something like:


static long int
parse_number (const char *s)
{
  long int val;
  char *endptr;

  errno = 0;
  val = strtol (s, &endptr, 16);

  if (*endptr != '\0' || errno)
    errno = EINVAL;

  return val;
}

...

case 'd':
      h->curset->domain = parse_number (arg);
      if (errno)
        PERR (errno, "Invalid domain");
      break;


Testing it with settrans works great, but when trying it with fsysopts,
the behavior is the same, h->curset->domain ends up set to 0 and
permission over all devices is granted.

In the debugger, I see that errno is correctly set to EINVAL and PERR is
called, but after that the thread continues, it reaches the case
ARGP_KEY_SUCCESS and the new permissions are applied.

Any idea on why it's this patch working fine for settrans but not for
fsysopts?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]