netdev - RE: [PATCH net-next 03/14] ice: track malicious VFs in new ice_mbx_vf

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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 14 Mar 2023 21:20:15 +0000
From:   "Keller, Jacob E" <jacob.e.keller@...el.com>
To:     Leon Romanovsky <leon@...nel.org>,
        "Nguyen, Anthony L" <anthony.l.nguyen@...el.com>
CC:     "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Michal Swiatkowski <michal.swiatkowski@...ux.intel.com>,
        "Szlosek, Marek" <marek.szlosek@...el.com>
Subject: RE: [PATCH net-next 03/14] ice: track malicious VFs in new
 ice_mbx_vf_info structure



> -----Original Message-----
> From: Leon Romanovsky <leon@...nel.org>
> Sent: Tuesday, March 14, 2023 6:44 AM
> To: Nguyen, Anthony L <anthony.l.nguyen@...el.com>
> Cc: davem@...emloft.net; kuba@...nel.org; pabeni@...hat.com;
> edumazet@...gle.com; netdev@...r.kernel.org; Keller, Jacob E
> <jacob.e.keller@...el.com>; Michal Swiatkowski
> <michal.swiatkowski@...ux.intel.com>; Szlosek, Marek
> <marek.szlosek@...el.com>
> Subject: Re: [PATCH net-next 03/14] ice: track malicious VFs in new
> ice_mbx_vf_info structure
> 
> On Mon, Mar 13, 2023 at 11:21:12AM -0700, Tony Nguyen wrote:
> > From: Jacob Keller <jacob.e.keller@...el.com>
> >
> > Currently the PF tracks malicious VFs in a malvfs bitmap which is used by
> > the ice_mbx_clear_malvf and ice_mbx_report_malvf functions. This bitmap is
> > used to ensure that we only report a VF as malicious once rather than
> > continuously spamming the event log.
> 
> I would say that idea that VF is allowed to spam PF is very questionable.
> Even with overflow logic.
> 
> Thanks

Unfortunately, there's no protection in the hardware mailbox to stop a VF from doing such spamming. The normal VF driver obviously doesn't do this, but we can't control what a VM does to its driver. This was an oversight in design that was not caught before the hardware became fixed.

Thanks,
Jake