[Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?
Joel Wirāmu Pauling
joel at aenertia.net
Thu Jan 4 17:13:32 EST 2018
Talking cross purposes here ; I am merely pointing out WHY it's a problem
in the routing world.
I also have coloured books from my past, they mostly involve bad 80's
Children's TV series tie ins and 'between the lines' style instructions.
-Joel
On 5 January 2018 at 11:09, dpreed at deepplum.com <dpreed at deepplum.com> wrote:
> I don't disagree that anyone who can run code in the hypervisor itself can
> attack the guest instances.
>
>
>
> But that has nothing to do with KALSR or Meltdown or Sceptre. That's just
> bad security design - the rule is "the principle of least privilege", which
> comes from the 1970's work on secure operating systems.
>
>
>
> I should point out here that I was one of the researchers that helped
> develop the original multi-level security systems then. Those "colored
> books" come from us.
>
>
>
> -----Original Message-----
> From: "Joel Wirāmu Pauling" <joel at aenertia.net>
> Sent: Thursday, January 4, 2018 5:00pm
> To: "dpreed at deepplum.com" <dpreed at deepplum.com>
> Cc: "Jonathan Morton" <chromatix99 at gmail.com>, cerowrt-devel at lists.
> bufferbloat.net
> Subject: Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches
> than x86?
>
> SRIOV ports and Vendor NIC optimizations wrt Latencies.
>
> Whilst these heavy hitting NVF appliances tend to be large and span
> multiple compute hosts (and therefore are the only tenannts on those
> computes) - this isn't always the case.
>
> It's a problem in that if you can get onto the hypervisor even as an
> unprivileged user you can read out guest stores. .... Big Problem.
>
> On 5 January 2018 at 10:57, dpreed at deepplum.com <dpreed at deepplum.com>
> wrote:
>
>> Hmm... protection datacentres tend to require lower latencies than can be
>> achieved running on hypervisors.
>>
>>
>>
>> Which doesn't mean that some datacenters don't do that.
>>
>>
>>
>> As far as NFV is concerned, Meltdown only breaks security if a userspace
>> application is running on a machine where another user has data running
>> through kernel address space. NFV environments don't tend to run NFV in
>> userspace under an OS that has kernel data in the page tables that are
>> reachable from CR3.
>>
>>
>>
>> The key issue in Meltdown is that CR3 is not changed between userspace
>> and kernelspace. Which means that the memory access pipeline in userspace
>> can use a kernelspace address (what Intel calls a "linear" address) without
>> a check that the pagetables enable userspace access. The check happens
>> after the speculative execution of the memory access.
>>
>>
>>
>> I repeat this, because many pseudo-experts who love to be quoted in the
>> press as saying "be afraid, be very afraid" are saying a lot of nonsense
>> about Meltdown and Sceptre. It seems to be an echo chamber effect - the
>> papers were released yesterday afternoon, but in a rush to get "quoted",
>> all the wannabe-quoted people are saying things that are just plain NOT
>> TRUE.
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: "Joel Wirāmu Pauling" <joel at aenertia.net>
>> Sent: Thursday, January 4, 2018 4:44pm
>> To: "Jonathan Morton" <chromatix99 at gmail.com>
>> Cc: cerowrt-devel at lists.bufferbloat.net
>> Subject: Re: [Cerowrt-devel] KASLR: Do we have to worry about other
>> arches than x86?
>>
>>
>> On 5 January 2018 at 01:09, Jonathan Morton <chromatix99 at gmail.com>
>> wrote:
>>
>>>
>>>
>>> I don't think we need to worry about it too much in a router context.
>>> Virtual server folks, OTOH...
>>>
>>> - Jonathan Morton
>>>
>>> Disagree - The Router is pretty much synonymous with NFV
>>
>> ; I run my lede instances at home on hypervisors - and this is
>> definitely the norm in Datacentres now. We need to work through this quite
>> carefully.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20180105/8b4accd8/attachment.html>
More information about the Cerowrt-devel
mailing list