On Thu, Oct 14, 2021 at 10:50:59PM -0700, Andi Kleen wrote:
>
> > I thought you basically create an OperationRegion of SystemMemory type,
> > and off you go. Maybe the OSPM in Linux is clever and protects
> > some memory, I wouldn't know.
>
>
> I investigated this now, and it looks like acpi is
I thought you basically create an OperationRegion of SystemMemory type,
and off you go. Maybe the OSPM in Linux is clever and protects
some memory, I wouldn't know.
I investigated this now, and it looks like acpi is using
ioremap_cache(). We can hook into that and force non sharing. It's
On Tue, Oct 12, 2021 at 02:18:01PM -0700, Andi Kleen wrote:
>
> > Interesting. VT-d tradeoffs ... what are they?
>
> The connection to the device is not encrypted and also not authenticated.
>
> This is different that even talking to the (untrusted) host through shared
> memory where you at
Interesting. VT-d tradeoffs ... what are they?
The connection to the device is not encrypted and also not authenticated.
This is different that even talking to the (untrusted) host through
shared memory where you at least still have a common key.
Allowing hypervisor to write into BIOS
On Tue, Oct 12, 2021 at 10:55:20AM -0700, Andi Kleen wrote:
>
> > I mean ... it's already wide spread.
>
>
> I meant wide spread usage with confidential guests.
>
> > If we support it with TDX
> > it will be used with TDX.
>
> It has some security trade offs. The main reason to use TDX is
I mean ... it's already wide spread.
I meant wide spread usage with confidential guests.
If we support it with TDX
it will be used with TDX.
It has some security trade offs. The main reason to use TDX is security.
Also when people take the VT-d tradeoffs they might be ok with the BIOS
On Mon, Oct 11, 2021 at 10:35:18AM -0700, Andi Kleen wrote:
>
> > Presumably bios code is in arch/x86 and drivers/acpi, right?
> > Up to 200 calls the majority of which is likely private ...
>
> Yes.
>
> > I don't have better ideas but the current setup will just
> > result in people making
Presumably bios code is in arch/x86 and drivers/acpi, right?
Up to 200 calls the majority of which is likely private ...
Yes.
I don't have better ideas but the current setup will just
result in people making their guests vulnerable whenever they
want to allow device pass-through.
Yes
On Sun, Oct 10, 2021 at 07:39:55PM -0700, Andi Kleen wrote:
>
> > The connection is quite unfortunate IMHO.
> > Can't there be an option
> > that unbreaks drivers *without* opening up security holes by
> > making BIOS shared?
>
> That would require new low level APIs that distinguish both cases,
The connection is quite unfortunate IMHO.
Can't there be an option
that unbreaks drivers *without* opening up security holes by
making BIOS shared?
That would require new low level APIs that distinguish both cases, and a
tree sweep.
-Andi
___
On Fri, Oct 08, 2021 at 05:37:11PM -0700, Kuppuswamy Sathyanarayanan wrote:
> + ioremap_force_shared= [X86_64, CCG]
> + Force the kernel to use shared memory mappings which do
> + not use ioremap_host_shared/pcimap_host_shared to opt-in
> +
On 10/8/21 5:37 PM, Kuppuswamy Sathyanarayanan wrote:
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 91ba391f9b32..0af19cb1a28c 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++
12 matches
Mail list logo
