As far as I know, the first partition does start from sec 64, so 0-63
gap is a typical of creating the MBR partition structure, has to do
with DOS compatibility. But I think Even with MBR you can create the
partition structure where the very first partition on the disk will
start at LBA 1, GUID partition tables do that I believe.
On 8/25/05, Gary G. Little wrote:
> And Phil just kicked me in the shins. It seems that there are user sectors
> that are generally not used, such as an area between LBA 0 and LBA 64.
> That’s an used area of 63 sectors. So I guess I stand corrected.
>
> –
> Gary G. Little
>
> “PeterGV (OSR)” wrote in message news:xxxxx@ntdev…
> > Gary G. Little wrote:
> >> Yes but … storing the data on the boot disk in one of the unused
> >> regions is fine … if they aren’t being used. Seagate trusted drives are
> >> now using those regions and will not allow an un-trusted write to those
> >> areas. The upside to that is that once you have established trust with
> >> the drive, you now have on-drive smartcard capability with multiple
> >> dCards.
> >>
> >
> > Interesting. Completely OT: Are there any white papers on all this stuff
> > Seagate’s doing? Encryption/trusted/etc?? Not that I’ve looked, but I’m
> > interested…
> >
> > Peter
> > OSR
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
–
- Developer
bad idea, any one can see what you are up to, also doesnt take much
time to change boot.ini bacl to normal again.
On 8/25/05, Faraz Ahmed wrote:
> Hi;
> You could try this out. Get the amount of RAM installed on
> the system say X MB. Start the kernel with /MAXMEM=X-1MB, there by
> reserving the Top 1 Mb of physical memory for your self. Then your
> driver can access this memory by MmGetVirtualForPhysical(there by also
> document this function).
>
> Regards
> Faraz.
>
> On 8/24/05, John White wrote:
> >
> >
> >
> > HI All,
> > We are designing an application where some data is to be passed from BIOS to
> > the Driver. The data is to reside on some location on the system RAM. Can
> > anyone help me in providing pointers as to how I can reserve some area in
> > RAM in BIOS and ensure that Windows OS (XP /2k) does not use / overwrite
> > that area and later my driver should be allowed to access this memory area.
> >
> > Should we create a device node in ACPI BIOS?
> >
> > Thanks in advance.
> >
> > regards,
> > john
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com — Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256 You are
> > currently subscribed to ntdev as: xxxxx@gmail.com To unsubscribe send
> > a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
see, even maxim thinks the same way.
On 8/25/05, Maxim S. Shatskih wrote:
> Your BIOS hook code can pose itself to the very top of the 640KB of low
> real-mode memory, hook int 11h and int 15h and pose itself as the EBIOS area
> not avaliable for the OS. If there was already the EBIOS area, then the hook
> code must extend it down.
>
> I think this will be the safe way.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
> ----- Original Message -----
> From: John White
> To: Windows System Software Devs Interest List
> Sent: Thursday, August 25, 2005 8:01 AM
> Subject: Re:[ntdev] Sharing memory between BIOS and Driver
>
>
> HI All,
> Thank you for your valuable suggestions.
>
> It looks like the best bet is the boot disk.
> regards,
> john
>
>
>
> “Gary G. Little” wrote:
> And Phil just kicked me in the shins. It seems that there are user sectors
> that are generally not used, such as an area between LBA 0 and LBA 64.
> That’s an used area of 63 sectors. So I guess I stand corrected.
>
> –
> Gary G. Little
>
> “PeterGV (OSR)” wrote in message news:xxxxx@ntdev…
> > Gary G. Little wrote:
> >> Yes but … storing the data on the boot disk in one of the unused
> >> regions is fine … if they aren’t being used. Seagate trusted drives are
> >> now using those regions and will not allow an un-trusted write to those
> >> areas. The upside to that is that once you have established trust with
> >> the drive, you now have on-drive smartcard capability with multiple
> >> dCards.
> >>
> >
> > Interesting. Completely OT: Are there any white papers on all this stuff
> > Seagate’s doing? Encryption/trusted/etc?? Not that I’ve looked, but I’m
> > interested…
> >
> > Peter
> > OSR
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@yahoo.com
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>
> ________________________________
> Start your day with Yahoo! - make it your home page — Questions? First
> check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256 You are
> currently subscribed to ntdev as: xxxxx@storagecraft.com To unsubscribe send
> a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
>
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
Correct, the GPT protective MBR starts from LBA 1. So the disk strategy
would require one solution for MBR disks and one for GPT. GPT disks
could simply allocate a small private partition for the data. Come to
think of it, the same strategy could be used for MBR disks. Writing to
“unused” locations, either on disk or in memory, is risky as anyone else
may be using the same strategy. At a minimum you want to make your
“unused” location look used or nonexistent.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Developer
Sent: Thursday, August 25, 2005 7:41 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Sharing memory between BIOS and Driver
As far as I know, the first partition does start from sec 64, so 0-63
gap is a typical of creating the MBR partition structure, has to do
with DOS compatibility. But I think Even with MBR you can create the
partition structure where the very first partition on the disk will
start at LBA 1, GUID partition tables do that I believe.
On 8/25/05, Gary G. Little wrote:
> And Phil just kicked me in the shins. It seems that there are user
sectors
> that are generally not used, such as an area between LBA 0 and LBA 64.
> That’s an used area of 63 sectors. So I guess I stand corrected.
>
> –
> Gary G. Little
>
> “PeterGV (OSR)” wrote in message news:xxxxx@ntdev…
> > Gary G. Little wrote:
> >> Yes but … storing the data on the boot disk in one of the unused
> >> regions is fine … if they aren’t being used. Seagate trusted
drives are
> >> now using those regions and will not allow an un-trusted write to
those
> >> areas. The upside to that is that once you have established trust
with
> >> the drive, you now have on-drive smartcard capability with multiple
> >> dCards.
> >>
> >
> > Interesting. Completely OT: Are there any white papers on all this
stuff
> > Seagate’s doing? Encryption/trusted/etc?? Not that I’ve looked, but
I’m
> > interested…
> >
> > Peter
> > OSR
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
–
- Developer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
mark,
in case of normal MBR disks, *eating* up partition for 300 Bytes (ref:
original post) could be expensive. After all we just have 4 enties to
make do with.
On 8/25/05, Roddy, Mark wrote:
> Correct, the GPT protective MBR starts from LBA 1. So the disk strategy
> would require one solution for MBR disks and one for GPT. GPT disks
> could simply allocate a small private partition for the data. Come to
> think of it, the same strategy could be used for MBR disks. Writing to
> “unused” locations, either on disk or in memory, is risky as anyone else
> may be using the same strategy. At a minimum you want to make your
> “unused” location look used or nonexistent.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Developer
> Sent: Thursday, August 25, 2005 7:41 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Sharing memory between BIOS and Driver
>
> As far as I know, the first partition does start from sec 64, so 0-63
> gap is a typical of creating the MBR partition structure, has to do
> with DOS compatibility. But I think Even with MBR you can create the
> partition structure where the very first partition on the disk will
> start at LBA 1, GUID partition tables do that I believe.
>
>
>
> On 8/25/05, Gary G. Little wrote:
> > And Phil just kicked me in the shins. It seems that there are user
> sectors
> > that are generally not used, such as an area between LBA 0 and LBA 64.
> > That’s an used area of 63 sectors. So I guess I stand corrected.
> >
> > –
> > Gary G. Little
> >
> > “PeterGV (OSR)” wrote in message news:xxxxx@ntdev…
> > > Gary G. Little wrote:
> > >> Yes but … storing the data on the boot disk in one of the unused
> > >> regions is fine … if they aren’t being used. Seagate trusted
> drives are
> > >> now using those regions and will not allow an un-trusted write to
> those
> > >> areas. The upside to that is that once you have established trust
> with
> > >> the drive, you now have on-drive smartcard capability with multiple
> > >> dCards.
> > >>
> > >
> > > Interesting. Completely OT: Are there any white papers on all this
> stuff
> > > Seagate’s doing? Encryption/trusted/etc?? Not that I’ve looked, but
> I’m
> > > interested…
> > >
> > > Peter
> > > OSR
> > >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> –
>
> - Developer
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag argument:
> ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
–
- Developer
also, the solution wont work if 4 partitions are defined already.
On 8/25/05, Developer wrote:
> mark,
>
> in case of normal MBR disks, eating up partition for 300 Bytes (ref:
> original post) could be expensive. After all we just have 4 enties to
> make do with.
>
>
>
> On 8/25/05, Roddy, Mark wrote:
> > Correct, the GPT protective MBR starts from LBA 1. So the disk strategy
> > would require one solution for MBR disks and one for GPT. GPT disks
> > could simply allocate a small private partition for the data. Come to
> > think of it, the same strategy could be used for MBR disks. Writing to
> > “unused” locations, either on disk or in memory, is risky as anyone else
> > may be using the same strategy. At a minimum you want to make your
> > “unused” location look used or nonexistent.
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Developer
> > Sent: Thursday, August 25, 2005 7:41 AM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] Sharing memory between BIOS and Driver
> >
> > As far as I know, the first partition does start from sec 64, so 0-63
> > gap is a typical of creating the MBR partition structure, has to do
> > with DOS compatibility. But I think Even with MBR you can create the
> > partition structure where the very first partition on the disk will
> > start at LBA 1, GUID partition tables do that I believe.
> >
> >
> >
> > On 8/25/05, Gary G. Little wrote:
> > > And Phil just kicked me in the shins. It seems that there are user
> > sectors
> > > that are generally not used, such as an area between LBA 0 and LBA 64.
> > > That’s an used area of 63 sectors. So I guess I stand corrected.
> > >
> > > –
> > > Gary G. Little
> > >
> > > “PeterGV (OSR)” wrote in message news:xxxxx@ntdev…
> > > > Gary G. Little wrote:
> > > >> Yes but … storing the data on the boot disk in one of the unused
> > > >> regions is fine … if they aren’t being used. Seagate trusted
> > drives are
> > > >> now using those regions and will not allow an un-trusted write to
> > those
> > > >> areas. The upside to that is that once you have established trust
> > with
> > > >> the drive, you now have on-drive smartcard capability with multiple
> > > >> dCards.
> > > >>
> > > >
> > > > Interesting. Completely OT: Are there any white papers on all this
> > stuff
> > > > Seagate’s doing? Encryption/trusted/etc?? Not that I’ve looked, but
> > I’m
> > > > interested…
> > > >
> > > > Peter
> > > > OSR
> > > >
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> >
> >
> > –
> >
> > - Developer
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: unknown lmsubst tag argument:
> > ‘’
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> > —
> > Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> –
>
> - Developer
>
–
- Developer
Suppose your hard disc provides you a mechanism that your driver could interrograte by presenting the proper credentials? Now you know that the “magic” word really is the “magic” word because the disc won’t give it to you unless you have the right credentials. Therefore your “magic” word can only be written by you and cannot be seen or modified by anyone but you. You also get secure storage much greater than 300 bytes.
–
The personal opinion of
Gary G. Little
“John White” wrote in message news:xxxxx@ntdev…
The program in BIOS has a magic word that a driver in the OS will need. So we are trying to figure out the best means of passing the data to the driver in the OS.
The size of data would be around 300 bytes.
We need to do this everytime the system boots.
We are planning to use an area of system RAM to be reserved for this purpose. Just looking for some easy way of reserving this memory so that the code changes in the BIOS is minimal. Wish if this could be done without changing the BIOS.
Thanks
regards,
john
“PeterGV (OSR)” wrote:
John White wrote:
>
> We are designing an application where some data is to be passed from
> BIOS to the Driver. The data is to reside on some location on the
> system RAM.
What are you actually trying to do? How MUCH data do you want to pass
from the BIOS to your driver, and how frequently do you want to do it?
The second part of your question (“the data is to reside on some
location on the system RAM”) presumes a solution… but there may be a
better way to accomplish what you are trying to do.
Peter
OSR
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@yahoo.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
------------------------------------------------------------------------------
Yahoo! Mail
Stay connected, organized, and protected. Take the tour
On 8/24/05, John White wrote:
The program in BIOS has a magic word that a driver in the OS will need. So
we are trying to figure out the best means of passing the data to the
driver
in the OS.
The size of data would be around 300 bytes.
We need to do this everytime the system boots.
We are planning to use an area of system RAM to be reserved for this
purpose. Just looking for some easy way of reserving this memory so that
the
code changes in the BIOS is minimal. Wish if this could be done without
changing the BIOS.
Thanks
regards,
john
John,
You can use an OEM-specific SMBIOS structures (types 128 through 256)
to pass information from the BIOS to your driver. Usually it is very
easy to dynamically add and modify SMBIOS structures.
Dmitriy Budko, VMware
The last time I did this (exactly for the reason that Peter suggests), I
found space in the first
page (0 … 4K) of physical memory. My driver, which was boot start and in
the food chain for the boot disk, was able to retrieve the information
planted by a custom boot program.
Don
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of PeterGV (OSR)
Sent: 24 August 2005 19:05
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Sharing memory between BIOS and Driver
John White wrote:
>
> The size of data would be around 300 bytes.
>
> We need to do this everytime the system boots.
>
> We are planning to use an area of system RAM to be reserved for this
> purpose. Just looking for some easy way of reserving this
memory so that
> the code changes in the BIOS is minimal. Wish if this could be done
> without changing the BIOS.
>
Sounds like the classic “we want to pass the encryption key from a
hooked BIOS INT 13 routine to the Windows storage filter
driver” problem.
Since this is a one-time-only thing on boot, then your best bet is
probably to just slap the data into a pre-defined location in
physical
memory (followed by some sort of checksum) and then retrieve the data
ASAP with a boot-loading driver.
No actual change to the BIOS code will be necessary in this case.
The downside of this approach (did I just answer a question
like this in
this forum recently??) is that whichever 300 bytes of memory
you decide
to use – based on empirical testing – it’s possible that a service
pack or OS release will eventually wind-up using that memory.
An alternative that’s commonly used is storing the data on
the boot disk
in one of the unused regions. Personally, I prefer that approach.
I wouldn’t go through the hassle of creating an ACPI device
and passing
the data out with a pre-defined method. That’s overkill in this
situation for sure.
Peter
OSR
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@careful.co.uk
To unsubscribe send a blank email to xxxxx@lists.osr.com