Windows 10? Free? Ed Bott has some thoughts

On 03/24/2015 02:11 AM, Roderick Stewart wrote:
On Tue, 24 Mar 2015 09:00:47 +1000, Maurice Helwig
wrote:

On 24/03/2015 4:51 AM, Kirk Bubul wrote:
http://www.zdnet.com/article/will-mi...tag=TRE17cfd61

QUESTION

If the update to win 10 is free and is done via Windows Updates, and my
computer is set to automatic updates -- do I get updated from win 7 to
win 10 whether I want it or not?????????

I am going to set all my computers to manual updates until I know the
answers.

http://dilbert.com/strip/2015-03-24

Made me laugh!


Rod.

Paul wrote:

VanguardLH wrote:

T wrote:

Just out of curiosity, do UEFI motherboards have a discharge berg to
reset the whole mess?

I don't have any UEFI motherboard so I haven't personally experienced
[the nuisance of] using them. I'm assuming your "discharge berg" means
the header on the mobo used to reset the CMOS. UEFI replaces BIOS.
BIOS settings are read from the copy put into the CMOS table (which
requires a battery when the PC has no power source to retain the
settings in CMOS), not directly from the EEPROM(s) holding the BIOS
firmware.

I'm not sure about storage options for UEFI systems.

The BIOS has *always* had the ability to flash the EEPROM chip.
On at least one brand of BIOS (Award or AMI), there is a
subroutine that knows how to flash EEPROM segments.

The area that a legacy BIOS updates, is DMI/ESCD. Any time the
CPU changes, more RAM is added, DMI is updated, the EEPROM segment
is burned. And this is one reason why, if you "upgrade" a BIOS,
pull the EEPROM chip out of the socket and put it in a lab
programmer later, the checksum won't match your original file.
It's because after the first boot, the DMI has been edited by
the BIOS and the whole image is no longer the same. I've tested
this, and right after a BIOS upgrade, my checksum was no longer
the same. And the DMI does it. Only a portion of the BIOS
image is "non-volatile", and only that area should be checksummed.

After flashing the BIOS (burning in new firmware), I don't see why you
would expect it to have the same checksum as the other but obviously
different old firmware code. The checksum for old and new code should
be different.

*******

As for the statements about BIOS passwords, there are two implementations.

On a desktop, typically two locations in CMOS RAM hold the password string.
On those, using the CLR_CMOS header, clears the password. So those are
easy to fix.

On "business" laptops, a 2KB EEPROM located near the Sourhbridge holds
the password. The tech support info says to ship the laptop back
to the factory, to have a forgotten password cleared. A dude in
Romania, charges $50 for a package (plus clip-on hardware connections),
to clear the EEPROM. It's not clear whether any special pattern has to be
stored in that chip, for the laptop to operate correctly. So those
don't have the easy option of a CMOS jumper. You're kinda screwed,
if helping a customer who owns such a laptop.

I only mentioned in passing that some computers can write into the BIOS.
Sometime awhile back I saw mobos that provided a backup of the BIOS. I
don't remember if those had a separate set of EEPROMS or if it was just
reserved space inside the same EEPROM. The option to save the backup
was in the BIOS settings so the BIOS was the one doing the burning.

Aren't the BIOS update program (when you flash in new firmware) also
using the BIOS to perform that function. It has been a long time since
I saw a debug of the flash update program but, as I recall, it called a
function in the BIOS to burn in the new firmware.

As for the business computer with the password stored in EEPROM, I
thought that was a function of TPM where that password was used to to
secure the hardware via a crypto key that has a unique RSA key for each
TPM chip. However, upon recollection, maybe there used to be a
different means of passwording a laptop because TPM wasn't established
until 2009 and I remember my workplace assigning me an IBM Thinkpad back
around 2006 plus it was already a year, or more old, and was an IBM
laptop and not one from Lenovo who started acquiring IBM's products back
in 2004, and that laptop that had password protection that couldn't be
simply erased by clearing the CMOS. It did have some extra hardware for
storing the password but it was a password that I could change (but I
needed to know the correct old password to change it). The IT admin
that doled it out to me wouldn't tell me the password and I understood
their viewpoint. It was sysprepped for my use to do work at home over a
VPN so they needed to manage the laptop. Other than changing some
policies pushed onto the laptop when logging into their domain (with
their permission), I really had no need to be changing anything else on
the laptop. It was their property, not mine.

