Wolf said:
That was first order of business before d/l W8.
I surmise that "built-in security" refers to secure boot. If so, no
problems here, it doesn't work on this box (MSI P965 Neo mobo w/ Core
Duo E6600 CPU, date 2006) , but install went fine (just took a l-o-o-ng
time.) Which is OK by me. I think of secure boot as malware. ;-) There
were no problems installing.
This is secure boot. It allows the startup process to check for signed
executables, so the startup process basically allows only one thing
to happen. (Maybe that would prevent an MBR virus from taking over.)
If multiple OS certificates are loaded, then you can have
more OSes. On WinRT (Win8 for mobile devices), Secure Boot is
a requirement, and will likely be used to enforce only one OS
running on the box. Whereas, on desktop PCs, there are more options - when
I upgraded to Win8 here, the missing secure boot did not prevent installation
or running of the upgrade. If you're buying a Dell with windows 8 on it,
it's a topic you might want to research, to see how Dell has handled
the issue, whether there are multiple certificates, whether Secure Boot
can be turned off, and so on.
http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Secure_boot
"Secure boot
The UEFI 2.2 specification adds a protocol known as Secure boot,
which can secure the boot process by preventing the loading of
drivers or OS loaders that are not signed with an acceptable
digital signature. When secure boot is enabled, it is initially
placed in "Setup" mode, which allows a public key known as the
"Platform key" (PK) to be written to the firmware. Once the key
is written, secure boot enters "User" mode, where only drivers
and loaders signed with the platform key can be loaded by the
firmware. Additional "Key Exchange Keys" (KEK) can be added to
a database stored in memory to allow other certificates to be used,
but they must still have a connection to the private portion of the
Platform key. Secure boot can also be placed in "Custom" mode, where
additional public keys can be added to the system that do not match
the private key."
*******
NX/XD is for runtime security, and preventing malware from doing
things to memory that it should not.
Of the three preview releases of Win8, the first two did not have
NX turned on. Only the last one turned it on, and NX was not
prominently listed as a requirement on the Microsoft web pages.
Exactly why it wasn't mentioned, isn't clear to me, as it's
a nuisance for users to discover half way through an install,
that they don't have it.
NX/XD was optionally used, on older OSes, so you could opt for it
or not. Whereas, for better or worse, it's always used on Windows 8.
NX is for AMD, and XD is for Intel. NX is on S754, S939, and all
the later AMxx socket processors. I don't know if it's required for
the processor to support 64 bit instructions (there were a few 32 bit
only processors in the first two mentioned sockets). XD on Intel,
requires at least a late model P4, probably in LGA775 socket. I don't
know if there are any S478 socket P4 processors with XD. The XD requirement
is what only makes Win8 a candidate for two computers here (as the
others don't have NX or XD). (You can look up XD on ark.intel.com and
whether your Intel processor has it or not.)
http://en.wikipedia.org/wiki/NX_bit
"An operating system with support for the NX bit may mark certain
areas of memory as non-executable. The processor will then refuse
to execute any code residing in these areas of memory. The general
technique, known as executable space protection, is used to prevent
certain types of malicious software from taking over computers by
inserting their code into another program's data storage area and
running their own code from within this section; this is known as
a buffer overflow attack.
"
So that's a useful form of protection, when the software people can't
seem to remove all the possible stack overflow or buffer overflow
exposures in their code.
To me, Secure Boot seems a bit like overkill, whereas NX is
useful.
When I first started writing this answer, I thought maybe a TPM chip
was needed for Secure Boot, but I couldn't really find any mention of
TPM at all in the case. So it would appear TPM is only used to optionally
support things like BitLocker encryption. It looks like the
certificate scheme, is "boiled into the UEFI BIOS".
Paul
