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]
Message-ID: <C5551D9AAB213A418B7FD5E4A6F30A07892F9481@ORSMSX108.amr.corp.intel.com>
Date:	Fri, 22 May 2015 15:07:33 +0000
From:	"Rose, Gregory V" <gregory.v.rose@...el.com>
To:	Hiroshi Shimamoto <h-shimamoto@...jp.nec.com>,
	"Skidmore, Donald C" <donald.c.skidmore@...el.com>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>
CC:	"nhorman@...hat.com" <nhorman@...hat.com>,
	"jogreene@...hat.com" <jogreene@...hat.com>,
	Linux Netdev List <netdev@...r.kernel.org>,
	"Choi, Sy Jong" <sy.jong.choi@...el.com>,
	Rony Efraim <ronye@...lanox.com>,
	"David Miller" <davem@...emloft.net>,
	Edward Cree <ecree@...arflare.com>,
	Or Gerlitz <gerlitz.or@...il.com>,
	"sassmann@...hat.com" <sassmann@...hat.com>
Subject: RE: [PATCH v5 3/3] ixgbe: Add new ndo to trust VF


> -----Original Message-----
> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@...ts.osuosl.org] On
> Behalf Of Hiroshi Shimamoto
> Sent: Thursday, May 21, 2015 7:31 PM
> To: Skidmore, Donald C; Kirsher, Jeffrey T; intel-wired-
> lan@...ts.osuosl.org
> Cc: nhorman@...hat.com; jogreene@...hat.com; Linux Netdev List; Choi, Sy
> Jong; Rony Efraim; David Miller; Edward Cree; Or Gerlitz;
> sassmann@...hat.com
> Subject: Re: [Intel-wired-lan] [PATCH v5 3/3] ixgbe: Add new ndo to trust
> VF
> 

[big snip]

> I think your concerns are related to some operational assumptions.
> My basic concept is, not to change the behavior of VM, existing user
> operation.
> I mean that I didn't think it's better that the user should check the both
> of the ixgbevf driver can deal with new API and the VF is trusted.
> 
> Now, I think the point is who takes care whether the VF is trusted. Right?
> It seems that you think the VF user should handle that user is trusted and
> do something with a notice that "you're trusted or untrusted" from the
> host.
> Is that correct?
> I made it in PF side, because it looks easy to handle it. If something to
> do in VF side, I think ixgbevf driver should handle it.

Setting the VF trusted mode feature should only be allowed through the PF as it is the only trusted entity from the start.  We do not want the VF being able to decide for itself to be trusted.

- Greg

> 
> thanks,
> Hiroshi
> 
> _______________________________________________
> Intel-wired-lan mailing list
> Intel-wired-lan@...ts.osuosl.org
> http://lists.osuosl.org/mailman/listinfo/intel-wired-lan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