I need to write information to file on system shutdown when all file IO
finished.
Can’t do it during last chance shutdown notification since paging io still
active.
I think all file io for volume definitely finished when volume gets
mn_set_power with power.type SystemPowerState and power state
PowerSystemShutdown.
So my idea:
In volume filter during setPower dispatch build write irp for volume (to
previously saved cluster location for my file);
Send write irp to volume;
Return status_pending;
Send setPower irp down volume stack from write irp completion routine.
While it looks like valid approach I have some doubts. For example set
power for volumes with page file comes at dispatch level, and I am not sure
if write irp completion for my irp for such volume is guaranteed to be
called at dispatch.
Would be great to hear your opinions if i should follow that approach or if
I should move to some other solution.
Translation: “I want to write to the disk when nobody can write to the disk. But I only get a chance to write to the disk when others can write to the disk”.
NTFS should send you IRP_MJ_SHUTDOWN when the volume is already “locked” for writing and now if you send IRP_MJ_WRITE to NTFS, it returns STATUS_TOO_LATE error code. So, if you have pre-reserved some clusters on volume (maybe from IoRegisterShutdownNotification’s callback), you can send IRP_MJ_WRITE request to volume stack.
Unfortunately there are still some paging reads after shutdown irp.
Main goal is to wipe number of files with pattern on shutdown. While in
general this is not a problem, that is hard to perform correctly with page
file, since I can’t overwrite page file when some code still can be paged
in for execution.
On Tuesday, July 1, 2014, Petr Kurtin wrote:
> NTFS should send you IRP_MJ_SHUTDOWN when the volume is already “locked” > for writing and now if you send IRP_MJ_WRITE to NTFS, it returns > STATUS_TOO_LATE error code. So, if you have pre-reserved some clusters on > volume (maybe from IoRegisterShutdownNotification’s callback), you can send > IRP_MJ_WRITE request to volume stack. > > — > NTDEV is sponsored by OSR > > Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev > > OSR is HIRING!! See http://www.osr.com/careers > > 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 >
“Sergey Pisarev” wrote in message news:xxxxx@ntdev… Thank you Petr !
Unfortunately there are still some paging reads after shutdown irp. Main goal is to wipe number of files with pattern on shutdown. While in general this is not a problem, that is hard to perform correctly with page file, since I can’t overwrite page file when some code still can be paged in for execution.
On Tuesday, July 1, 2014, Petr Kurtin wrote:
NTFS should send you IRP_MJ_SHUTDOWN when the volume is already “locked” for writing and now if you send IRP_MJ_WRITE to NTFS, it returns STATUS_TOO_LATE error code. So, if you have pre-reserved some clusters on volume (maybe from IoRegisterShutdownNotification’s callback), you can send IRP_MJ_WRITE request to volume stack.
But windows does not wipe page file completely, only portions that can be
wiped safely at the early stage of shutdown.
Plus we can’t control number of write passes and pattern to write.
On Tuesday, July 1, 2014, Scott Noone wrote:
>
> > Any reason to not use the “zero pagefiles at shutdown” option? > > http://support.microsoft.com/kb/314834 > > > -scott > OSR > @OSRDrivers > > > “Sergey Pisarev” wrote in message > news:xxxxx@ntdev… > Thank you Petr ! > > Unfortunately there are still some paging reads after shutdown irp. > Main goal is to wipe number of files with pattern on shutdown. While in > general this is not a problem, that is hard to perform correctly with page > file, since I can’t overwrite page file when some code still can be paged > in for execution. > > On Tuesday, July 1, 2014, Petr Kurtin wrote: > > > NTFS should send you IRP_MJ_SHUTDOWN when the volume is already “locked” > for writing and now if you send IRP_MJ_WRITE to NTFS, it returns > STATUS_TOO_LATE error code. So, if you have pre-reserved some clusters on > volume (maybe from IoRegisterShutdownNotification’s callback), you can > send IRP_MJ_WRITE request to volume stack. > > > — NTDEV is sponsored by OSR > > Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev > > OSR is HIRING!! See http://www.osr.com/careers > > 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 > > > > – > Sent from Gmail Mobile > > — > NTDEV is sponsored by OSR > > Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev > > OSR is HIRING!! See http://www.osr.com/careers > > 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 >
Plus we can’t control number of write passes and pattern to write.
I think you need to bring yourself to year 2014 (heck, at least 2000) and realize that these are not your grandfather’s MFM floppy drives. These are PRML harddrives with separate read/write heads, and thin film coating which leaves no residue of previous data. Same for flash drives. No residue, as long as the page is erased. Which is a separate issue from simply overwriting it.
You want a secure box? Use TPM and secure boot with the boot encryption.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@broadcom.com
Sent: Tuesday, July 1, 2014 12:17 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Write to volume on system shutdown
Plus we can’t control number of write passes and pattern to write.
I think you need to bring yourself to year 2014 (heck, at least 2000) and realize that these are not your grandfather’s MFM floppy drives. These are PRML harddrives with separate read/write heads, and thin film coating which leaves no residue of previous data. Same for flash drives. No residue, as long as the page is erased. Which is a separate issue from simply overwriting it.
You want a secure box? Use TPM and secure boot with the boot encryption.
The only way you can be 100% sure that the last serviceable paging file I/O
occurred is to see an IRP_MJ_CLOSE for the paging file at the file system
level. Until that point, it’s possible that a paging file I/O could squeeze
in and be serviced.
For example, in your scenario there is a window if the paging file isn’t
closed. Someone could be executing pageable code in parallel with the set
power operation and trigger a page fault while you’re clearing the paging
file.
To demonstrate, here’s a quick experiment that forces the window (there are
of course other ways to do this):
Set a breakpoint in the VolSnap power handler (volsnap!VolSnapPower)
Wait for the Set Power for PowerSystemShutdown operation
Set a breakpoint in the NTFS path for paging file I/O (for confirmation
purposes)
kd> bp ntfs!ntfspagingfileio
Ask the debugger to page in the address, which results in a thread on the
target doing the work
kd> .pagein 8b6b5000
You need to continue execution (press ‘g’ ) for the pagein to be brought in. When the debugger breaks in again, the page will be present. kd> g
Breakpoint 2 hit Ntfs!NtfsPagingFileIo: 8204a029 68d8000000 push 0D8h
kd> g Break instruction exception - code 80000003 (first chance) nt!RtlpBreakWithStatusInstruction: 8136d3a4 cc int 3
7. Data is now in memory, paged in from the paging file. Note that the VolSnap driver is still in pre-processing of the Set Power, where you would presumably be doing the zeroing.
So, basically, you’re pretty out of luck without some coordination from the O/S. Make sure that you test whatever you come up with under heavy load with memory pressure, otherwise something that appears to work may just be bad luck.
I need to perform some extensive testing to see if paging is actually
possible after set_power without some external force.
For now i did some testing at pc with low amount of RAM. There were lots
of paging, but none since set_power came. It just looked natural that no io
can go to device when system powering down this device, so i didn’t test
that much.
On Wed, Jul 2, 2014 at 6:43 PM, Scott Noone wrote:
> The only way you can be 100% sure that the last serviceable paging file > I/O occurred is to see an IRP_MJ_CLOSE for the paging file at the file > system level. Until that point, it’s possible that a paging file I/O could > squeeze in and be serviced. > > For example, in your scenario there is a window if the paging file isn’t > closed. Someone could be executing pageable code in parallel with the set > power operation and trigger a page fault while you’re clearing the paging > file. > > To demonstrate, here’s a quick experiment that forces the window (there > are of course other ways to do this): > > 1. Set a breakpoint in the VolSnap power handler (volsnap!VolSnapPower) > > 2. Wait for the Set Power for PowerSystemShutdown operation > > 3. Turn the breakpoint into a “busypoint” (http://www.osronline.com/ > article.cfm?article=611) > > kd> r @$t0 = low(poi(@$ip)) > kd> ew @$ip 0xFEEB > kd> u @$ip > volsnap!VolSnapPower: > jmp volsnap!VolSnapPower (8290324c) > > 4. The Set Power IRP is now frozen. Next, find a paged out address that is > in a paging file (I scanned pageable image sections) > > kd> !pte 8b6b5000 > VA 8b6b5000 > PDE at C06022D8 PTE at C045B5A8 > contains 000000001D693863 contains 000051FE00004060 > pfn 1d693 —DA–KWEV not valid > PageFile: 0 > Offset: 51fe > Protect: 3 - ExecuteRead > > kd> dc 8b6b5000 > 8b6b5000 ??? ??? ??? ??? ??? > 8b6b5010 ??? ??? ??? ??? ??? > > 5. Set a breakpoint in the NTFS path for paging file I/O (for confirmation > purposes) > > kd> bp ntfs!ntfspagingfileio > > 6. Ask the debugger to page in the address, which results in a thread on > the target doing the work > > kd> .pagein 8b6b5000 > You need to continue execution (press ‘g’ ) for the pagein to be > brought in. When the debugger breaks in again, the page will be present. > kd> g > > Breakpoint 2 hit > Ntfs!NtfsPagingFileIo: > 8204a029 68d8000000 push 0D8h > > kd> k > ChildEBP RetAddr > Ntfs!NtfsPagingFileIo > Ntfs!NtfsFsdRead+0x2d2 > … > nt!IoPageRead+0x1e4 > nt!MiIssueHardFaultIO+0x50 > … > nt!MmPrefetchVirtualMemory+0x89 > nt!ExpWorkerThread+0x111 > > kd> g > Break instruction exception - code 80000003 (first chance) > nt!RtlpBreakWithStatusInstruction: > 8136d3a4 cc int 3 > > 7. Data is now in memory, paged in from the paging file. Note that the > VolSnap driver is still in pre-processing of the Set Power, where you would > presumably be doing the zeroing. > > kd> dc 8b6b5000 > 8b6b5000 00000000 ff8b0000 83ec8b55 c03318ec …U…3. > 8b6b5010 f6335756 8de87589 ababec7d 8bababab VW3…u…}… > > So, basically, you’re pretty out of luck without some coordination from > the O/S. Make sure that you test whatever you come up with under heavy load > with memory pressure, otherwise something that appears to work may just be > bad luck. > > -scott > OSR > @OSRDrivers > > > > > — > NTDEV is sponsored by OSR > > Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev > > OSR is HIRING!! See http://www.osr.com/careers > > 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 >
> The only way you can be 100% sure that the last serviceable paging file > I/O occurred is to see an IRP_MJ_CLOSE for the paging file at the file > system level. Until that point, it’s possible that a paging file I/O could > squeeze in and be serviced. > > For example, in your scenario there is a window if the paging file isn’t > closed. Someone could be executing pageable code in parallel with the set > power operation and trigger a page fault while you’re clearing the paging > file. > > To demonstrate, here’s a quick experiment that forces the window (there > are of course other ways to do this): > > 1. Set a breakpoint in the VolSnap power handler (volsnap!VolSnapPower) > > 2. Wait for the Set Power for PowerSystemShutdown operation > > 3. Turn the breakpoint into a “busypoint” (http://www.osronline.com/ > article.cfm?article=611) > > kd> r @$t0 = low(poi(@$ip)) > kd> ew @$ip 0xFEEB > kd> u @$ip > volsnap!VolSnapPower: > jmp volsnap!VolSnapPower (8290324c) > > 4. The Set Power IRP is now frozen. Next, find a paged out address that is > in a paging file (I scanned pageable image sections) > > kd> !pte 8b6b5000 > VA 8b6b5000 > PDE at C06022D8 PTE at C045B5A8 > contains 000000001D693863 contains 000051FE00004060 > pfn 1d693 —DA–KWEV not valid > PageFile: 0 > Offset: 51fe > Protect: 3 - ExecuteRead > > kd> dc 8b6b5000 > 8b6b5000 ??? ??? ??? ??? ??? > 8b6b5010 ??? ??? ??? ??? ??? > > 5. Set a breakpoint in the NTFS path for paging file I/O (for confirmation > purposes) > > kd> bp ntfs!ntfspagingfileio > > 6. Ask the debugger to page in the address, which results in a thread on > the target doing the work > > kd> .pagein 8b6b5000 > You need to continue execution (press ‘g’ ) for the pagein to be > brought in. When the debugger breaks in again, the page will be present. > kd> g > > Breakpoint 2 hit > Ntfs!NtfsPagingFileIo: > 8204a029 68d8000000 push 0D8h > > kd> k > ChildEBP RetAddr > Ntfs!NtfsPagingFileIo > Ntfs!NtfsFsdRead+0x2d2 > … > nt!IoPageRead+0x1e4 > nt!MiIssueHardFaultIO+0x50 > … > nt!MmPrefetchVirtualMemory+0x89 > nt!ExpWorkerThread+0x111 > > kd> g > Break instruction exception - code 80000003 (first chance) > nt!RtlpBreakWithStatusInstruction: > 8136d3a4 cc int 3 > > 7. Data is now in memory, paged in from the paging file. Note that the > VolSnap driver is still in pre-processing of the Set Power, where you would > presumably be doing the zeroing. > > kd> dc 8b6b5000 > 8b6b5000 00000000 ff8b0000 83ec8b55 c03318ec …U…3. > 8b6b5010 f6335756 8de87589 ababec7d 8bababab VW3…u…}… > > So, basically, you’re pretty out of luck without some coordination from > the O/S. Make sure that you test whatever you come up with under heavy load > with memory pressure, otherwise something that appears to work may just be > bad luck. > > -scott > OSR > @OSRDrivers > > > > — > NTDEV is sponsored by OSR > > Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev > > OSR is HIRING!! See http://www.osr.com/careers > > 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 >
Note that there is DO_POWER_PAGABLE flag
“Sergey Pisarev” wrote in message news:xxxxx@ntdev… Thank you Scott !
I need to perform some extensive testing to see if paging is actually possible after set_power without some external force. For now i did some testing at pc with low amount of RAM. There were lots of paging, but none since set_power came. It just looked natural that no io can go to device when system powering down this device, so i didn’t test that much.
On Wed, Jul 2, 2014 at 6:43 PM, Scott Noone wrote:
The only way you can be 100% sure that the last serviceable paging file I/O occurred is to see an IRP_MJ_CLOSE for the paging file at the file system level. Until that point, it’s possible that a paging file I/O could squeeze in and be serviced.
For example, in your scenario there is a window if the paging file isn’t closed. Someone could be executing pageable code in parallel with the set power operation and trigger a page fault while you’re clearing the paging file.
To demonstrate, here’s a quick experiment that forces the window (there are of course other ways to do this):
1. Set a breakpoint in the VolSnap power handler (volsnap!VolSnapPower)
2. Wait for the Set Power for PowerSystemShutdown operation
5. Set a breakpoint in the NTFS path for paging file I/O (for confirmation purposes)
kd> bp ntfs!ntfspagingfileio
6. Ask the debugger to page in the address, which results in a thread on the target doing the work
kd> .pagein 8b6b5000 You need to continue execution (press ‘g’ ) for the pagein to be brought in. When the debugger breaks in again, the page will be present. kd> g
Breakpoint 2 hit Ntfs!NtfsPagingFileIo: 8204a029 68d8000000 push 0D8h
kd> g Break instruction exception - code 80000003 (first chance) nt!RtlpBreakWithStatusInstruction: 8136d3a4 cc int 3
7. Data is now in memory, paged in from the paging file. Note that the VolSnap driver is still in pre-processing of the Set Power, where you would presumably be doing the zeroing.
So, basically, you’re pretty out of luck without some coordination from the O/S. Make sure that you test whatever you come up with under heavy load with memory pressure, otherwise something that appears to work may just be bad luck.
Not every thread in the system pays attention to power down notifications
and Windows doesn’t suspend every thread prior to the power down. So, if any
of those threads are running and touching pageable code/data they can
trigger a page fault.
Without your filter present, at that point their behavior is of course
non-deterministic: either they get their work done before power off or they
don’t. However, the issue is that with your filter they might page in
garbage and, if running in kernel mode, crash the machine. Very difficult to
test and/or reproduce as it would require just the right circumstances,
hence my point about testing this under load.
“Sergey Pisarev” wrote in message news:xxxxx@ntdev… Thank you Scott !
I need to perform some extensive testing to see if paging is actually possible after set_power without some external force. For now i did some testing at pc with low amount of RAM. There were lots of paging, but none since set_power came. It just looked natural that no io can go to device when system powering down this device, so i didn’t test that much.
On Wed, Jul 2, 2014 at 6:43 PM, Scott Noone wrote: The only way you can be 100% sure that the last serviceable paging file I/O occurred is to see an IRP_MJ_CLOSE for the paging file at the file system level. Until that point, it’s possible that a paging file I/O could squeeze in and be serviced.
For example, in your scenario there is a window if the paging file isn’t closed. Someone could be executing pageable code in parallel with the set power operation and trigger a page fault while you’re clearing the paging file.
To demonstrate, here’s a quick experiment that forces the window (there are of course other ways to do this):
1. Set a breakpoint in the VolSnap power handler (volsnap!VolSnapPower)
2. Wait for the Set Power for PowerSystemShutdown operation
5. Set a breakpoint in the NTFS path for paging file I/O (for confirmation purposes)
kd> bp ntfs!ntfspagingfileio
6. Ask the debugger to page in the address, which results in a thread on the target doing the work
kd> .pagein 8b6b5000 You need to continue execution (press ‘g’ ) for the pagein to be brought in. When the debugger breaks in again, the page will be present. kd> g
Breakpoint 2 hit Ntfs!NtfsPagingFileIo: 8204a029 68d8000000 push 0D8h
kd> g Break instruction exception - code 80000003 (first chance) nt!RtlpBreakWithStatusInstruction: 8136d3a4 cc int 3
7. Data is now in memory, paged in from the paging file. Note that the VolSnap driver is still in pre-processing of the Set Power, where you would presumably be doing the zeroing.
So, basically, you’re pretty out of luck without some coordination from the O/S. Make sure that you test whatever you come up with under heavy load with memory pressure, otherwise something that appears to work may just be bad luck.
