Mailing List Archive

Meltdown effect on MythTV
Hello,

Anybody has a view how much effect will the Intel Meltdown bug will have on
a combined Myth FE/BE?

I have a new Intel system and was wondering whether to return it and
replace it with an AMD one.

Thanks
Re: Meltdown effect on MythTV [ In reply to ]
> On Jan 4, 2018, at 5:28 PM, Rajil Saraswat <rajil.s@gmail.com> wrote:
>
> Hello,
>
> Anybody has a view how much effect will the Intel Meltdown bug will have on a combined Myth FE/BE?
>
> I have a new Intel system and was wondering whether to return it and replace it with an AMD one.
>
> Thanks

Not sure if the problem isn’t also a problem for AMD. It seems all of the Processor vendors are working on common solutions so the O/S patches work on all systems. I’m only see high level reports, so not clear what it all means. Bottom line, is my Mythtv FE and BE still work.

Jim A

> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Meltdown effect on MythTV [ In reply to ]
Hoi Jim,

Thursday, January 4, 2018, 11:55:11 PM, you wrote:



>> On Jan 4, 2018, at 5:28 PM, Rajil Saraswat <rajil.s@gmail.com> wrote:
>>
>> Hello,
>>
>> Anybody has a view how much effect will the Intel Meltdown bug will have on a combined Myth FE/BE?
>>
>> I have a new Intel system and was wondering whether to return it and replace it with an AMD one.
>>
>> Thanks

> Not sure if the problem isn’t also a problem for AMD. It seems all
> of the Processor vendors are working on common solutions so the O/S
> patches work on all systems. I’m only see high level reports, so
> not clear what it all means. Bottom line, is my Mythtv FE and BE still work.

> Jim A

Meltdown seems so far only Intel related
Spectre affects Intel, AMD and Atom
Meltdown they so far think is software patchable
Spectre maybe is software patchable but has a lower risk as it is much
more difficult to exploit


Tot mails,
Hika mailto:hikavdh@gmail.com

"Zonder hoop kun je niet leven
Zonder leven is er geen hoop
Het eeuwige dilemma
Zeker als je hoop moet vernietigen om te kunnen overleven!"

De lerende Mens

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Meltdown effect on MythTV [ In reply to ]
Rajil Saraswat <rajil.s@gmail.com> wrote:

> Anybody has a view how much effect will the Intel Meltdown bug will have on a combined Myth FE/BE?
>
> I have a new Intel system and was wondering whether to return it and replace it with an AMD one.

As already said, it seems AMD didn't escape completely.
However, for a MythTV system, I wouldn't worry - it's not like you're going to be running random untrusted software is it ?

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Meltdown effect on MythTV [ In reply to ]
On Fri, Jan 5, 2018 at 6:04 AM Simon Hobson <linux@thehobsons.co.uk> wrote:

> Rajil Saraswat <rajil.s@gmail.com> wrote:
>
> > Anybody has a view how much effect will the Intel Meltdown bug will have
> on a combined Myth FE/BE?
> >
> > I have a new Intel system and was wondering whether to return it and
> replace it with an AMD one.
>
> As already said, it seems AMD didn't escape completely.
> However, for a MythTV system, I wouldn't worry - it's not like you're
> going to be running random untrusted software is it ?
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org


I'm sure the question is more in line with how much of a performance hit is
expected.



--
-Thomas
Re: Meltdown effect on MythTV [ In reply to ]
On 01/05/2018 08:03 AM, Simon Hobson wrote:
> Rajil Saraswat <rajil.s@gmail.com> wrote:
>
>> Anybody has a view how much effect will the Intel Meltdown bug will have on a combined Myth FE/BE?
>>
>> I have a new Intel system and was wondering whether to return it and replace it with an AMD one.
>
> As already said, it seems AMD didn't escape completely.
> However, for a MythTV system, I wouldn't worry - it's not like you're going to be running random untrusted software is it ?

I agree. Most of us have little worry about a bad piece of software probing
kernel space and grabbing a few bytes at a time. In any case, all 3 major
operating systems will soon have patches to fix Meltdown, which only affects
Intel CPUs. Just keep your system updated. The Spectre exploit affects Intel,
AMD, and ARM processors. Existing silicon cannot be fixed; however, reading
out-of-bounds memory using this exploit is very slow, and again our systems
hardly run random untrusted software.

Larry

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Meltdown effect on MythTV [ In reply to ]
More information concerning the Linux implementation for mitigation of Meltdown
is available. The info below is copied from https://lkml.org/lkml/2018/1/4/775.

Sorting through the jargon, your mileage will vary depending on what features
are found on your CPU.

A new kernel parameter is available called "pti" for Page Table Isolation. User
and kernel space will use separate page tables to prevent any user process from
using the side-channel approach. There will be a small performance hit and some
memory increases. The feature can be turned off at build or run time, and will
automatically be turned off for AMD processors.

The details of increased memory usage are as follows:

a. Each process now needs an order-1 page directory (PGD) instead of order-0.
(Consumes 4k per process).

b. The 'cpu_entry_area' structure must be 2MB in size and 2MB aligned so that it
can be mapped by setting a single Page Mid Directory (PMD) entry. This consumes
nearly 2MB of RAM once the kernel is decompressed, but no space in the kernel
image itself.

The details of CPU usage:

a. CR3 manipulation to switch between the page table copies
must be done at interrupt, syscall, and exception entry
and exit (it can be skipped when the kernel is interrupted,
though.) Moves to CR3 are on the order of a hundred
cycles, and are required every at entry and every at exit.
b. A "trampoline" must be used for SYSCALL entry. This
trampoline depends on a smaller set of resources than the
non-PTI SYSCALL entry code, so requires mapping fewer
things into the userspace page tables. The downside is
that stacks must be switched at entry time.
c. Global pages are disabled for all kernel structures not
mapped in both to kernel and userspace page tables. This
feature of the MMU allows different processes to share TLB
entries mapping the kernel. Losing the feature means more
TLB misses after a context switch. The actual loss of
performance is very small, however, never exceeding 1%.
d. Process Context IDentifiers (PCID) is a CPU feature that
allows us to skip flushing the entire TLB when switching page
tables. This makes switching the page tables (at context
switch, or kernel entry/exit) cheaper. But, on systems with
PCID support, the context switch code must flush both the user
and kernel entries out of the TLB. The user PCID TLB flush is
deferred until the exit to userspace, minimizing the cost.
e. The userspace page tables must be populated for each new
process. Even without PTI, the shared kernel mappings
are created by copying top-level (PGD) entries into each
new process. But, with PTI, there are now *two* kernel
mappings: one in the kernel page tables that maps everything
and one for the entry/exit structures. At fork(), we need to
copy both.
f. In addition to the fork()-time copying, there must also
be an update to the userspace PGD any time a set_pgd() is done
on a PGD used to map userspace. This ensures that the kernel
and userspace copies always map the same userspace
memory.
g. On systems without PCID support, each CR3 write flushes
the entire TLB. That means that each syscall, interrupt
or exception flushes the TLB.

Larry

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Meltdown effect on MythTV [ In reply to ]
On Friday, January 5, 2018 19:26 CET, Larry Finger <Larry.Finger@lwfinger.net> wrote:
 More information concerning the Linux implementation for mitigation of Meltdown
is available. The info below is copied from https://lkml.org/lkml/2018/1/4/775.

Sorting through the jargon, your mileage will vary depending on what features
are found on your CPU.

A new kernel parameter is available called "pti" for Page Table Isolation. User
and kernel space will use separate page tables to prevent any user process from
using the side-channel approach. There will be a small performance hit and some
memory increases. The feature can be turned off at build or run time, and will
automatically be turned off for AMD processors.

The details of increased memory usage are as follows:

a. Each process now needs an order-1 page directory (PGD) instead of order-0.
(Consumes 4k per process).

b. The 'cpu_entry_area' structure must be 2MB in size and 2MB aligned so that it
can be mapped by setting a single Page Mid Directory (PMD) entry. This consumes
nearly 2MB of RAM once the kernel is decompressed, but no space in the kernel
image itself.

The details of CPU usage:

a. CR3 manipulation to switch between the page table copies
must be done at interrupt, syscall, and exception entry
and exit (it can be skipped when the kernel is interrupted,
though.) Moves to CR3 are on the order of a hundred
cycles, and are required every at entry and every at exit.
b. A "trampoline" must be used for SYSCALL entry. This
trampoline depends on a smaller set of resources than the
non-PTI SYSCALL entry code, so requires mapping fewer
things into the userspace page tables. The downside is
that stacks must be switched at entry time.
c. Global pages are disabled for all kernel structures not
mapped in both to kernel and userspace page tables. This
feature of the MMU allows different processes to share TLB
entries mapping the kernel. Losing the feature means more
TLB misses after a context switch. The actual loss of
performance is very small, however, never exceeding 1%.
d. Process Context IDentifiers (PCID) is a CPU feature that
allows us to skip flushing the entire TLB when switching page
tables. This makes switching the page tables (at context
switch, or kernel entry/exit) cheaper. But, on systems with
PCID support, the context switch code must flush both the user
and kernel entries out of the TLB. The user PCID TLB flush is
deferred until the exit to userspace, minimizing the cost.
e. The userspace page tables must be populated for each new
process. Even without PTI, the shared kernel mappings
are created by copying top-level (PGD) entries into each
new process. But, with PTI, there are now *two* kernel
mappings: one in the kernel page tables that maps everything
and one for the entry/exit structures. At fork(), we need to
copy both.
f. In addition to the fork()-time copying, there must also
be an update to the userspace PGD any time a set_pgd() is done
on a PGD used to map userspace. This ensures that the kernel
and userspace copies always map the same userspace
memory.
g. On systems without PCID support, each CR3 write flushes
the entire TLB. That means that each syscall, interrupt
or exception flushes the TLB.

Larry

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.orgHi again,

In layman's terms, does this mean that we can, by using the boot-time kernel parameter "pti=disable" disable all the additional security (and potential system-overhead) in systems which we do not think are vulnerable?


Some of us are running mythtv on a minimum of hardware and would rather not take the hit.

BR.

--Marius--


 
Error 500: Internal Server Error | Gossamer Threads: Vancouver-based Web Technology Consultancy

Error: 500 Internal Server Error

Oops, server error!

Uh Oh! There has been a problem with the program you just accessed. Please wait a minute and try your request again, if the problem persists, please do contact us and we will look into it asap. In the meantime, you can continue exploring the website.