[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1395697861.2832.84.camel@deadeye.wl.decadent.org.uk>
Date: Mon, 24 Mar 2014 21:51:01 +0000
From: Ben Hutchings <ben@...adent.org.uk>
To: David Miller <davem@...emloft.net>
Cc: alon@...vatecore.com, David.Laight@...lab.com,
netdev@...r.kernel.org, grantgrundler@...il.com
Subject: Re: [PATCH 1/4 V2] Ethernet drivers in 3.14-rc3 kernel: fix 3
buffer overflows triggered by hardware devices
On Mon, 2014-03-24 at 14:35 -0400, David Miller wrote:
> From: Alon Nafta <alon@...vatecore.com>
> Date: Mon, 24 Mar 2014 10:35:37 -0700
>
> > Moreover, a system can be protected from malicious HW, and in fact
> > doesn't have to trust HW at all (except for the CPU obviously).
>
> So should we check to make sure the program counter of the cpu really
> increments to the next instruction every time?
>
> There is a limit to everything.
>
> The length field of DMA descriptors is absolutely, fully, trusted in
> the vast majority of drivers.
There is a real question as to how much peripherals should be trusted.
We already try to avoid trusting USB devices at all, because many
machines have ports that are accessible to users that shouldn't be fully
trusted. (Also, users may assume it's just as safe to plug in a 'USB
stick' they were given, as it is to insert a disc or memory card.) A
bug in the HID subsystem has apparently been exploited in the past for
code injection.
Given that some machines also have easily accessible hotplug PCI(e)
ports (CardBus, ExpressCard, Thunderbolt), and that those can be
distrusted at the hardware level (using an IOMMU), it seems like a
worthwhile goal to distrust them at the software level. However, as you
hinted, this is a big job since any vulnerable driver that's installed
can be exploited.
Ben.
--
Ben Hutchings
Everything should be made as simple as possible, but not simpler.
- Albert Einstein
Download attachment "signature.asc" of type "application/pgp-signature" (812 bytes)
Powered by blists - more mailing lists