linux-kernel - Re: [PATCH v2 12/28] thunderbolt: Add functions for allocating and releasing hop IDs

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]

Date:   Sun, 10 Feb 2019 13:13:53 +0100
From:   Lukas Wunner <lukas@...ner.de>
To:     Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc:     linux-kernel@...r.kernel.org,
        Michael Jamet <michael.jamet@...el.com>,
        Yehezkel Bernat <YehezkelShB@...il.com>,
        Andreas Noever <andreas.noever@...il.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Subject: Re: [PATCH v2 12/28] thunderbolt: Add functions for allocating and
 releasing hop IDs

On Wed, Feb 06, 2019 at 04:17:22PM +0300, Mika Westerberg wrote:
> Each port has a separate path configuration space that is used for
> finding the next hop (switch) in the path. Hop ID is an index to this
> configuration space and hop IDs 0 - 7 are reserved.
> 
> In order to get next available hop ID for each direction we provide two
> pairs of helper functions that can be used to allocate and release hop
> IDs for a given port.
[...]
> +static int tb_port_alloc_hopid(struct tb_port *port, bool in, int min_hopid,
> +			       int max_hopid)
> +{
> +	int port_max_hopid;
> +	struct ida *ida;
> +
> +	if (in) {
> +		port_max_hopid = port->config.max_in_hop_id;
> +		ida = &port->in_hopids;
> +	} else {
> +		port_max_hopid = port->config.max_out_hop_id;
> +		ida = &port->out_hopids;
> +	}
> +
> +	/* Hop IDs 0-7 are reserved */
> +	if (min_hopid < 8)
> +		min_hopid = 8;
> +
> +	if (max_hopid < 0 || max_hopid > port_max_hopid)
> +		max_hopid = port_max_hopid;
> +
> +	return ida_simple_get(ida, min_hopid, max_hopid + 1, GFP_KERNEL);
> +}

If there are two Macs at the ends of the daisy-chain with Thunderbolt
devices in-between, the other Mac may already have established tunnels
to some of the devices and therefore has occupied hop entries in the
devices' path config space.  How do you ensure that you don't allocate
the same entries and overwrite the other Mac's hop entries, thereby
breaking its tunnels?  Because you're only allocating the hop entries
locally here.  Maybe there's some check in a later patch whether a
hop entry is already occupied, I'm not even halfway through this patch
bomb.

Thanks,

Lukas