All of lore.kernel.org
 help / color / mirror / Atom feed
* Possible to prevent dom0 accessing guest memory?
@ 2016-11-14 14:51 Andy Smith
  2016-11-14 15:06 ` Andrew Cooper
  0 siblings, 1 reply; 5+ messages in thread
From: Andy Smith @ 2016-11-14 14:51 UTC (permalink / raw)
  To: xen-devel

Hello,

Please forgive me if this is a naive question but I do not know this
low-level stuff very well.

If the ability of the toolstack to dump a guest's memory (e.g. xl
dump-core) were disabled on the hypervisor side, would there be any
other way to do so from dom0 without rebooting the machine into a
hypervisor that had the capability re-enabled?

I understand dom0 has privileges to map devices to guests; does that
give it a way to read arbitrary memory without need of toolstack
support?

The purpose of my question is in seeing if disk encryption in VMs
can be made slightly more useful. If there were no way for root in
dom0 to read guest memory without rebooting into a different
hypervisor then I think that would be a useful step.

Cheers,
Andy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Possible to prevent dom0 accessing guest memory?
  2016-11-14 14:51 Possible to prevent dom0 accessing guest memory? Andy Smith
@ 2016-11-14 15:06 ` Andrew Cooper
  2016-11-14 15:29   ` Andy Smith
  0 siblings, 1 reply; 5+ messages in thread
From: Andrew Cooper @ 2016-11-14 15:06 UTC (permalink / raw)
  To: Andy Smith, xen-devel

On 14/11/16 14:51, Andy Smith wrote:
> Hello,
>
> Please forgive me if this is a naive question but I do not know this
> low-level stuff very well.
>
> If the ability of the toolstack to dump a guest's memory (e.g. xl
> dump-core) were disabled on the hypervisor side, would there be any
> other way to do so from dom0 without rebooting the machine into a
> hypervisor that had the capability re-enabled?
>
> I understand dom0 has privileges to map devices to guests; does that
> give it a way to read arbitrary memory without need of toolstack
> support?
>
> The purpose of my question is in seeing if disk encryption in VMs
> can be made slightly more useful. If there were no way for root in
> dom0 to read guest memory without rebooting into a different
> hypervisor then I think that would be a useful step.

You have misunderstood a step.

Dom0 can map all of guest memory.  This is how `xl dump-core` is
implemented, as well as how Qemu emulates devices for the guest.

However, it is also a strict requirement for Dom0 to construct the
domain in the first place, so you can't simply disable it in the
hypervisor and end up with a working system.

Even if it were possible to exclude this in Xen, Dom0 by default has a
number of powers which can alter hypervisor code, such as loading a
crash kernel or a livepatch.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Possible to prevent dom0 accessing guest memory?
  2016-11-14 15:06 ` Andrew Cooper
@ 2016-11-14 15:29   ` Andy Smith
  2016-11-14 17:09     ` George Dunlap
  0 siblings, 1 reply; 5+ messages in thread
From: Andy Smith @ 2016-11-14 15:29 UTC (permalink / raw)
  To: xen-devel

Hi Andrew,

On Mon, Nov 14, 2016 at 03:06:12PM +0000, Andrew Cooper wrote:
> You have misunderstood a step.
> 
> Dom0 can map all of guest memory.  This is how `xl dump-core` is
> implemented, as well as how Qemu emulates devices for the guest.

Ah, okay, thanks. That is what I feared.

Due to details of the legal jurisdiction in which I operate, it
would actually be useful to me to disable xl dump-core and be able
to truthfully state that I do not know how to obtain a dump of a
guest's memory. As it stands I do know that xl dump-core exists and
I can be compelled to run it. I do not personally know how to write
a program to do what xl dump-core does and would have no interest in
finding out.

But I appreciate that the more general concern would be an attacker
who gains root access, and they could just run such a program, so I
guess Xen developers would see little point in offering a way to
disable dump-core.

Cheers,
Andy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Possible to prevent dom0 accessing guest memory?
  2016-11-14 15:29   ` Andy Smith
@ 2016-11-14 17:09     ` George Dunlap
  2016-11-14 20:35       ` Andy Smith
  0 siblings, 1 reply; 5+ messages in thread
From: George Dunlap @ 2016-11-14 17:09 UTC (permalink / raw)
  To: Andy Smith; +Cc: xen-devel

On Mon, Nov 14, 2016 at 3:29 PM, Andy Smith <andy@strugglers.net> wrote:
> Hi Andrew,
>
> On Mon, Nov 14, 2016 at 03:06:12PM +0000, Andrew Cooper wrote:
>> You have misunderstood a step.
>>
>> Dom0 can map all of guest memory.  This is how `xl dump-core` is
>> implemented, as well as how Qemu emulates devices for the guest.
>
> Ah, okay, thanks. That is what I feared.
>
> Due to details of the legal jurisdiction in which I operate, it
> would actually be useful to me to disable xl dump-core and be able
> to truthfully state that I do not know how to obtain a dump of a
> guest's memory. As it stands I do know that xl dump-core exists and
> I can be compelled to run it. I do not personally know how to write
> a program to do what xl dump-core does and would have no interest in
> finding out.
>
> But I appreciate that the more general concern would be an attacker
> who gains root access, and they could just run such a program, so I
> guess Xen developers would see little point in offering a way to
> disable dump-core.

I don't think we've had someone before ask us to remove functionality
so that they can't be ordered to run it; but if that would be of
service to some of our users, there's no inherent reason we couldn't
take a look to see how difficult it would be to implement.

So is the basic situation that you can be asked to run commands, but
that you can't be asked to implement new functionality, or re-compile
and reboot your host?

Removing the dump-core functionality from xl should be pretty
straightforward.  With very little effort I could send you a patch you
could apply locally that would simply delete the code which implements
that command in xl. It would also be simple enough to make a config
option that would disable building that command in xl.

Would either of those suffice?

There is probably a way to configure Xen to make it possible to build
domains while making a full dump-core difficult to implement even by a
motivated attacker; but that would be quite a bit more work (and very
bespoke to your own particular situation).

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Possible to prevent dom0 accessing guest memory?
  2016-11-14 17:09     ` George Dunlap
@ 2016-11-14 20:35       ` Andy Smith
  0 siblings, 0 replies; 5+ messages in thread
From: Andy Smith @ 2016-11-14 20:35 UTC (permalink / raw)
  To: xen-devel

Hi George,

On Mon, Nov 14, 2016 at 05:09:01PM +0000, George Dunlap wrote:
> There is probably a way to configure Xen to make it possible to build
> domains while making a full dump-core difficult to implement even by a
> motivated attacker; but that would be quite a bit more work (and very
> bespoke to your own particular situation).

I think if it could be made extremely difficult for a compromised
dom0 to dump guest memory then that would be useful to a wide range
of Xen users, as compromise of general purpose Linux hosts (like
most people's dom0s) is pretty commonplace.

Though I was reminded off-list (thanks for that), that Intel SGX and
AMD SME include features which can protect guest memory from other
guests/host/dom0, so perhaps that is a more sensible direction to go
in.

Thanks,
Andy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2016-11-14 20:35 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-11-14 14:51 Possible to prevent dom0 accessing guest memory? Andy Smith
2016-11-14 15:06 ` Andrew Cooper
2016-11-14 15:29   ` Andy Smith
2016-11-14 17:09     ` George Dunlap
2016-11-14 20:35       ` Andy Smith

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.