netdev - RE: [net-next v2 6/6] ixgbe: Add malicious driver detection support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87618083B2453E4A8714035B62D67992B3E8A975@FMSMSX105.amr.corp.intel.com>
Date:   Thu, 29 Jun 2017 21:19:58 +0000
From:   "Tantilov, Emil S" <emil.s.tantilov@...el.com>
To:     David Miller <davem@...emloft.net>,
        "gerlitz.or@...il.com" <gerlitz.or@...il.com>
CC:     "Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
        "Greenwalt, Paul" <paul.greenwalt@...el.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "nhorman@...hat.com" <nhorman@...hat.com>,
        "sassmann@...hat.com" <sassmann@...hat.com>,
        "jogreene@...hat.com" <jogreene@...hat.com>
Subject: RE: [net-next v2 6/6] ixgbe: Add malicious driver detection support

>-----Original Message-----
>From: David Miller [mailto:davem@...emloft.net]
>Sent: Thursday, June 29, 2017 11:28 AM
>To: gerlitz.or@...il.com
>Cc: Tantilov, Emil S <emil.s.tantilov@...el.com>; Kirsher, Jeffrey T
><jeffrey.t.kirsher@...el.com>; Greenwalt, Paul <paul.greenwalt@...el.com>;
>netdev@...r.kernel.org; nhorman@...hat.com; sassmann@...hat.com;
>jogreene@...hat.com
>Subject: Re: [net-next v2 6/6] ixgbe: Add malicious driver detection
>support
>
>From: Or Gerlitz <gerlitz.or@...il.com>
>Date: Wed, 28 Jun 2017 17:28:59 +0300
>
>> On Wed, Jun 28, 2017 at 1:14 AM, Tantilov, Emil S
>> <emil.s.tantilov@...el.com> wrote:
>>
>>> Mainly because I am not sure that other (non-Intel) drivers will benefit
>from
>>> such an option. In normal operation this functionality should not cause
>issues
>>> and if it doesn't we may be able to deprecate the private flag in the
>future.
>>
>> If you think this functionality makes sense any driver running over HW
>> implementing
>> it would like to be able to expose that and hence you better not use
>> private flag.

As I mentioned I don't know if this will be useful for other drivers.
The i40e driver enables it by default without possibility to disable it
and if this protection does not cause problems for ixgbe then we may not
need the option in the future. Because of this I wasn't sure if it's
worth polluting the tools with options that may end up not being 
needed/used at all.
 
>> Are we sure the trust UAPI can't be extended for that matter?
>
>Yeah, we should probably make this a generic control if possible.

MDD is set globally for the device, while the trusted option is set per VF.
So if we do end up adding an option it probably won't work as extension for
trusted.

Thanks,
Emil