Unsolved
This post is more than 5 years old
1 Rookie
•
2 Posts
1
11825
March 30th, 2018 05:00
bios or uefi?
hello, I am really confused because I can not find out in the BIOS settings whether it is an old BIOS or a UEFI boot? also there is no legacy boot entry....
is there any other way to find out this -perhaps in the registry?
the system is up to date, the bios has not been updated
dell studio xps 8100 / ws 10 pro / 64bit
No Events found!
speedstep
11 Legend
•
47K Posts
1
March 30th, 2018 05:00
Class 3 UEFI removes Compatability Support Module leaving only Windows 10 hardware, software, and drivers. Studio XPS 8100 is NOT a UEFI system.
http://www.dell.com/us/dfh/p/studio-xps-8100/pd
This is a windows 7 system from 2009.
People will become quite upset when they find this out.
Thats also why INTEL and Microsoft etc have stated that ONLY windows 10 can be used with Current Skylake and Kabylake and Coffeelake processors.
INTEL has stated that all future updates will be Class 3 by 2020.
For anyone that depends on legacy hardware, software, drivers this will be a huge setback that will either force users to abandon these devices, run them on older platforms or move their operations to other platforms that have class 2.3.1 UEFI with CSM.
Tesla1856
10 Wizard
•
17.9K Posts
•
71.4K Points
0
March 30th, 2018 09:00
If you don't see BIOS options for UEFI, CSM, and/or SecureBoot ... it's likely Legacy BIOS.
I've found I like UEFI-Mode, especially on a newer Windows-only systems. For one, it's the only way to enable SecureBoot. I think SecureBoot is the only way to enforce Boot-Kit authorization (there are only a few).
There might be a third one that is just EFI, but I think that is still just considered non-UEFI (not true UEFI). Some of the machines released in that middle year (around 2011) act a bit different. Maybe @speedstep knows the answer to this sentence.
ejn63
12 Elder
•
31.3K Posts
•
154.5K Points
1
March 30th, 2018 16:00
The XPS 8100 is BIOS only - it does not have UEFI firmware.
speedstep
11 Legend
•
47K Posts
1
April 2nd, 2018 08:00
Secure Boot is worthless. Microsoft’s Debug Mode Flaw and “Golden Key” Leak Allows Disabling of Secure Boot
Microsoft did release some patches, but the developers insist that the issue is not entirely fixed up. You can check out these patches (MS16-094 and MS16-100) and then read up on the blog post itself on why they do not solve the issue
Basically, bootmgr checks the policy when it loads, if it includes a DeviceID, which doesn’t match the DeviceID of the device that bootmgr is running on, the policy will fail to load. Any policy that allows for enabling testsigning (MS calls these Retail Device Unlock / RDU policies, and to install them is unlocking a device), is supposed to be locked to a DeviceID (UnlockID on Redstone and above). Indeed, I have several policies (signed by the Windows Phone production certificate) like this, where the only differences are the included DeviceID, and the signature. If there is no valid policy installed, bootmgr falls back to using a default policy located in its resources. This policy is the one which blocks enabling testsigning, etc, using BCD rules.
During the development of Windows 10 v1607, Microsoft created a new type of Secure Boot Policy (referred to as SBP henceforth for the sake of brevity) for internal testing and debugging purposes. The policy is “supplemental” in nature with no DeviceID present, and it causes its settings to be merged in onto an existing Boot Policy. The Boot Manager loads in the older types of SBP, then verifies its signing and authenticity and then loads in these supplemental boot policies. The issue here is that there is no further verification on the supplemental policy itself. Also, Boot Managers earlier than Windows 10 v1511 do not know about the existence of the supplemental nature of these policies, and hence, react as if they loaded a valid and signed certifcate. Again, this behavior was likely for internal development, so that the developers shouldn’t have had to sign each and every OS version and minor change they had to do on the device. If you loaded a supplemental SBP, you can enable test signing for Windows to allow you to load in unsigned drivers. Further, since these Policies come into play before the Boot Manager stage in the boot procedure, you can compromise the security of the whole order and run unauthorized (read self-signed) code. This opens up a lot of possibilities, for users intending to modify parts of Windows beyond authorization and for malware creators alike.