Peter Wieland still has access into the building and the ability to smack, I left 18mo ago ;).
Regarding the crowdstrike incident, I am curious how they plan to force out AV venders outside of kernel. Currently, most public AV/EDR products are AM/PPL processes, which requires an ELAM driver which in turn requires MVI membership. I assume they want to lock the new AV API behind MVI membership as well - which would make sense. But to join MVI you need a working AV software with a certification - otherwise you get rejected, no matter what. But how do you handle giving out access to MVI afterwards? What is the plan here? You give access to the API to all malware vendors, but what about new or smaller companies that do not currently even have access to AM/PPL - MVI? Do they have give access to everyone? If they lock out new/small companies out, they are going to get sued into oblivion, especially in the EU. I highly doubt they will give the access to everyone, considering how hard they currently gatekeep AM/PPL. If they lock it down, any locked out company could then sue them on the basis of unfair competition, since they are an AV as well. So im really curious how they deal with this.
They are not going to get sued to oblivion by new or small companies. Companies like that don’t have the resources.
Since most so called security software is close kin to malware, it is all being slowly strangled. Good riddance in my opinion, but before we get there I suspect increasing use of virtualization will silo more and more functions. But that’s a total guess on my part
Im pretty sure that in the EU that would fall under DMA, the EU commission can fine up to 10% of company revenue. You dont need money to be able to file a complaint. But that is off-topic for this forum.
The EU’s DMA and DSA could be the basis for a completely new forum.
Peter could do it as well, but you were one of the guys who “fixed” this same sort of thing before. And I’m sure you harbor a deep and abiding desire to return to Redmond. Startups? Fame and fortune? What is that compared to the ability to eat in the cafeteria and deal with loads of internal politics, and work in an area that nobody internally really values.
C’mon… it’s such an appealing proposition.
Leading the effort to gracefully get the remaining non perf critical drivers out of kernel mode would have been the culmination of my drivers experience, but yeah it became clear 10+ years ago that drivers expertise was not valued anymore. I do miss an accessible cafe for coffee and a salad though
(as I drink my aeropress cup of coffee b/c that is closest approximation to an espresso I have).
I distinctly remember years ago (OK, decades ago) being given a tour of the hardware team facility in Redmond by the legendary Adrian Oney when I was considering applying for employment. I noticed that many offices had mattresses in them, and he said it was kind of a badge of courage to sleep in your office at night. That was when I decided maybe I wasn’t a good fit for Microsoft.
Adrian Oney was legendary in part because of code he put in the Windows 3.x kernel debugger, WDEB386.EXE. During initialization, it tried to detect exactly what kind of CPU you were using. If it was one it didn’t recognize, it printed a message something like “Wow, you must have some special kind of CPU – please tell adriano.” That message survived, as far as I know, clear into Windows 98.
It is wildly off topic, but while many governments have attempted various kinds of anti-trust laws, none have really worked.
From the point of view of this forum, I doubt that anything that any government or court will do will make any practical difference. At least for a very long time to come. So we have to work with what we have. And use such means as we can
Is that what they are doing? That makes me sad and lessens my interest in using it. If it’s just going to be a WDF wrapper might as well stick with WDF.
I’m finally getting caught up on professional life after taking an extended vacation.
@Zac_Lockard Thanks for the reminder about Driver Package Isolation, which I’ve been utilizing with my driver packages, but I was asking for clarification regarding “driver isolation to limit blast radius“ and what was meant by “driver isolation” in that context.
Regarding “Driver signing will require a higher security and resiliency bar with many new certification tests.“, I would find it highly helpful if Microsoft would properly fixed the damned HLK tests & mitigation filters before [exponentially?] increasing the number of certification tests that driver developers have to execute as part of preparing an HLK package to submit for driver signing purposes.
Driver isolation in principle means that anything related to your driver (regkeys, files) are in locations that are known to and specified by the the OS: HKR for regkeys, or a file location from something like IoGetDriverDirectory (or another API as specified here). If there was an issue with an isolated driver needing remediation, the OS could completely clean up the state of that driver.
Simply, they won't in near future. After CrowdStrike incident, Microsoft said that its "going to" reduce kernel code. Microsoft always had a thing for 3rd party drivers. They don't want your code on their kernel, but device drivers have to work somehow.
Microsoft wants Windows to be stable (of what is left from that word), by trying to reduce number of drivers and using AI in %30 of its code base. Which is funny, considering they even manage to break user mode components. Examples are the "localhost" and SSD controller incident nobody knows true or not.
The biggest flaw IMO is that NT shares same privileges as other kernel drivers. Whether it be AV, AC or something else. They introduced PatchGuard so AVs don't hook syscalls as they wish. The AV industry backslashed. Called it "imperfect" and blamed it for giving malware more opportunity, somehow. KPP doesn't prevent kernel modifications, it just crashes the system when they are detected.
Everyone wants their code on those juicy opaque structures. And Microsoft doesn't want that. Virtualization is one good way to seperate Microsoft code from "3rd party" code on kernel. But still, if a driver goes down, the system goes down. It just makes sure drivers can't access things they shouldn't (like LSASS). Which it has power to, but does not for some reason.
Now they push towards UMDF. But as far as I see, nobody listens.
And I agree with Peter. Their "generic" preinstalled drivers won't match anywhere the speed of our own custom ones. I don't want no "Microsoft Basic ..... Adapter" like its for graphics.
Understood. Yes, I’m familiar with and use the isolation w/respect to registry locations used to store driver settings, etc., which are needed at driver load time.
The ask for clarification was just to ensure that I hadn’t missed something related to a new virtualization mechanism used to demote 3rd party drivers to some lesser degree of access to kernel resources as compared to in-box drivers.
Nope, nothing like that
Virtualization based security is a core feature of windows 11. It does not however discriminate against third party drivers.
I’ve got my head fairly well wrapped around the concepts of Virtualization Based Security and Virtual Trust Levels, along with secure code execution at VTL 1, so that’s not surprising since the space we’re working in is all at VTL 0 regardless of whether it’s an in-box driver or a 3rd party driver.