<br><br><div class="gmail_quote">On Mon, Sep 26, 2011 at 4:29 PM, Avi Greenbury <span dir="ltr"><<a href="mailto:lists@avi.co">lists@avi.co</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">Rashkae wrote:<br>
<br>
> On 09/26/2011 06:53 PM, compdoc wrote:<br>
> > <a href="http://www.theregister.co.uk/2011/09/23/ms_denies_uefi_lock_in/" target="_blank">http://www.theregister.co.uk/2011/09/23/ms_denies_uefi_lock_in/</a><br>
> ><br>
><br>
> Am I the only one who thinks this is actually a good idea from MS?<br>
<br>
</div>I'd not seen it attributed to MS before, but no, it makes sense to me.<br>
It'd be nice to avoid the trust issues that have befallen SSL on the<br>
web, though I do see that extending the trust in the manufacturer to<br>
make good hardware as far as entrusting them to certify only good<br>
software is much more logical than deciding that arbitrary companies<br>
capable of generating random numbers are to be trusted on no prior<br>
grounds.<br>
<div class="im"><br>
> If PC makers wanted to lock pc's they could have done long before now.<br>
<br>
</div>I don't think they do directly, but they want Windows cheap and I don't<br>
really see why they'd necessarily not remove some toggle control in<br>
order to carry on paying £5 for their Windows licenses.<br>
<div class="im"><br>
> 4.  What I would like to see is OEM's making BIOS that can sign their<br>
> own boot sectors.  I can see no reason why this wouldn't be<br>
> implemented.  Basically, if a Boot sector/MBR gets changed in a<br>
> system with Secure boot enabled, the modified code will not boot<br>
> until someone with the BIOS password goes in and specifically tells<br>
> the bios to sign code The flaw with this idea, I suppose, it might be<br>
> possible for an attacker to read the private key from the BIOS, and<br>
> sign itself when installing.<br>
<br>
</div>The bigger flaw is that you're assuming the user is in a position to<br>
make that judgement as to whether to allow the code to run, and in a<br>
position where they actually care. Neither of these are generally true,<br>
as we can see with attitudes towards current, conventional, malware.<br>
<font color="#888888"><br>
--<br>
Avi<br>
</font><div><div></div><div class="h5"><br>
--<br>
ubuntu-users mailing list<br>
<a href="mailto:ubuntu-users@lists.ubuntu.com">ubuntu-users@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-users" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-users</a><br>
</div></div></blockquote></div><br><br clear="all">The thought/question has occurred to tiny little NOOB brain that what is to stop the attacker from writing a program to install a virtual box on top of the secure layer that mimics the users system with all the inimical spyware/keyloggers/etc. running in the background?<br>
With these new multi-processor systems there are a lot more un-used clock cycles available for malware to use without slowing most users down to the point where they actually notice.<br>-- <br><a href="http://linuxcounter.net/cert/544489.png" target="_blank"></a>Accidental deaths by firearms account for less than 1% of the 30,000. 
 There are three times as many medical mistake deaths in the US than 
there are accidental gun deaths.  Perhaps we need safety locks on 
doctors and nurses?<br><br><a href="http://linuxcounter.net/cert/544489.png" target="_blank"><img src="http://linuxcounter.net/cert/544489.png"></a><br><br>