Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932648AbWJLPqf (ORCPT ); Thu, 12 Oct 2006 11:46:35 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932649AbWJLPqe (ORCPT ); Thu, 12 Oct 2006 11:46:34 -0400 Received: from mx2.netapp.com ([216.240.18.37]:61998 "EHLO mx2.netapp.com") by vger.kernel.org with ESMTP id S932648AbWJLPqd (ORCPT ); Thu, 12 Oct 2006 11:46:33 -0400 X-IronPort-AV: i="4.09,301,1157353200"; d="scan'208"; a="417397017:sNHT22545784" Subject: Re: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic From: Trond Myklebust To: Alan Cox Cc: Matt Domsch , Jan Engelhardt , Greg KH , linux-kernel@vger.kernel.org, stable@kernel.org, Justin Forbes , Zwane Mwaikambo , "Theodore Ts'o" , Randy Dunlap , Dave Jones , Chuck Wolber , Chris Wedgwood , Michael Krufky , torvalds@osdl.org, akpm@osdl.org, Chuck Lever In-Reply-To: <1160648107.23731.6.camel@localhost.localdomain> References: <20061010165621.394703368@quad.kroah.org> <20061010171429.GD6339@kroah.com> <1160610353.7015.8.camel@lade.trondhjem.org> <1160615547.20611.0.camel@localhost.localdomain> <1160616905.6596.14.camel@lade.trondhjem.org> <20061012015306.GB27693@lists.us.dell.com> <1160648107.23731.6.camel@localhost.localdomain> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Network Appliance Inc Date: Thu, 12 Oct 2006 08:15:26 -0700 Message-Id: <1160666126.6004.42.camel@lade.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 X-OriginalArrivalTime: 12 Oct 2006 15:15:27.0426 (UTC) FILETIME=[3F865220:01C6EE11] Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2235 Lines: 48 On Thu, 2006-10-12 at 11:15 +0100, Alan Cox wrote: > Ar Mer, 2006-10-11 am 20:53 -0500, ysgrifennodd Matt Domsch: > > > > Then their hardware is faulty and should be specifically blacklisted not > > > > make everyone have to deal with silly unmaintainable hacks. > > > > > > They are not hacks. The actual range of ports used by the RPC client is > > > set using /proc/sys/sunrpc/(min|max)_resvport. People that don't have > > > broken motherboards can override the default range, which is all that we > > > are changing here. > > No.. you have it backwards. The tiny tiny number of people with broken > boards can either set it themselves, use DMI, or ram the offending board > somewhere dark belonging to whoever sold it to them :-) The main problem with that approach is that the offending boardmakers tend to hide these details deep in technical docs that are not bundled with the motherboard, and which consequently nobody actually reads. Instead they see that NFS doesn't work, and conclude to waste NFS community's time in debugging it. We're still leaving a fairly large range of ports for the NFS client to use: there should be 373 that are rife for the taking. > > > To be fair, the motherboard manufacturers have actually registered these > > > ports with IANA: > > This is irrelevant, they are stealing bits out of the incoming network > stream. That's not just rude its dangerous - they should have their own > MAC and IP stack for this. Port assignments are courtesy numbering to > avoid collisions on your own stack. They have no more right to steal > packets from that port than CERN does to claim all port 80 traffic on > the internet. > > Why do I say dangerous - because they steal the data *before* your Linux > firewalling and feed it to an unauditable binary firmware which has > controlling access to large parts of the system without the OS even > seeing it. > > Not a good idea IMHO on any box facing even a slightly insecure port. No arguments with this. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/