I've seen articles saying to clear CMOS to reset all passwords for the
Thinkpad and others saying that will clear the passwords except for the
supervisor password, like
http://superuser.com/questions/28423...er-on-password.
I never really go into how passwording was enforced on that old Thinkpad
that I used about a decade ago. I've never been stuck before or after
will having to use one of those "business" class laptops. On a laptop
that goes on trips, encrypting the files is sufficient data protection.
With the loss of the hardware, it's not my concern if the thief can
continue using the hardware, and I don't need to protect the apps since
the thief can get those from anywhere and doesn't need my computer to
get them.

*******

The UEFI could be re-writing major portions
of the BIOS, and we'd never know it. Since UEFI
has a file system, and appears to have all sorts of
whizzy update options, I will not be surprised to
hear about it eventually getting trashed (somehow).
UEFI has all the earmarks of being an eventual
disaster (malware). It's just a matter of time until
someone figures out a way to brick it.

I've already read one posting, where someone managed to
disable BIOS access on a UEFI system, via a setting
in Windows. And there didn't appear to be any way to
reverse the operation. So UEFI is smelling liks
a disaster waiting to happen. About as safe as a
chocolate teapot.

But is the Windows setting writing to the UEFI BIOS EEPROM(s) or is it
writing to the CMOS table copy of the BIOS settings? Be interesting to
know what was said and if a CMOS reset was attempted (and failed).

As with drivers, the UEFI firmware has to be bitwidth matched to the OS.
A 64-bit UEFI can only load a 64-bit UEFI operating system's bootloader
or kernel. Well, that means once a user buys or builds a UEFI computer
that they are stuck with the same bitwidth for OS. The OS can switch
bitwidth processor mode (Linux 3.15, and later, can do this) but who
knows what Microsoft might or might not do. Could be you'll be stuck
with 64-bit Windows 10 if the UEFI is 64-bit. Oh what joy in [possibly]
limiting a user's choices at a later time. It'll be "You can't get
there from here" and "Too late to change". I haven't played with the
Windows 10 preview to have tested if a 32-bit version can be used with a
64-bit UEFI.

I haven't heard that UEFI has its own file system. It loads a boot
manager, just like the old BIOS did, but now has EFI binaries it can use
for driver, application, and boot code (to finally load the OS loader).
There are EFI boot services and EFI runtime services. EFI boot services
are only available while the firmware is in control of the hardware.
The OS can make use of the EFI runtime services but the ones I've seen
mentioned are date and time (same as with MBR BIOS) and NVRAM access
(isn't that the CMOS table copy of BIOS settings?). I don't see why
UEFI would need a file system versus the EFI API simply knowing the
binary offset to call a function in the EFI binaries.

As yet, I don't understand what are "UEFI applications" that run
standalone of any OS and can be installed independently of the mobo
maker. Maybe that's where the hackers will figure out how to pwn a
system. The OS loaders are (can be) a class of UEFI Applications.
http://en.wikipedia.org/wiki/Unified...ace#UEFI_shell
is the part that sounds a probably target for malware.

From issues (bugs) reported with differing implementations of UEFI, it
doesn't look like anything that I want. What Microsoft wants doesn't
mean it's good for me. The deficiences of MBR BIOS and its cures does
not entail having to supplant it with the spaghetti mess of UEFI.

Guess I'll have to start reading up on the vulnerabilities of UEFI, like
http://www.bing.com/search?q=hacking uefi. Or maybe I'll wait another 3
years for Windows 10 and UEFI to either solidify and establish
themselves or fall down.

VanguardLH wrote:


After flashing the BIOS (burning in new firmware), I don't see why you
would expect it to have the same checksum as the other but obviously
different old firmware code. The checksum for old and new code should
be different.

The legacy layout looks like this.

Main code block --- non-volatile
DMI --- updates on first boot
ESCD --- updates on first boot
(Microcode cache) --- when present, updates on first boot
Boot block --- is never supposed to be flashed, but
many stupid motherboard companies erase this,
and it's when this is erased, you have a
major brickage exposure

When you flash a new BIOS, let's pretend the entire chip
got erased and flashed. The DMI region is all-0s in the
image. On first boot, the DMI is populated by the BIOS
with discovered hardware. Later, you use Asus Probe or
Intel DMIExplorer, and you "read out" the hardware inventory.
Those are examples of uses of the DMI area, for hardware
inventory in large companies.

If you "burn" the BIOS, boot once, then do a run where
you "archive" the entire BIOS chip, the checksum of the
entire image now differs from the originally downloaded
image. The volatile portions have been populated with
new unique data. And that's what I'm referring to.

If you know where the main BIOS block checksum value
is stored, and how to interpret it, that one should
be a constant. As the main block is not changed
during normal operation. The main block checksum
is verified by the boot block code, before the
jump into that code during POST.

I only mentioned in passing that some computers can write into the BIOS.
Sometime awhile back I saw mobos that provided a backup of the BIOS. I
don't remember if those had a separate set of EEPROMS or if it was just
reserved space inside the same EEPROM. The option to save the backup
was in the BIOS settings so the BIOS was the one doing the burning.

Gigabyte has dual BIOS, consisting of two chips,
two "MAIN" blocks, but apparently only one boot block.
So the chips are not completely identical. Only our
product at work had completely duplicated contents,
and an arbiter on board to select one.


Aren't the BIOS update program (when you flash in new firmware) also
using the BIOS to perform that function. It has been a long time since
I saw a debug of the flash update program but, as I recall, it called a
function in the BIOS to burn in the new firmware.

I found documentation for a standard call for flashing.
If the BIOS wants to update the microcode cache, or
write to DMI, it pretty well must have that routine.
And it works in terms of the smallest block that can
be bulk erased and programmed, whatever that segment side
is. Back when I was programming the microcode cache on
my 440BX manually, the segment size was 2KB out of perhaps
a 128KB chip.

Since there was a shadow function, to copy the BIOS into
low RAM, it's also possible to flash the BIOS chip, while
the BIOS is still doing stuff (like say SMM).


As for the business computer with the password stored in EEPROM, I
thought that was a function of TPM where that password was used to to
secure the hardware via a crypto key that has a unique RSA key for each
TPM chip. However, upon recollection, maybe there used to be a
different means of passwording a laptop because TPM wasn't established
until 2009 and I remember my workplace assigning me an IBM Thinkpad back
around 2006 plus it was already a year, or more old, and was an IBM
laptop and not one from Lenovo who started acquiring IBM's products back
in 2004, and that laptop that had password protection that couldn't be
simply erased by clearing the CMOS. It did have some extra hardware for
storing the password but it was a password that I could change (but I
needed to know the correct old password to change it). The IT admin
that doled it out to me wouldn't tell me the password and I understood
their viewpoint. It was sysprepped for my use to do work at home over a
VPN so they needed to manage the laptop. Other than changing some
policies pushed onto the laptop when logging into their domain (with
their permission), I really had no need to be changing anything else on
the laptop. It was their property, not mine.

I was trying to help someone with a password issue in one
of the groups, and ran into the documentation for it.
It was a simple function, with a separate adjunct chip to
prevent "CLR_CMOS" junkies from having their way. I was
not able to get any other info - the dude who wanted
$50 to clear it, certainly wasn't going to give details
on his web site.

TPM is yet another era, and I'll just have to wait
for the next victim, for another "learning ezperience" :-)


