linux-kernel - Re: Dual-Licensing Linux And Medical Devices

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: <1181924861.21797.240.camel@localhost.localdomain>
Date:	Sat, 16 Jun 2007 00:27:41 +0800
From:	Tim Post <tim.post@...kinetics.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Michael Poole <mdpoole@...ilus.org>,
	Daniel Hazelton <dhazelton@...er.net>,
	Alexandre Oliva <aoliva@...hat.com>,
	Lennart Sorensen <lsorense@...lub.uwaterloo.ca>,
	Greg KH <greg@...ah.com>,
	debian developer <debiandev@...il.com>,
	"david@...g.hm" <david@...g.hm>,
	Tarkan Erimer <tarkan@...one.net.tr>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>, mingo@...e.hu
Subject: Re: Dual-Licensing Linux And Medical Devices

On Thu, 2007-06-14 at 21:23 -0700, Linus Torvalds wrote:
> 
> On Thu, 14 Jun 2007, Michael Poole wrote:
> > 
> > If the signature is one that serves to indicate origin, to detect
> > tampering, or the other things you mentioned, the program's binary is
> > useful when separated from the signature.  My objection arises when a
> > functionally equivalent binary -- including advertised functions such
> > as "runs on platform XYZ" -- cannot be produced from the distributed
> > source code.
> 
> Ahh.
> 
> Ok, that's a totally different issue, and is one where I heartily agree 
> with you. I would actually *love* for the GPL (any version) to have a 
> "guarantee of authenticity", where if you distribute a binary, there has 
> to be some documented way to get *exactly* that binary out of the source 
> code that got distributed.

I would hope that this is *required*, somehow, when dealing with medical
equipment. I don't think those appliances even have the capacity to
build every upgrade from source. None that I've tinkered with do. These
things almost need a license of their own.

As long as the signing mechanism can't be used to force clinics to pay
for the privilege of upgrading free software, that is. It would truly
suck if an ultrasound loaded with free software sat in a corner useless
because a free clinic could not afford to pay for what they already paid
for.

If you guys can find a way to make that practical given my above
concerns, that would be entirely useful. I hate the fact that this kind
of trust is needed because it is so very easily mis-used, but people
dying due to hacked IV regulators really wouldn't much care about those
politics.

I think, also privacy implications for patients. A rootkit in a MRI
would be very bad.

Regardless, like it or not, kernel code is in or headed for medical
devices, so I hope some more brain power is burned on this. 

Best,
--Tim

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