[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6D0F6E8C3C@AcuExch.aculab.com>
Date: Tue, 25 Mar 2014 17:05:00 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Alon Nafta' <alon@...vatecore.com>
CC: Ben Hutchings <ben@...adent.org.uk>,
David Miller <davem@...emloft.net>,
netdev <netdev@...r.kernel.org>,
Grant Grundler <grantgrundler@...il.com>
Subject: RE: [PATCH 1/4 V2] Ethernet drivers in 3.14-rc3 kernel: fix 3
buffer overflows triggered by hardware devices
From: Alon Nafta
> Hi David,
>
> Are you referring to (older) systems without IOMMU? Since IOMMU and
> VT-d (for Intel) exactly solve that security problem.
Yes - I don't know the details of the x86 IOMMU.
David
> On Tue, Mar 25, 2014 at 2:37 AM, David Laight <David.Laight@...lab.com> wrote:
> > From: Alon Nafta
> >> I don't think they should be trusted at all, at least not to a point
> >> where it's feasible for them to execute code on your system.
> >> USB drivers, filesystem drivers, peripheral drivers - they're all on
> >> the same boat, obviously having different levels of severity depending
> >> on driver popularity.
> >
> > On a large number of systems any PCI or PCIe hardware has the
> > ability to read and write any system physical addresses.
> > Not only does this mean that 'dodgy' hardware can change the
> > kernel code, but also any attempt to restrict the memory that
> > the driver itself can access is likely to be circumventable.
> >
> > Yes, you can raise the barrier, but there will always be low
> > points on it.
> >
> > David
> >
> >
> >
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists