Assembly Language in WDK

NTDEV
21

As usual, what we have here is the case of somebody with only a partial grasp of a solution asking a SPECIFIC question (“how do I code up an SENTER or SKINIT instruction”) instead of asking the list how to solve their larger, OVERALL problem (“I want to enter a secure environment from Windows, can anybody here give me some pointers on how to do it”).

Of course in Windows we code “db 0xxx” for as-yet undefined opcodes as required. You used to be able to see this in NTDDK.H before instructions such as “rdtsc” and “yield” were universally defined.

While Don may be wound a bit tight on this topic, he’s also ENTIRELY CORRECT. If the OP is coming from a *nix background, it’s entirely likely that he doesn’t fully grasp the impact to the OS of what he’s proposing. And given that he didn’t ask for help on his overall problem, I don’t think it’s unreasonable to point out to him, in capital letters, that what little he’s told us points to a pretty bad design in Windows.

As to what Intel recommends for implementing LT, I wouldn’t necessarily rely on guidance from Intel on how to code for the Windows kernel environment.

Anthony: Get some time with an experienced Windows kernel-mode dev and talk through what you want to accomplish. If you do, I think you’ll find “How do I code up an SKINIT and can I use GCC to write my Windows drivers” to be the least of your issues.

Peter
OSR

22

I’m not saying Windows is unreliable or comparing it to Linux. In my eyes, they are both unreliable and unsecure. It’s just that you dont understand our requirements. The unsecureOS, which will be Windows because thats what the users want, is only used for access to the public internet. Web browsing and email.
The secureOS is a virtualized environment which is also executing Windows Guest VMs. The only difference is that those Windows Guest VMs are secure and only connected to the secure network.
The unsecured Windows is only connected to the public internet.
The actual work will be done in the Windows Guest VMs running on top of the secureOS, which is not Linux or Windows, it is custom. Those are the critical OSes, not the unsecured Windows. Also, the secureOS will not allow connections through the network card which is connected to the public internet.
Also, I have pulled the power on my Windows machine here and it re-booted fine. Good enough for email and web-browsing on the public internet.
I have worked a lot on the secureOS drivers, and other embedded drivers, but not on Windows development for at least 8 years, and I am unfamiliar with Windows driver development, but not driver development in general, so, I am just seeking to get up to speed again so I can complete this study and let our customer know what the issues are, including the possibility that the unsecure OS might not boot up again. The conclusion could very well be, “Hey, you really dont want to do this”.

23

And given that there are drivers running at the same security level that
your driver is running at, any other driver can modify the image of the
OS that you are downloading/about to run at any point they so choose.
Case closed.

If you really want security with no other actors in the way, perform a
PIXI (or whatever the acronym is) boot and grab the image off the
network and then use the TPM to validate the image before executing it.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gdc4s.com
Sent: Thursday, July 26, 2007 3:51 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Assembly Language in WDK

You CANNOT make a multi-boot system and meet security requirements.
During the time the “unsecure OS” (linux or win) is running on the
platform, the image and data of the secureOS cannot physically reside on
that machine. That is a security no-no.
The secureOS must reside in a remote location inaccessible to the
unsecureOS. When the special driver is invoked, it will have a way to
retrieve the secureOS image (perhaps over a network), load it, and
execute it. The secureOS will be configured with a networked file
system. This all must occur with no reboot of the machine.
That is the subject of the study. Case closed.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

24

“And given that there are drivers running at the same security level that
your driver is running at, any other driver can modify the image of the
OS that you are downloading/about to run at any point they so choose.
Case closed”

Not true, a kernel driver can completely control the state of the machine. Like vmware’s driver.

25

“If you really want security with no other actors in the way, perform a
PIXI (or whatever the acronym is) boot and grab the image off the
network and then use the TPM to validate the image before executing it.”

Now that (PXE + TPM) IS part of the plan, after the kernel driver has wrested control of the machine from the unsecureOS.

26

Tim,

Don, while I usually enjoy your curmudgeonliness, you are being entirely
unreasonable here. This is a special-purpose need, for a
special-purpose piece of hardware. The design he has described is
*exactly* the design that Intel recommends in their LaGrande Technology
architecture. And crashing the OS is kind of irrelevant if he’s going
to wipe and replace the entire OS anyway, wouldn’t you say?

