public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Matt Domsch <Matt_Domsch@dell.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>,
	Jan Engelhardt <jengelh@linux01.gwdg.de>,
	Greg KH <gregkh@suse.de>,
	linux-kernel@vger.kernel.org, stable@kernel.org,
	Justin Forbes <jmforbes@linuxtx.org>,
	Zwane Mwaikambo <zwane@arm.linux.org.uk>,
	"Theodore Ts'o" <tytso@mit.edu>,
	Randy Dunlap <rdunlap@xenotime.net>,
	Dave Jones <davej@redhat.com>,
	Chuck Wolber <chuckw@quantumlinux.com>,
	Chris Wedgwood <reviews@ml.cw.f00f.org>,
	Michael Krufky <mkrufky@linuxtv.org>,
	torvalds@osdl.org, akpm@osdl.org,
	Chuck Lever <chuck.lever@oracle.com>
Subject: Re: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic
Date: Thu, 12 Oct 2006 11:15:07 +0100	[thread overview]
Message-ID: <1160648107.23731.6.camel@localhost.localdomain> (raw)
In-Reply-To: <20061012015306.GB27693@lists.us.dell.com>

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

> > 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.
 
> For the one Dell server affected, we could DMI list
> it; likewise for others.

This should be done with DMI I agree.



  parent reply	other threads:[~2006-10-12  9:51 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20061010165621.394703368@quad.kroah.org>
2006-10-10 17:13 ` [patch 00/19] 2.6.17-stable review Greg KH
2006-10-10 17:14   ` [patch 01/19] dvb-core: Proper handling ULE SNDU length of 0 (CVE-2006-4623) Greg KH
2006-10-10 17:14   ` [patch 02/19] NFS: Fix a potential deadlock in nfs_release_page Greg KH
2006-10-10 17:14   ` [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic Greg KH
2006-10-10 18:59     ` Jan Engelhardt
2006-10-11 23:45       ` Trond Myklebust
2006-10-12  1:12         ` Alan Cox
2006-10-12  1:35           ` Trond Myklebust
2006-10-12  1:53             ` Matt Domsch
2006-10-12  2:04               ` Trond Myklebust
2006-10-12 10:16                 ` Alan Cox
2006-10-12 10:15               ` Alan Cox [this message]
2006-10-12 15:15                 ` Trond Myklebust
2006-10-12  7:58             ` Jan Engelhardt
2006-10-12  8:35               ` Bernd Petrovitsch
2006-10-12 12:28                 ` Jan Engelhardt
2006-10-12 15:01               ` Trond Myklebust
2006-10-12 15:49                 ` Jan Engelhardt
2006-10-10 17:14   ` [patch 04/19] LOCKD: Fix a deadlock in nlm_traverse_files() Greg KH
2006-10-10 17:14   ` [patch 05/19] NFS: More page cache revalidation fixups Greg KH
2006-10-10 17:14   ` [patch 06/19] Backport: Old IDE, fix SATA detection for cabling Greg KH
2006-10-10 17:14   ` [patch 07/19] invalidate_complete_page() race fix Greg KH
2006-10-10 18:12     ` Hugh Dickins
2006-10-10 19:14       ` [stable] " Greg KH
2006-10-10 19:30         ` Andrew Morton
2006-10-10 17:14   ` [patch 08/19] ext3 sequential read regression fix Greg KH
2006-10-10 17:14   ` [patch 09/19] sysfs: remove duplicated dput in sysfs_update_file Greg KH
2006-10-10 17:15   ` [patch 10/19] Video: Fix msp343xG handling regression Greg KH
2006-10-10 17:15   ` [patch 11/19] Video: cx24123: fix PLL divisor setup Greg KH
2006-10-10 17:15   ` [patch 12/19] SPARC64: Fix serious bug in sched_clock() on sparc64 Greg KH
2006-10-10 17:15   ` [patch 13/19] Fix sparc64 ramdisk handling Greg KH
2006-10-10 17:15   ` [patch 14/19] PKT_SCHED: cls_basic: Use unsigned int when generating handle Greg KH
2006-10-10 17:15   ` [patch 15/19] xirc2ps_cs: Cannot reset card in atomic context Greg KH
2006-10-10 17:15   ` [patch 16/19] Add PIIX4 APCI quirk for the 440MX chipset too Greg KH
2006-10-10 17:15   ` [patch 17/19] MMC: Always use a sector size of 512 bytes Greg KH
2006-10-10 17:15   ` [patch 18/19] ahci: do not fail softreset if PHY reports no device Greg KH
2006-10-10 17:15   ` [patch 19/19] Input: logips2pp - fix button mapping for MX300 Greg KH
2006-10-10 17:59   ` [stable] [patch 00/19] 2.6.17-stable review Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1160648107.23731.6.camel@localhost.localdomain \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=Matt_Domsch@dell.com \
    --cc=Trond.Myklebust@netapp.com \
    --cc=akpm@osdl.org \
    --cc=chuck.lever@oracle.com \
    --cc=chuckw@quantumlinux.com \
    --cc=davej@redhat.com \
    --cc=gregkh@suse.de \
    --cc=jengelh@linux01.gwdg.de \
    --cc=jmforbes@linuxtx.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mkrufky@linuxtv.org \
    --cc=rdunlap@xenotime.net \
    --cc=reviews@ml.cw.f00f.org \
    --cc=stable@kernel.org \
    --cc=torvalds@osdl.org \
    --cc=tytso@mit.edu \
    --cc=zwane@arm.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox