Hi Carl-Daniel,
Yep, the GART is one way to go. On the other hand, there are PCI-Express
systems that do not have a GART. The whole thing is a bit of a mess, which
is why I didn't expand on it.
Cheers,
Arvind
On Fri, 12 Jan 2007, Carl-Daniel Hailfinger wrote:
> Hi Arvind,
>
> Arvind Seshadri wro
Hi Arvind,
Arvind Seshadri wrote:
> Having an IOMMU is not necessary since our goal is only to prevent DMA
> write to a region of memory. We have come up with techniques that can
> prevent DMA writes on legacy systems without an IOMMU. Also, Pioneer is
That sounds interesting. Are you using the G
Hi Carl-Daniel,
Having an IOMMU is not necessary since our goal is only to prevent DMA
write to a region of memory. We have come up with techniques that can
prevent DMA writes on legacy systems without an IOMMU. Also, Pioneer is
not LinuxBIOS-specific. It can be incorporated into any SMM code.
Che
Hi Arvind,
Arvind Seshadri wrote:
> Pioneer provides the stronger guarantee that the program whose integrity
> is checked is the one that is invoked for execution. In other words, an
> attacker cannot modify the program between the time its integrity is
> checked and the time the program is invoke
Hi Carl-Daniel,
SEBOS is based on AEGIS, which is a secure bootstrap mechanism. As such,
SEBOS can only guarantee the integrity of what programs are loaded into
memory. This property is similar to that provided by the TCG trusted boot
specification and is called loadtime attestation.
Loadtime atte
Hi Arvind,
Arvind Seshadri wrote:
> Thanks for the clarification! The way SMI is handled in LinuxBIOS suits my
> purpose very well. I am working on a project called Pioneer, whose goal is
> to prevent any malware present on a computer from tampering with code
> execution (details can be found at
>
Thanks for the clarification! The way SMI is handled in LinuxBIOS suits my
purpose very well. I am working on a project called Pioneer, whose goal is
to prevent any malware present on a computer from tampering with code
execution (details can be found at
http://www.cs.cmu.edu/~arvinds/verifiable_co
* Arvind Seshadri <[EMAIL PROTECTED]> [061230 05:13]:
> BTW, I was looking over the datasheet for the AMD8111 southbridge and
> found that several sources can generate an SMI. There are enable bits for
> the individual SMI sources as well as a global SMI enable/disable bit.
> Given that LinuxBIOS d
I was going to say the same thing: SMM code is meant to the OS
independent since it emulates hardware functionality. But I agree with the
requirement for the code being reentrant since the trend is towards
multicore CPUs.
BTW, I was looking over the datasheet for the AMD8111 southbridge and
found
>> I would like to implement a piece of code as an SMM handler in
>> LinuxBIOS.
>
> I think the sensible way to do this is write an SMI handler that is
> controlled by Linux (or other OS). BIOS code should not run once the
> OS is up.
But SMM code isn't BIOS code -- it is "virtual hardware".
> T
On 12/24/06, Arvind Seshadri <[EMAIL PROTECTED]> wrote:
> Hi,
> I would like to implement a piece of code as an SMM handler in LinuxBIOS.
I think the sensible way to do this is write an SMI handler that is
controlled by Linux (or other OS). BIOS code should not run once the
OS is up. There are lot
Hi,
I would like to implement a piece of code as an SMM handler in LinuxBIOS.
>From what I understand of LinuxBIOS, there is no SMM handler at present
but the SMM registers on the AMD K8 platform are locked using the SMMLOCK
bit. How does the platform then handle SMI when using LinuxBIOS? I would
b
12 matches
Mail list logo
