linux-kernel - Re: [PATCH 2/3] firewire-sbp2: Ignore SBP-2 targets on the local node

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: <4F365FA8.40600@bootc.net>
Date:	Sat, 11 Feb 2012 12:31:36 +0000
From:	Chris Boot <bootc@...tc.net>
To:	Clemens Ladisch <clemens@...isch.de>
CC:	Stefan Richter <stefanr@...6.in-berlin.de>,
	Greg KH <gregkh@...uxfoundation.org>,
	linux1394-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] firewire-sbp2: Ignore SBP-2 targets on the local
 node

On 11/02/2012 12:16, Clemens Ladisch wrote:
> Stefan Richter wrote:
>> On Feb 10 Chris Boot wrote:
>>> The firewire-sbp2 module tries to login to an SBP-2/3 target even when
>>> it is running on the local node, which fails because of the inability to
>>> fetch data from DMA mapped regions using firewire transactions on the
>>> local node.
>>
>> In the long run, we might want to support target and initiator set up to
>> reside on the same node and talking to each other via loopback, if
>> somebody really needs it and if it can be done with reasonably little
>> effort.
>
> Handling SBP data packets in the driver is required if we do not want to
> allow remote DMA from any device that claims to be a target.  This is
> somewhere on my todo list.

I just made it ignore it completely as it just doesn't work at all at 
the moment. If the firewire-sbp2 driver is changed so it could work in 
future, then a module option or similar sounds like a good idea.

>>> +	/* ignore targets on the local node */
>>> +	if (device->node == device->card->local_node) {
>>> +		dev_set_drvdata(&unit->device, NULL);
>>> +		return 0;
>>> +	}
>>
>> But I do wonder:  Shouldn't this be implemented by returning from the
>> driver probe method with an error?
>
> AFAIK zero means "attach", and the drvdata pointer has no meaning to the
> core.
>
>> If so, which errno should be returned?
>
> -ENODEV or -ENXIO.

Perhaps, but the meaning of those isn't quite what is happening here. We 
aren't saying the device doesn't exist or is inaccessible, just that we 
don't want to talk to it...

Chris

-- 
Chris Boot
bootc@...tc.net
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/