Hi Florian,
On Fri, 5 Jan, 2018 at 10:45 AM, Florian Weimer <fwei...@redhat.com>
wrote:
> Devices connected via Thunderbolt can be DMA masters and thus read
system memory without interference of the operating system (or even
the CPU). Version 3 of the interface provides 4 different security
levels, in order to mitigate the aforementioned security risk that
connected devices pose to the system. The security level is set by
the
system firmware.
The four security levels are:
* none: Security disabled, all devices will fully functional on
connect.
* dponly: Only pass the display-port stream through to the connected
device.
* user: Connected devices need to be manually authorized by the user.
* secure: As 'user', but also challenge the device with a secret key
to verify its identity.
Can the IOMMU help here? If it can, would it make sense to disable
all security prompts?
In theory yes, in practice it is hard to make sure it is always
properly set up (for all drivers in the mix). Also apparently "various
[other] reasons" according to the Linux kernel documentation: "There
are ways to prevent this by setting up an IOMMU but it is not always
available for various reasons."
The current design how gnome-shell and boltd work together will avoid
showing any prompts at all as long as a) the current user is an admin,
b) she is logged in and c) the session is unlocked. We hope that this
will take care of most situations where people plug in thunderbolt
devices.
Are there plans to prevent enabling devices when the shield is
active? (That's something we should do for most USB decices, too,
FWIW.)
I am not sure what you refer to with "shield" but if you mean the lock
screen, then yes indeed we wont enable devices when the session is
locked.
Cheers,
CK
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/Documentation/admin-guide/thunderbolt.rst
--
Dr. Christian J. Kellner
Desktop Hardware Enablement
Red Hat
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