Actually, Don is not entirely unreasonable - he just expressed a very well-founded concern that the whole thing may go well beyond screwing up the current session (which, as you have properly pointed out, does not really matter in this context), and, in addition to that, screw up the whole installation and/or destroy user data. This seems to be much more risky than writing 0 to CR0 or doing any other operation that resets CPU right on the spot without bugchecking, because the machine keeps on running, and there may be some inconsistencies between the *actual* state of the machine and the one assumed by the newly loading OS.

Although it can be done, it does not necessarily have to de done as abruptly as the OP described, i.e. by “wiping the currently running WinOS from memory” - as Don properly pointed out, this is at least irresponsible.

I would do it a bit differently. ExitWindows() shuts down the OS “in civilized and orderly fashion”, and then resets the CPU. I would rather call ExitWindows() from the user mode, and monitor its execution flow - after it is done with saving the OS state, I would change its execution flow is such way that, instead of resetting the CPU, it issues GETSEC [SENTER] instruction…

Anton Bassov

27

wrote in message news:xxxxx@ntdev…
>> Also, I have pulled the power on my Windows machine here and it
>> re-booted fine. Good enough for email and web-browsing on the public
>> internet.

Set up a test to do this 10,000 times after having run applications from
multiple vendors. This testing can be automated, with scripts to do the
testing and a simple driver to crash the system (for instance have an IOCTL
that calls KeBugCheck) with the invocation of the driver varying in time.
I suspect you will be very unhappy. Your one time test, is like saying
“Gee I connected to the internet without any protection and nobody infected
my computer and stole anything so I don’t think I need security” and just
as stupid.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

28

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Tim Roberts[SMTP:xxxxx@probo.com]
Reply To: Windows System Software Devs Interest List
Sent: Friday, July 27, 2007 12:54 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Assembly Language in WDK

That’s fine. Just put it in a standalone assembler file, just like you
do on Linux, and put it in a subdirectory called “i386”. You’ll have to
convert it to MASM. Then, in the sources file, you do this:

SOURCES = \
driver_file_1.c \
driver_file_2.c …

I386_SOURCES = \
senter.asm

The build process will take care of it. You might want to add !ifdefs
to make sure no one tries to build an x64 version.

Why? Linker shouldn’t find functions defined in assembly files from i386 directory. For x64 version there can be assembly file in amd64 subdirectory and in the SOURCES file something like:

AMD64_SOURCES = senter.asm

I admit I’ve never tried to use both i386 and amd64 assembly files in one driver but I believe build would handle it gracefully.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

29

Don:

I’ve done quite a bit of research in to a related LaGrande area, and I
would agree with you that there are some rather obvious potential
issues. What I looked at did not involve crashing the OS, but rather
pushing the existing instance in to a MVMM after spawning a new host.
There are still a lot of problems that I see. That being said, Tim is
quite correct about the (singular TXT) Intel document describing this,
although unless the dev also performs TPM based attestation and
measurement starting with BIOS, the whole exercise is kind of pointless.
That notwithstanding, what Intel asserts in basically one document does
not comment on OS support, so I can see your point, except that I have
believe the dev is conducting some sort of feasibility study, which is
what I did. I would also agree with you about the “academic” nature of
this problem. Here’s the thing: it’s what they want. There is no
“user” to be victimized here. Personally, I find it a little hard to
believe that they haven’t figured out that they might lose data in the
process, academics or otherwise. They just don’t care, for whatever
reason. The bottom line is that the user and the client are either the
same, or, minimally, that is the client’s problem. I don’t know who the
dev’s client is, but I know in my case this thing, should it ever come
to exist, will never get out in to the open, and the idea that this is
somehow a Linux conspiracy is little over the top. I realize you don’t
mean that completely seriously, nevertheless, it is still there.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Thursday, July 26, 2007 19:04
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Assembly Language in WDK

Tim,

Sorry, but I have just been hearing a FUCKING LECTURE BY A BUNCH OF
ASSHOLES, about something similar. These pointy hair professor types
are
using the fact that they crashed Windows and therefore lost work to show

that Windows is unreliable and Linux is not!

He is not wiping and replacing the OS, he is crashing the OS to
load
his secure OS, and then expecting the user to reboot into Windows. I
for
one would be highly pissed to discover by running the “secure
application”
I have lost all the work on my desktop system!

Anthony claims he needs to load the secure OS from a network and
not
on the disk, so then at least he can make his network loader to be
something that respects the OS environment, and NOT A PIECE OF GARBAGE.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Don Burn wrote:
>> Please tell us your product so we can recomend all of our customers
>> avoid
>> this. You are going to do a ton of damage, by basically crashing the
OS
>> to
>> run your crap. Instead of this make your secure OS a boot option,
and
>> never go into Windows. It is garbage like this, that make me laugh
>> everytime I see the Linux is reliable and secure, and Windows is not
>> claims.
>>
>
> Don, while I usually enjoy your curmudgeonliness, you are being
entirely
> unreasonable here. This is a special-purpose need, for a
> special-purpose piece of hardware. The design he has described is
> exactly the design that Intel recommends in their LaGrande
Technology
> architecture. And crashing the OS is kind of irrelevant if he’s going
> to wipe and replace the entire OS anyway, wouldn’t you say?
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

30

>>
“And given that there are drivers running at the same security level that
your driver is running at, any other driver can modify the image of the
OS that you are downloading/about to run at any point they so choose.
Case closed”

Not true, a kernel driver can completely control the state of the machine. Like
vmware’s driver.
<<

In this case, I’m afraid you are missing something important, deadly, and unavoidable.

WHEN your driver is loaded, and BEFORE ANY of your driver’s code is executed, ANY OTHER driver with a load image callback registered will know that your driver has been loaded, all references resolved, and where its image lives in the kernel’s virtual address space. Since that image includes PE headers, it can determine entry point, imports, etc., etc…

At that point it can [if it tries hard enough] modify ANYTHING in your driver. I KNOW this is true- we use this technique regularly to do “truly evil things” [that for now I have no intention of disclosing outside Microsoft] that make it easier or economical for us to effectively test difficult-to-reach or difficult-to-test parts of the KMDF runtime and loader.

So what difference does it make if your driver can control the machine once it starts running? The bad guys can stop you before you even get the chance to take control, if they are truly determined to do so.

31

Thanks MM,
This is a feasibility study. We WANT to discover ALL the issues surrounding LT/VT and their usages. We have already fielded an LT/VT system that boots from BIOS with TPM as the root of trust. It’s not like we’re some hacks who just started coding yesterday. We have already fielded LT/VT early launch systems. It’s late launch we dont trust, but we also want it, somehow.
This is a follow-on trade study that the customer wants. They dont care what happens to the original unsecureOS, or if will reboot again, or if it has to be re-installed. This is simply a “thinking outside the box” study. We have already done the “normal” late launch as advertised by Intel. It is not secure enough to be certified.
The study we are doing now is to find “other” ways that we COULD do a late launch.
Don, there is no OS bias here, our customer uses every OS known to mankind, and many that are only known to very few mankind.
I just wanted to know how to write assembly code for Windows drivers, and some here have answered that question. And I thank them, and I am proceeding with my study. And while there’s some bickering here, I’ve already incorporated an assembly module into my code base and it works.
I managed to load the driver, and have it execute the assembly, and talk to my app.
Now comes the hard part.
And yes, it may not be feasible, but we cant conclude that based on conjecture or emotions. We can only conclude that by letting the rubber meet the road.

32

>>During the time the “unsecure OS” (linux or win) is running on the
platform, the image and data of the secureOS cannot physically reside on
that machine.

> it will have a way to retrieve the secureOS image (perhaps over a
network)

These two statements are curiosly at odds with one another and seemingly the
work of Sales & Marketing and not Engineering.

33

> the idea that this is somehow a Linux conspiracy is little over the top. I realize you don’t

mean that completely seriously, nevertheless, it is still there.

I don’t know about the “conspiracy”, but, objectively, doing these things under an open-source system must be, indeed, easier - once you have a source, you can modify and rebuild the kernel in such way that the system does everything it would normally do under the controlled shutdown, and then spawns the new OS. In other words, as long as you have an access to the OS source you can do everything safely. However, doing it safely under Windows is not the easiest task one would imagine…

Anton Bassov

34

Bob,
Whats the risk of that? Is the “load image callback” publicly advertised? Does the average driver register these callbacks? There will be a lot of time (in CPU terms) between the time my driver is loaded and the time it is called. If the user doesn’t see the secureOS loading, then he will know he has a corrupted system. And since the secureOS was never loaded, we wouldn’t be compromised, I think this would be more of a denial of service. Is that right?

35

On Jul 26, 2007, at 7:22 PM, xxxxx@gdc4s.com wrote:

“If you really want security with no other actors in the way,
perform a
PIXI (or whatever the acronym is) boot and grab the image off the
network and then use the TPM to validate the image before executing
it.”

Now that (PXE + TPM) IS part of the plan, after the kernel driver
has wrested control of the machine from the unsecureOS.

Not to take this any further off-topic than it is, but I’m curious
how you’re going to validate the image’s integrity after unsecureOS
has managed to download it (and presumably patch it, including
patching out all of the integrity checks, etc.). This also seems like
a good candidate for a blue pill.

If you’re curious to know whether or not that kind of attack is
within reach, check out the (different, but similar?) papers by
Skywing and Skape about disabling PatchGuard. As far as I know,
PatchGuard has never lasted more than about 3 days from the time
these guys got irritated enough with it to break it.

Then again, I’m no TPM expert, so perhaps I’m missing something?

-sd

36

Steve,

It’s not being downloaded by unsecureOS, but by the driver itself after unsecureOS is out of the picture. I’m just starting this study, so I haven’t worked out all the issues, but once the image is downloaded, we would measure it, and then use an attestation protocol to verify it.
My gut feeling is that our conclusion will be “thumbs down” on this whole idea, but I can’t be biased that way ahead of time :slight_smile:
Thanks

37

> It’s not being downloaded by unsecureOS, but by the driver itself after

unsecureOS is out of the picture.

Do you somehow realize that your driver just has no chance to run if “unsecureOS is out of the picture” - it is just impossible ( even theoretically) ??? Whatever your driver does, it has to make some system calls . If it does not rely upon the system-provided services, and, instead, starts dealing with all hardware devices and controllers on its own, it is already not a Windows driver but a full-blown custom OS, which simply defeats the purpose of your project - after all, the very idea of your project is to insure that a custom OS is not physically resident on the target machine.

Anton Bassov

38

anton,

The driver, yes, is complicated, but it is not an OS. it does not need to make systems calls.
It just needs to load another OS, which I already have an image of and which already has drivers for the platform.
I plan on switching back to Real Mode and pretending to be a BIOS.
My first cut, starting simple (not doing PXE yet), is I have two SATA disks in the platform. The BIOS will boot either one, it’s a BIOS selection. So, right now, I can boot whichever disk I want.
Disk 1 has “off the shelf” WinXP. Disk2 has the secureOS image and filesystem, ready to boot.
I installed Windows on disk 1 before putting the “previously built” disk 2 in the system.
I then put disk 2 in the system (with the secureOS image and filesystem). Now Windows says it found new hardware, but I say Cancel.
Then I run my WinApp, which calls WinDriver, which switches the platform to Real Mode (following Intels documented rules). I then get the MBR off the second disk. I load it at 7C00, and then I jump to it. This is the general plan so far, I have not worked out the details, I dont know if it will work, but I know I’m not going to try PXE if the two disks cant work. Unless there’s some other reason they both wont work!
The secureOS image is the entity which will do the SENTER and then load the MVMM, and the host OS. The secureOS image is already a working system on its own.
If this can work, we will try to do PXE over the network and get the image. That image will be configured to use NFS. I dont have that image yet anyway.
Any thoughts?

39

I’m taking the liberty to answer for Bob Kjelgaard.

Anthony Brown wrote:

Whats the risk of that?
As Doron Holan already said, all kernel modules share the same privilege level (like all monolithic kernels, e.g., Linux).
Consequently, any module can compromise the other module’s integrity if there is malicious intent.

Anthony Brown wrote:

Is the “load image callback” publicly advertised?
Yes, it is completely documented:
http://msdn2.microsoft.com/en-us/library/ms802949.aspx

Anthony Brown wrote:

Does the average driver register these callbacks?
No, I think “the average driver” doesn’t need such a callback.

40

Well, if our WinDriver is corrupted (such as to be non-functional) by another system driver, then it’s a denial of service, but not a compromise of our secureOS.
If the WinDriver can manage to run and successfully switch to real mode, then it will have succeeded.
Obvioulsy, the “2-disk” test run is insecure, because the untrusted “off the shelf” WinXP could have access to disk 2, before it is lauched. The PXE solution should resolve this problem, assuming only the WinDriver has credentials for that network interface over which the PXE boot takes place. I dont know how this happens yet.