Hi, On 10/1/19 5:34 PM, Jan Kiszka wrote: > On 01.10.19 17:23, Ralf Ramsauer wrote: >> Hi Jan, >> >> On 9/30/19 9:28 PM, Jan Kiszka wrote: >>> On 30.09.19 21:25, Andrej Utz wrote: >>>> Hi Jan, >>>> >>>> On 30.09.19 21:19, Jan Kiszka wrote: >>>>> On 30.09.19 21:13, Andrej Utz wrote: >>>>>> This patch series eases configuration of port I/O devices for x86 >>>>>> plattforms by generating an initial PIO region list. To sustain >>>>>> previous >>>>>> behavior, most entries are disabled (commented out). Only whitelisted >>>>>> device ports are allowed. This includes the peripheral PCI port >>>>>> space. >>>>> >>>>> Did you also try what explodes when enforcing the generated list? I >>>>> mean, if there is no mess like with hidden memory regions, things >>>>> just Just Work (TM). >>>> >>>> Not yet. Analysis of additional whitelist candidates shall follow. >>> >>> We probably need a mixture: white-listing know-harmless thing that are >>> requested in the legacy range, combined with permitting the PCI >>> device-related regions. >> >> Ack. With a little luck we can rely on entries in /proc/ioports, at >> least for PCI ports above 0xd00. >> >> I just compared lspci vs. ioports on some machines: Looks like ioports >> contains everything that can be found in PCI config space. But ioports >> contains even more. >> >> What are those pnp entries good for? E.g.: >> f800-f87f : pnp 00:01 >> f880-f8ff : pnp 00:01 >> [...] >> >> Are these reserved areas for PCI devices? > > pnp, ACPI, some further platform resources.
Will the root cell touch those ports? So far, it looks like it doesn't. > >> >> And on my laptop, I can also find ACPI stuff above 0xd00: >> >> 0d00-ffff : PCI Bus 0000:00 >> 1640-164f : pnp 00:01 >> 1800-187f : pnp 00:01 >> 1800-1803 : ACPI PM1a_EVT_BLK >> 1804-1805 : ACPI PM1a_CNT_BLK >> 1808-180b : ACPI PM_TMR >> 1820-182f : ACPI GPE0_BLK >> 1850-1850 : ACPI PM2_CNT_BLK >> >> How should we deal with that? > > PM_TMR is passed through anyway, at least to non-root cells. The rest is > more dangerous, potentially. But a "works by default" setting may have > to include them. > >> >> And what about VGA? We whitelist 0x3b0-0x3df on any machine. Shouldn't >> VGA be listed in ioports if present? At least for qemu that's the case. >> If we can rely on that, then we wouldn't even have to whitelist VGA. [1] > > Yes. VGA, if it shall be with the root cell (common case), should be > listed. Alright. So here you can find a WIP version of this series that comes with support for selective whitelisting PCI devices: https://github.com/lfd/jailhouse/tree/ioports-ralf-v2 So far, I successfully tested this approach on Qemu and on a real machine. No crashes so far. (which I didn't expect, to be honest ;-) ) Jan, could you please test this approach? Just run it on your local machine, look at the output, and compare it with /proc/ioports. If this is the way to go, I'll make a clean series out of it. The head commit is probably the most interesting one. Thanks Ralf > >> >> Besides that, we could enrich PIO ranges with a comment that links them >> to their corresponding BDF, just like we do for memory regions. > > Ack. > >> >> In any case, platform specific stuff will remain static. >> > > Yes, and we may see more failure there when we start to restrict the > access. > > Jan > -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/48835bb9-5fe5-852b-e538-00c7b6fb6498%40oth-regensburg.de.
