[Top][All Lists]

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

Re: Recent libpciaccess changes

From: Joan Lledó
Subject: Re: Recent libpciaccess changes
Date: Mon, 7 Feb 2022 23:08:55 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0


El 7/2/22 a les 11:42, Damien Zammit ha escrit:
I have not been able to prove it yet, but I think the function call
pci_device_hurd_map_range() attempts to look up _SERVERS_BUS_PCI during
bootstrap and fails because it does not exist (no root filesystem exists).

Yes, the hurd module is to be used only by nested arbiters and libpciaccess clients, and it assumes there's a fs with a master arbiter running at /servers/bus/pci

Joan, I heard we are not supposed to use the hurd access method during 
only the x86 access method.  Is this the problem, and if so, how can we fix 
How did you envisage your mapping of regions to work during bootstrap when there
is no filesystem access?

Regrettably I didn't think on that, because I'm not familiar with your work on rump (I'll watch your fosdem talk soon :)). And yes, it should use the x86 backend, but it calls pci_system_x86_create() at [1], does that call fail in your scenario? In that case it will take the hurd methods at [2] which includes the hurd_map_range() function, which needs a fs. That probably worked before my mapping implementation because there were no hurd mapping methods and the ones in the x86 module were being used in all cases.

Is there a way to detect, from the hurd_create() function, when is your scenario running? If so, the solution would be reassign pci_sys->methods->[map_range, unmap_range] back to the x86 ones in that case.

Samuel suggested on IRC that we could make it try the x86 map range function 
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.

Perhaps there is a better solution to make the access method selectable via a 
instead of implementing fallback mechanisms and making assumptions about what 
is running?
Would that work better?

In any case, we do need better testing of changes in different scenarios
to not put a burden on Samuel to fix everything we break.

How can I reproduce your scenario?

[1] https://gitlab.freedesktop.org/xorg/lib/libpciaccess/-/blob/master/src/hurd_pci.c#L619 [2] https://gitlab.freedesktop.org/xorg/lib/libpciaccess/-/blob/master/src/hurd_pci.c#L634

reply via email to

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