[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 2/2] x86: allow Meltdown band-aid to be disabled

On Tue, Jan 16, 2018 at 12:21 PM, Juergen Gross <jgross@xxxxxxxx> wrote:
> On 16/01/18 13:12, George Dunlap wrote:
>> On Mon, Jan 15, 2018 at 11:07 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>> First of all we don't need it on AMD systems. Additionally allow its use
>>> to be controlled by command line option. For best backportability, this
>>> intentionally doesn't use alternative instruction patching to achieve
>>> the intended effect - while we likely want it, this will be later
>>> follow-up.
>> Is it worth making it optional to apply to dom0?  In most cases, if an
>> attacker can manage to get userspace on dom0, they should be able to
>> take over the whole system anyway; turning it off on dom0 to get
>> better performance seems like a policy decision that administrators
>> might reasonably make.
> You are implying here that Linux is insecure: why does userspace access
> allow you to take over the machine? I can see that being true for root
> access, but not for any other unprivileged user account.

Well first of all, go look at my talk about local root exploits in
Linux -- usually there are a few found every month.

But let's ignore that out for a minute.  Consider a "typical"
recommended dom0 setup:
- Dom0 on a separate network
- Nothing running on dom0 except Xen-related services, and toolstack

How would an attacker get userspace access on such a host at all?
- Attack a devicemodel running in dom0
- Attack a backend running in the kernel
- Attack xenstore

We don't yet have a deprivileged QEMu, so at the moment an attack on
any of these will already give you full control of the system.

Obviously this wouldn't be appropriate to all systems; but it could be
appropriate to a fair number of them.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.