On 6/3/21 4:32 PM, Andi Kleen wrote:
>
>> We do not need an increasing pile of kludges
>
> Do you mean disabling features is a kludge?
>
> If yes I disagree with that characterization.
>
>
>> to make TDX and SEV “secure”. We need the actual loaded driver to be
>> secure. The virtio architecture is full of legacy nonsense,
>> and there is no good reason for SEV and TDX to be a giant special case.
>
> I don't know where you see a "giant special case". Except for the
> limited feature negotiation all the changes are common, and the
> disabling of features (which is not new BTW, but already done e.g. with
> forcing DMA API in some cases) can be of course used by all these other
> technologies too. But it just cannot be done by default for everything
> because it would break compatibility. So every technology with such
> requirements has to explicitly opt-in.
>
>
>>
>> As I said before, real PCIe (Thunderbolt/USB-C or anything else) has
>> the exact same problem. The fact that TDX has encrypted memory is, at
>> best, a poor proxy for the actual condition. The actual condition is
>> that the host does not trust the device to implement the virtio
>> protocol correctly.
>
> Right they can do similar limitations of feature sets. But again it
> cannot be default.
Let me try again.
For most Linux drivers, a report that a misbehaving device can corrupt
host memory is a bug, not a feature. If a USB device can corrupt kernel
memory, that's a serious bug. If a USB-C device can corrupt kernel
memory, that's also a serious bug, although, sadly, we probably have
lots of these bugs. If a Firewire device can corrupt kernel memory,
news at 11. If a Bluetooth or WiFi peer can corrupt kernel memory,
people write sonnets about it and give it clever names. Why is virtio
special?
If, for some reason, the virtio driver cannot be fixed so that it is
secure and compatible [1], then I think that the limited cases that are
secure should be accessible to anyone, with or without TDX. Have a
virtio.secure_mode module option or a udev-controllable parameter or an
alternative driver name or *something*. An alternative driver name
would allow userspace to prevent the insecure mode from auto-binding to
devices. And make whatever system configures encrypted guests for
security use this mode. (Linux is not going to be magically secure just
by booting it in TDX. There's a whole process of unsealing or remote
attestation, something needs to prevent the hypervisor from connecting a
virtual keyboard and typing init=/bin/bash, something needs to provision
an SSH key, etc.)
In my opinion, it is not so great to identify bugs in the driver and
then say that they're only being fixed for TDX and SEV.
Keep in mind that, as I understand it, there is nothing virt specific
about virtio. There are real physical devices that speak virtio.
[1] The DMA quirk is nasty. Fortunately, it's the only case I'm aware
of in which the virtio driver genuinely cannot be made secure and
compatible at the smae time. Also, fortunately, most real deployments
except on powerpc work just fine with the DMA quirk unquirked.
>
>
>>
>>>
>>> TDX and SEV use the arch hook to enforce DMA API, so that part is also
>>> solved.
>>>
>> Can you point me to the code you’re referring to?
>
> See 4/8 in this patch kit. It uses an existing hook which is already
> used in tree by s390.
This one:
int arch_has_restricted_virtio_memory_access(void)
+{
+ return is_tdx_guest();
+}
I'm looking at a fairly recent kernel, and I don't see anything for s390
wired up in vring_use_dma_api.
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