I've seen articles saying to clear CMOS to reset all passwords for the
Thinkpad and others saying that will clear the passwords except for the
supervisor password, like
http://superuser.com/questions/28423...er-on-password.
I never really go into how passwording was enforced on that old Thinkpad
that I used about a decade ago. I've never been stuck before or after
will having to use one of those "business" class laptops. On a laptop
that goes on trips, encrypting the files is sufficient data protection.
With the loss of the hardware, it's not my concern if the thief can
continue using the hardware, and I don't need to protect the apps since
the thief can get those from anywhere and doesn't need my computer to
get them.

Business laptops are just evil. I pity the fool
who has to support them, and all their failure modes.
For the ones with FDE, I hope someone is making
backups :-)


But is the Windows setting writing to the UEFI BIOS EEPROM(s) or is it
writing to the CMOS table copy of the BIOS settings? Be interesting to
know what was said and if a CMOS reset was attempted (and failed).

The CMOS is only 256 bytes. You would be hard pressed (in our
modern bloated world), to design anything into a 256 byte
limit. I'm sure flash is being used. Just one code path
pointing to a UEFI object, is probably 256 bytes right there.

I haven't heard that UEFI has its own file system. It loads a boot
manager, just like the old BIOS did, but now has EFI binaries it can use
for driver, application, and boot code (to finally load the OS loader).
There are EFI boot services and EFI runtime services. EFI boot services
are only available while the firmware is in control of the hardware.
The OS can make use of the EFI runtime services but the ones I've seen
mentioned are date and time (same as with MBR BIOS) and NVRAM access
(isn't that the CMOS table copy of BIOS settings?). I don't see why
UEFI would need a file system versus the EFI API simply knowing the
binary offset to call a function in the EFI binaries.

I've seen one passing reference to "200 files" being in
there. But like the rest of UEFI, no tutorial articles
that go into depth.

Even the legacy BIOS had file systems of a sort. Read
only ones.

The main code block consists of LHA compressed code segments
with length fields. It was possible to parse the thing,
and decompress the code. I used to do some of that stuff
by hand. The code blocks would be things like PXE support
for the onboard branded NIC. Or a Promise RAID code module
for pressing the control-key hotkey sequence to enter
the RAID setup. Each of those is loaded during POST.
Storage code modules, have their Extended INT 0x13
disk I/O routines loaded, for usage by DOS.

Later, I got copies of MMTool and some other thing,
and that made extraction a whole lot easier.

http://rayer.g6.cz/romos/amimtool.gif

For some of those modules, they have VID:PID, so
you can figure out what the PCI Option ROM is for.
And say, check the version of your Silicon Image
RAID code for the SIL3112, and see whether you have
a buggy version.


As yet, I don't understand what are "UEFI applications" that run
standalone of any OS and can be installed independently of the mobo
maker. Maybe that's where the hackers will figure out how to pwn a
system. The OS loaders are (can be) a class of UEFI Applications.
http://en.wikipedia.org/wiki/Unified...ace#UEFI_shell
is the part that sounds a probably target for malware.

From issues (bugs) reported with differing implementations of UEFI, it
doesn't look like anything that I want. What Microsoft wants doesn't
mean it's good for me. The deficiences of MBR BIOS and its cures does
not entail having to supplant it with the spaghetti mess of UEFI.

Guess I'll have to start reading up on the vulnerabilities of UEFI, like
http://www.bing.com/search?q=hacking uefi. Or maybe I'll wait another 3
years for Windows 10 and UEFI to either solidify and establish
themselves or fall down.

I know very little about UEFI, and I don't expect I'll
find a web page that gives a complete dump. Maybe if
you want info at this point in time, it's a "textbook"
at the bookstore or Amazon.

Paul

T wrote:

Roderick Stewart wrote:

http://dilbert.com/strip/2015-03-24

Made me laugh!

Then enjoy these (disable the annotation crap, if present, along with
having to close those phucking ad popups):

https://www.youtube.com/watch?v=p4-uaxBhw5c
https://www.youtube.com/watch?v=6u8LWU59aXw

On 03/24/2015 07:31 PM, VanguardLH wrote:
T wrote:

Roderick Stewart wrote:

http://dilbert.com/strip/2015-03-24

Made me laugh!

Then enjoy these (disable the annotation crap, if present, along with
having to close those phucking ad popups):

https://www.youtube.com/watch?v=p4-uaxBhw5c
https://www.youtube.com/watch?v=6u8LWU59aXw


:-)

