From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Oz5yX-0000Zh-85 for mharc-grub-devel@gnu.org; Fri, 24 Sep 2010 06:57:57 -0400 Received: from [140.186.70.92] (port=38641 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oz5yT-0000ZN-Bk for grub-devel@gnu.org; Fri, 24 Sep 2010 06:57:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oz5yQ-0008Mp-Tp for grub-devel@gnu.org; Fri, 24 Sep 2010 06:57:53 -0400 Received: from mail-gx0-f169.google.com ([209.85.161.169]:52701) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oz5yQ-0008Mf-PM; Fri, 24 Sep 2010 06:57:50 -0400 Received: by gxk24 with SMTP id 24so1354596gxk.0 for ; Fri, 24 Sep 2010 03:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=pp2+1bIgNfnJrzPWAavGeq8c/ykCs/wfJUCenA4JUWI=; b=O0EJjhovdNWhnkGpOpRoicyBKLFUMasKzms45c4nphr4OhU/EKQhlhwCzPBKSEkR8i 1elGJx79T1fRYIILJqBSK+BL2mBR5/1pnb9/uYIziHKPEyRyuvxnW0w0NMMSmaPVQaC7 czFBjTtEIBvPn0PFAtnCN+Y5I48L9LocnwBzQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Mbr6H1FX1KvyeDzOT2+8EoiQ7U5FL3+TlEeseBhl0tmNXbNVLUzZoDcLn6ctdFgzpC MFsVNSPO02IkmHNXaYRZfea6SydcHoe7IHUCdQ7Y4RygI9zRdoNuVbDB4Ltre7Dqe4Xo dPxeGgHy5BnGIpQDjLkXvBEsX21LoTbCS+AT4= MIME-Version: 1.0 Received: by 10.150.52.11 with SMTP id z11mr4369880ybz.149.1285325869385; Fri, 24 Sep 2010 03:57:49 -0700 (PDT) Received: by 10.220.74.204 with HTTP; Fri, 24 Sep 2010 03:57:49 -0700 (PDT) In-Reply-To: <20100923221923.GA21862@riva.ucam.org> References: <20100923221923.GA21862@riva.ucam.org> Date: Fri, 24 Sep 2010 20:27:49 +0930 Message-ID: From: Brendan Trotter To: The development of GNU GRUB Content-Type: text/plain; charset=ISO-8859-1 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Cc: Richard Stallman Subject: Re: Guidance on conflicts between GNU GRUB and proprietary software X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2010 10:57:55 -0000 Hi, Just thought I'd throw my 2 cents in.. Any software (except the software that "owns" the MBR) that uses any sectors that are in the first track with the MBR and outside of any partition (e.g. before the first partition) is broken. Not only will this broken software (potentially) conflict with the software that "owns" the MBR (not just GRUB), but it will also (potentially) conflict with any other pieces of broken software. It does not matter if the broken software is proprietory of not, or if broken software restrict users' freedom or not, or if broken software is popular or well known or not, or if the broken software is extremely useful and/or has an "excuse". All of these considerations are irrelevant. The software touches something it shouldn't, therefore it is broken. I doubt that Windows is *directly* at fault. However, allowing broken software access to these sectors is a security flaw. If Windows allows software to tamper with these sectors, then what else does Windows allow software to tamper with? Does Windows allow software to install a virus in the MBR? Does Windows allow software to install a virus in one or more sectors that are loaded (and executed) by the MBR? At a minimum Windows should have a UAC warning (a dialog box requiring admin privileges that alerts the user to the attempted access, and gives them the option to deny permission), but I wouldn't be surprised if there's none. If there is no such warning, then the issue should be reported to Microsoft as a security vulnerability, because that's exactly what it is. While the situation is unfortunate, Vladimir's suggested use of error-correcting code is a very good idea. However, I think it should go one step further. If the user has several OSs, and each OS happens to have several pieces of broken software that trash different sectors, then simply avoiding those trashed sectors won't stop the system from becoming unbootable. GRUB has to restore the rightful contents of trashed sectors during boot to minimise the total number of sectors that are trashed at any point in time. In addition to increasing GRUB's ability to tolerate trashed sectors, this would also help to discourage broken software (and possibly, make it easier for users to identify which piece/s of software is broken). As a service to end-users; it would also be very nice if GRUB displayed a "high visibility" warning that something is tampering with the system's security and attempted to identify which pieces of software may be tampering with the system's security (so the user can more easily identify the cause). This warning could/should include a URL for a web page that explains the issue in more detail, and maybe a hex dump from each trashed sector so that signatures can be obtained more easily. Also, as a service to end-users; if/when broken software is correctly identified the publisher of that software should be informed of their mistake - something like a formal email that (politely) explains to them why their software is broken and (even more politely) requests them to fix their broken software. Cheers, Brendan