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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 6 Jan 2015 10:30:59 -0800
From:	Greg Rose <gvrose8192@...il.com>
To:	Gleb Natapov <gleb@...udius-systems.com>
Cc:	Vlad Zolotarov <vladz@...udius-systems.com>,
	netdev@...r.kernel.org, Avi Kivity <avi@...udius-systems.com>,
	jeffrey.t.kirsher@...el.com
Subject: Re: [PATCH net-next v3 0/5]: ixgbevf: Allow querying VFs RSS
 indirection table and key

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

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