Hi!
> > > Yes, it originally was designed that way, but again, the world has
> > > changed so we have to change with it. That is why USB has for a long
> > > time now, allowed you to not bind drivers to devices that you do not
> > > "trust", and that trust can be determined by userspace. That
On Wed, Jul 01, 2020 at 10:47:50AM +0200, Pavel Machek wrote:
> Hi!
>
> > > We normally trust the hardware NOT to be malicious. (Because if hacker
> > > has physical access to hardware and lot of resources, you lost).
> >
> > That is what we originally thought, however the world has changed and
Hi!
> > We normally trust the hardware NOT to be malicious. (Because if hacker
> > has physical access to hardware and lot of resources, you lost).
>
> That is what we originally thought, however the world has changed and we
> need to be better about this, now that it is trivial to create a
On Tue, Jun 30, 2020 at 11:45:59PM +0200, Pavel Machek wrote:
> Hi!
>
> > Yes such drivers should be fixed, no doubt. But without lots of
> > fuzzing (we're working on this) and testing we'd like to avoid
> > exposing that attack surface at all.
> >
> > I think your suggestion to disable driver
Hi!
> Yes such drivers should be fixed, no doubt. But without lots of
> fuzzing (we're working on this) and testing we'd like to avoid
> exposing that attack surface at all.
>
> I think your suggestion to disable driver binding once the initial
> bus/slot devices have been bound will probably
Hi!
> > > I think that's inherently platform specific to some extent. We can do
> > > it with our coreboot based firmware, but there's no guarantee other
> > > vendors will adopt the same approach. But I think at least for the
> > > ChromeOS ecosystem we can come up with something that'll work,
On Wed, Jun 10, 2020 at 12:57 PM Rajat Jain wrote:
>
> On Tue, Jun 9, 2020 at 6:34 PM Oliver O'Halloran wrote:
> >
> > On Wed, Jun 10, 2020 at 7:04 AM Bjorn Helgaas wrote:
> > >
> > > To sketch this out, my understanding of how this would work is:
> > >
> > > - Expose the PCI pdev->untrusted
On Wed, Jun 10, 2020 at 4:01 PM Bjorn Helgaas wrote:
>
> On Tue, Jun 09, 2020 at 05:30:13PM -0700, Rajat Jain wrote:
> > On Tue, Jun 9, 2020 at 5:04 PM Bjorn Helgaas wrote:
> > > On Tue, Jun 09, 2020 at 04:23:54PM -0700, Rajat Jain wrote:
> > > > Thanks for sending out the summary, I was about
On Wed, Jun 10, 2020 at 01:17:54PM -0700, Rajat Jain wrote:
> On Tue, Jun 9, 2020 at 5:30 PM Rajat Jain wrote:
> >
> > On Tue, Jun 9, 2020 at 5:04 PM Bjorn Helgaas wrote:
> > >
> > > On Tue, Jun 09, 2020 at 04:23:54PM -0700, Rajat Jain wrote:
> > > > Hi Bjorn,
> > > >
> > > > Thanks for sending
On Tue, Jun 09, 2020 at 05:30:13PM -0700, Rajat Jain wrote:
> On Tue, Jun 9, 2020 at 5:04 PM Bjorn Helgaas wrote:
> > On Tue, Jun 09, 2020 at 04:23:54PM -0700, Rajat Jain wrote:
> > > Thanks for sending out the summary, I was about to send it out but got
> > > lazy.
> > > ...
> > > The one
On Tue, Jun 9, 2020 at 5:30 PM Rajat Jain wrote:
>
> On Tue, Jun 9, 2020 at 5:04 PM Bjorn Helgaas wrote:
> >
> > On Tue, Jun 09, 2020 at 04:23:54PM -0700, Rajat Jain wrote:
> > > Hi Bjorn,
> > >
> > > Thanks for sending out the summary, I was about to send it out but got
> > > lazy.
> > >
> > >
On Tue, Jun 9, 2020 at 6:34 PM Oliver O'Halloran wrote:
>
> On Wed, Jun 10, 2020 at 7:04 AM Bjorn Helgaas wrote:
> >
> > To sketch this out, my understanding of how this would work is:
> >
> > - Expose the PCI pdev->untrusted bit in sysfs. We don't expose this
> > today, but doing so
On Tue, Jun 09, 2020 at 04:23:54PM -0700, Rajat Jain wrote:
> The one thing that still needs more thought is how about the
> "pcieport" driver that enumerates the PCI bridges. I'm unsure if it
> needs to be whitelisted for further enumeration downstream. What do
> you think?
Why not just do
On Tue, Jun 09, 2020 at 04:04:00PM -0500, Bjorn Helgaas wrote:
> On Sun, Jun 07, 2020 at 01:36:32PM +0200, Greg Kroah-Hartman wrote:
>
> > Your "problem" I think can be summed up a bit more concise:
> > - you don't trust kernel drivers to be "secure" for untrusted
> > devices
> > -
On Wed, Jun 10, 2020 at 7:04 AM Bjorn Helgaas wrote:
>
> To sketch this out, my understanding of how this would work is:
>
> - Expose the PCI pdev->untrusted bit in sysfs. We don't expose this
> today, but doing so would be trivial. I think I would prefer a
> sysfs name like
On Tue, Jun 9, 2020 at 5:04 PM Bjorn Helgaas wrote:
>
> On Tue, Jun 09, 2020 at 04:23:54PM -0700, Rajat Jain wrote:
> > Hi Bjorn,
> >
> > Thanks for sending out the summary, I was about to send it out but got lazy.
> >
> > On Tue, Jun 9, 2020 at 2:04 PM Bjorn Helgaas wrote:
> > >
> > > On Sun,
On Tue, Jun 09, 2020 at 04:23:54PM -0700, Rajat Jain wrote:
> Hi Bjorn,
>
> Thanks for sending out the summary, I was about to send it out but got lazy.
>
> On Tue, Jun 9, 2020 at 2:04 PM Bjorn Helgaas wrote:
> >
> > On Sun, Jun 07, 2020 at 01:36:32PM +0200, Greg Kroah-Hartman wrote:
> >
> > >
Hi Bjorn,
Thanks for sending out the summary, I was about to send it out but got lazy.
On Tue, Jun 9, 2020 at 2:04 PM Bjorn Helgaas wrote:
>
> On Sun, Jun 07, 2020 at 01:36:32PM +0200, Greg Kroah-Hartman wrote:
>
> > Your "problem" I think can be summed up a bit more concise:
> > - you
On Sun, Jun 07, 2020 at 01:36:32PM +0200, Greg Kroah-Hartman wrote:
> Your "problem" I think can be summed up a bit more concise:
> - you don't trust kernel drivers to be "secure" for untrusted
> devices
> - you only want to bind kernel drivers to "internal" devices
>
On Mon, Jun 08, 2020 at 11:41:19AM -0700, Rajat Jain wrote:
> Hi Jesse and Greg,
>
> On Mon, Jun 8, 2020 at 11:30 AM Jesse Barnes wrote:
> >
> > > > I think your suggestion to disable driver binding once the initial
> > > > bus/slot devices have been bound will probably work for this
> > > >
On Mon, Jun 08, 2020 at 11:29:58AM -0700, Jesse Barnes wrote:
> > Now, as to you all getting some sort of "Hardware flag" to determine
> > "inside" vs. "outside" devices, hah, good luck! It took us a long time
> > to get that for USB, and even then, BIOSes lie and get it wrong all the
> > time.
Hi Jesse and Greg,
On Mon, Jun 8, 2020 at 11:30 AM Jesse Barnes wrote:
>
> > > I think your suggestion to disable driver binding once the initial
> > > bus/slot devices have been bound will probably work for this
> > > situation. I just wanted to be clear that without some auditing,
> > >
> > I think your suggestion to disable driver binding once the initial
> > bus/slot devices have been bound will probably work for this
> > situation. I just wanted to be clear that without some auditing,
> > fuzzing, and additional testing, we simply have to assume that drivers
> > are *not*
On Mon, Jun 08, 2020 at 10:03:38AM -0700, Jesse Barnes wrote:
> > > I feel a lot of resistance to the proposal, however, I'm not hearing
> > > any realistic solutions that may help us to move forward. We want to
> > > go with a solution that is acceptable upstream as that is our mission,
> > > and
> > I feel a lot of resistance to the proposal, however, I'm not hearing
> > any realistic solutions that may help us to move forward. We want to
> > go with a solution that is acceptable upstream as that is our mission,
> > and also helps the community, however the behemoth task of "inspect
> >
On Fri, Jun 05, 2020 at 06:08:28PM -0700, Rajat Jain wrote:
> Hello Greg,
>
> Thank you for continuing to work with me through this.
>
> On Fri, Jun 5, 2020 at 1:02 AM Greg Kroah-Hartman
> wrote:
> >
> > On Thu, Jun 04, 2020 at 12:38:18PM -0700, Rajat Jain wrote:
> > > Hello,
> > >
> > > I
Hello Greg,
Thank you for continuing to work with me through this.
On Fri, Jun 5, 2020 at 1:02 AM Greg Kroah-Hartman
wrote:
>
> On Thu, Jun 04, 2020 at 12:38:18PM -0700, Rajat Jain wrote:
> > Hello,
> >
> > I spent some more thoughts into this...
> >
> > On Wed, Jun 3, 2020 at 5:16 AM Greg
On Thu, Jun 04, 2020 at 12:38:18PM -0700, Rajat Jain wrote:
> Hello,
>
> I spent some more thoughts into this...
>
> On Wed, Jun 3, 2020 at 5:16 AM Greg Kroah-Hartman
> wrote:
> >
> > On Wed, Jun 03, 2020 at 04:51:18AM -0700, Rajat Jain wrote:
> > > Hello,
> > >
> > > >
> > > > > Thanks for the
Hello,
I spent some more thoughts into this...
On Wed, Jun 3, 2020 at 5:16 AM Greg Kroah-Hartman
wrote:
>
> On Wed, Jun 03, 2020 at 04:51:18AM -0700, Rajat Jain wrote:
> > Hello,
> >
> > >
> > > > Thanks for the pointer! I'm still looking at the details yet, but a
> > > > quick look
On Wed, Jun 03, 2020 at 05:57:02AM -0700, Rajat Jain wrote:
> > So please, in summary:
> > - don't think this is some new type of thing, it's an old issue
> > transferred to yet-another-hardware-bus. Not to say this is
> > not important, just please look at the work
Hi Greg,
Thanks for looking into this thread.
On Wed, Jun 3, 2020 at 5:16 AM Greg Kroah-Hartman
wrote:
>
> On Wed, Jun 03, 2020 at 04:51:18AM -0700, Rajat Jain wrote:
> > Hello,
> >
> > >
> > > > Thanks for the pointer! I'm still looking at the details yet, but a
> > > > quick look
On Wed, Jun 03, 2020 at 04:51:18AM -0700, Rajat Jain wrote:
> Hello,
>
> >
> > > Thanks for the pointer! I'm still looking at the details yet, but a
> > > quick look (usb_dev_authorized()) seems to suggest that this API is
> > > "device based". The multiple levels of "authorized" seem to take
Hello,
>
> > Thanks for the pointer! I'm still looking at the details yet, but a
> > quick look (usb_dev_authorized()) seems to suggest that this API is
> > "device based". The multiple levels of "authorized" seem to take shape
> > from either how it is wired or from userspace choice. Once
On Wed, Jun 03, 2020 at 02:27:33AM +, Rajat Jain wrote:
> On Mon, Jun 1, 2020 at 10:06 PM Greg Kroah-Hartman
> wrote:
> >
> > On Mon, Jun 01, 2020 at 06:25:42PM -0500, Bjorn Helgaas wrote:
> > > [+cc Greg, linux-kernel for wider exposure]
> >
> > Thanks for the cc:, missed this...
> >
> > >
>
On Mon, Jun 1, 2020 at 10:06 PM Greg Kroah-Hartman
wrote:
>
> On Mon, Jun 01, 2020 at 06:25:42PM -0500, Bjorn Helgaas wrote:
> > [+cc Greg, linux-kernel for wider exposure]
>
> Thanks for the cc:, missed this...
>
> >
> > On Tue, May 26, 2020 at 09:30:08AM -0700, Rajat Jain wrote:
> > > On Thu,
On Mon, Jun 01, 2020 at 06:25:42PM -0500, Bjorn Helgaas wrote:
> [+cc Greg, linux-kernel for wider exposure]
Thanks for the cc:, missed this...
>
> On Tue, May 26, 2020 at 09:30:08AM -0700, Rajat Jain wrote:
> > On Thu, May 14, 2020 at 7:18 PM Rajat Jain wrote:
> > > On Thu, May 14, 2020 at
[+cc Greg, linux-kernel for wider exposure]
On Tue, May 26, 2020 at 09:30:08AM -0700, Rajat Jain wrote:
> On Thu, May 14, 2020 at 7:18 PM Rajat Jain wrote:
> > On Thu, May 14, 2020 at 12:13 PM Raj, Ashok wrote:
> > > On Wed, May 13, 2020 at 02:26:18PM -0700, Rajat Jain wrote:
> > > > On Wed,
37 matches
Mail list logo