Loved the crack about Windows Nein

VanguardLH wrote:

Playing catch-up in this group. Comments below [inline], apologies in
advance for being weeks late in replying.

So the free update will be via Windows Update site, huh? Hmm, that
means for a clean Windows 10 that I'll have to save a backup, wipe the
OS partition(s) on my disk, install a clean Windows 7, and then use WU
to update to have a clean Windows 10. I detest polluted upgrades. If a
disk dies, I'll have to do that anyway (or restore from image backups)
to get Windows 10 back on my computer. The free offer is via the WU
site which means Windows 7/8 already has to be installed to be visiting
the WU site to get the Windows 10 upgrade download. So what happens
after the 1-year free upgrade expires and then my disk dies (and if I
was like most users that don't do backups)?

The quoted print below clarifies (and corrects) your above statement
where you noted Windows 7/8.
- The Win10 upgrade requires Windows 7Sp1 and Windows 8.1 (Win8.0 does
not qualify)


"The consumer free upgrade offer for Windows 10 applies to qualified
new and existing devices running Windows 7, Windows 8.1 and Windows
Phone 8.1."


Bott also figures "consumer" means the Home edition of Windows. Yuck.
I've had only one Home edition of Windows at home and many times got
snagged by features missing in it compared to the Pro version, like the
policy editors (local and groups), EFS, 16GB max RAM instead of 192GB,
Presentation support, software restriction policies (SRPs) that let me
block a program from ever loading (handy for apps that are rude in
reestablishing their startup program when they run), no domain joining
(so forget toting my laptop to work unless I go out to come back in but
into the corporate network's safe zone which means many resources are
unavailable), and probably more Pro-only features than I've tried. No
more crippled Home editions on my desktop.

If you visit the MSFT Store both 8.1 (Core and Pro) are 'consumer versions'
- while Ed raises the issue of of consumer being 'Home' (Win7
terminology) that may not necessarily be as constrained as appeared -
there are consumer SKU's and commercial SKU's. Ed raised the issue but
didn't necessarily state Win10 free upgrade was solely limited to the
entry level prior o/s. Second, 8.1 as noted above which only came in
full version media are both consumer version (Core and Pro) available in
the retail market and from the MSFT Store. i.e. I wouldn't extrapolate
too much in Ed's statement which imo is more postulative than concrete.


--
....winston
msft mvp consumer apps