netdev - Re: [PATCH net-next v3 0/5]: ixgbevf: Allow querying VFs RSS indirection table and key

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20150106184414.GC29721@cloudius-systems.com>
Date:	Tue, 6 Jan 2015 20:44:14 +0200
From:	Gleb Natapov <gleb@...udius-systems.com>
To:	Greg Rose <gvrose8192@...il.com>
Cc:	Vlad Zolotarov <vladz@...udius-systems.com>,
	netdev@...r.kernel.org, Avi Kivity <avi@...udius-systems.com>,
	jeffrey.t.kirsher@...el.com, davem@...emloft.net
Subject: Re: [PATCH net-next v3 0/5]: ixgbevf: Allow querying VFs RSS
 indirection table and key

On Tue, Jan 06, 2015 at 10:30:59AM -0800, Greg Rose wrote:
> On Tue, Jan 6, 2015 at 10:04 AM, Gleb Natapov <gleb@...udius-systems.com> wrote:
> > On Tue, Jan 06, 2015 at 08:59:41AM -0800, Greg Rose wrote:
> >> On Tue, Jan 6, 2015 at 2:58 AM, Vlad Zolotarov
> >> <vladz@...udius-systems.com> wrote:
> >> >
> >> >
> >> > I agree with Gleb here: when we started with just thinking about the idea of
> >> > this patch the possible security issue was the first thing that came into
> >> > our minds.
> >> > But eventually we couldn't come up with any security risk or attack example
> >> > that is exclusively caused by the fact that VF knows the indirection table
> >> > and/or RSS hash key of the PF.
> >> >
> >> > So, Greg, if we have missed anything and your have such an example could you
> >> > share it here, please?
> >>
> >> I don't have any examples and that is not my area of expertise.  But
> >> just because we can't think of a security risk or attack example
> >> doesn't mean there isn't one.
> >>
> > Is RSS hash security feature at all? Against what kind of attack? It
> > looks like some drivers (igb among them) use non random value for the key.
> 
> I don't believe RSS hashing itself is a security feature - I don't
> know that sharing the RSS info with a VF is a security risk.  I'm just
> asking that we preserve default behavior to avoid the possibility.
> 
> >
> >> Just add a policy hook so that the system admin can decide whether
> >> this information should be shared with the VFs and then we're covered
> >> for cases of both known and unknown exploits, risks, etc.
> >>
> > Default off means that it will stay that way for most installations and
> > information will not be available for "cloud" users. It is hard to get
> > proper support on public cloud for less trivial issues than changing
> > host HW configuration.
> 
> Someone in the host is configuring the VF HW to begin with.  Someone
> had to create the VFs in the first place so I presume they could set
> the policy for this feature as well at the same time.  To return to an
> example I provided to Vlad - anti-spoof checking is on by default but
> we allow system admins to turn it off so that other features, such as
> bonding, can be used.  I just want to preserve current behavior while
> allowing the feature you want to add to be available for those who
> want it.
> 
> If Dave and the rest of community feel that there is no risk to these
> patches and that they should be applied then I'll go away and shut up
> about it.  But for now I'm just approaching this from a "better safe
> than sorry" viewpoint.
> 
Thanks Greg for explaining your position clearly on this matter. I CCed
Dave to get his opinion. Vlad is going to work on adding this knob
anyway meanwhile, but we still have a hope that default could be "on".

--
			Gleb.
--
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