On Thu, Jan 4, 2018 at 5:54 PM, Thomas Gleixner <[email protected]> wrote:
> On Thu, 4 Jan 2018, Jon Masters wrote:
>> P.S. I've an internal document where I've been tracking "nice to haves"
>> for later, and one of them is whether it makes sense to tag binaries as
>> "trusted" (e.g. extended attribute, label, whatever). It was something I
>> wanted to bring up at some point as potentially worth considering.
>
> Scratch that. There is no such thing as a trusted binary.
>
I disagree. When there are patches that slow execution down up to 30%,
I want to be able to mark a binary as "trusted" so that I can run it
without those patches if it is important. This is a boon to
configurability and helps lessen the significant performance impact of
these patches. Besides, anything run as root can already not only
read, but also write kernel memory and other processes' memory, so
it's not like this particular ability for processes trusted by the
user is anything new. This flag should probably only be settable by
root though, for obvious reasons.
On Sat, Jan 06, 2018 at 10:04:26PM -0700, Kiernan Hager wrote:
> On Thu, Jan 4, 2018 at 5:54 PM, Thomas Gleixner <[email protected]> wrote:
> > On Thu, 4 Jan 2018, Jon Masters wrote:
> >> P.S. I've an internal document where I've been tracking "nice to haves"
> >> for later, and one of them is whether it makes sense to tag binaries as
> >> "trusted" (e.g. extended attribute, label, whatever). It was something I
> >> wanted to bring up at some point as potentially worth considering.
> >
> > Scratch that. There is no such thing as a trusted binary.
> >
>
> I disagree. When there are patches that slow execution down up to 30%,
> I want to be able to mark a binary as "trusted" so that I can run it
> without those patches if it is important. This is a boon to
> configurability and helps lessen the significant performance impact of
> these patches. Besides, anything run as root can already not only
> read, but also write kernel memory and other processes' memory, so
> it's not like this particular ability for processes trusted by the
> user is anything new. This flag should probably only be settable by
> root though, for obvious reasons.
I think everyone agrees on this, but most developers are still very
busy trying to get all issues addressed first. We should simply start
to work in parallel on what could consistute the next steps without
polluting them.
BTW the performance loss can be even worse, I have a packet generator
here whose performance was divided by 4 in a VM :-) No tests yet on
bare metal (it's easier to reboot a VM).
Willy
> I disagree. When there are patches that slow execution down up to 30%,
> I want to be able to mark a binary as "trusted" so that I can run it
It's not a binary that is trusted - it's a binary in a given use case.
You could easily have the same binary being run in two situations on the
same box at the same time and run just one of them 'trusted'.
On Sun, Jan 07, 2018 at 02:01:38PM +0000, Alan Cox wrote:
> > I disagree. When there are patches that slow execution down up to 30%,
> > I want to be able to mark a binary as "trusted" so that I can run it
>
> It's not a binary that is trusted - it's a binary in a given use case.
> You could easily have the same binary being run in two situations on the
> same box at the same time and run just one of them 'trusted'.
That's what I like with the prctl approach. This can end up as a config
option in the application itself. At least I'd see it like this in
haproxy. Basically :
- start it with enough privileges (always the case to warrant chroot()
then setuid())
- if config option "disable-kpti" is set, run prctl() to disable it.
It is sufficiently inconvenient to ensure that it's only done where
relevant and regardless of the executable itself (ie it should not be
an xattr on the FS for example).
Willy
Make sure that your patches do not affect AMD CPU,
because they are unaffected by Meltdown vulnerability
for which this "30% slowdown Intel patch" is required
All your security patches regarding Meltdown should be like:
*) if its Intel, it is " cpu_insecure " ==> take a safe and slow route
*) if its AMD, it is " secure cpu " ==> take a normal route
AMD users should not suffer because of Intel screwups.
if Intel is responsible they should accept the CPU returns
Best regards
Ivan Ivanov,
coreboot developer and
open source enthusiast
<div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br /> <table
style="border-top: 1px solid #D3D4DE;">
<tr>
<td style="width: 55px; padding-top: 18px;"><a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail"
target="_blank"><img
src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif"
alt="" width="46" height="29" style="width: 46px; height: 29px;"
/></a></td>
<td style="width: 470px; padding-top: 17px; color: #41424e;
font-size: 13px; font-family: Arial, Helvetica, sans-serif;
line-height: 18px;">Без вирусов. <a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail"
target="_blank" style="color: #4453ea;">http://www.avast.ru</a> </td>
</tr>
</table>
<a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"></a></div>
2018-01-07 20:47 GMT+03:00 Willy Tarreau <[email protected]>:
> On Sun, Jan 07, 2018 at 02:01:38PM +0000, Alan Cox wrote:
>> > I disagree. When there are patches that slow execution down up to 30%,
>> > I want to be able to mark a binary as "trusted" so that I can run it
>>
>> It's not a binary that is trusted - it's a binary in a given use case.
>> You could easily have the same binary being run in two situations on the
>> same box at the same time and run just one of them 'trusted'.
>
> That's what I like with the prctl approach. This can end up as a config
> option in the application itself. At least I'd see it like this in
> haproxy. Basically :
> - start it with enough privileges (always the case to warrant chroot()
> then setuid())
>
> - if config option "disable-kpti" is set, run prctl() to disable it.
>
>
> It is sufficiently inconvenient to ensure that it's only done where
> relevant and regardless of the executable itself (ie it should not be
> an xattr on the FS for example).
>
> Willy
On Sun, 2018-01-07 at 21:01 +0300, Ivan Ivanov wrote:
> Make sure that your patches do not affect AMD CPU,
> because they are unaffected by Meltdown vulnerability
> for which this "30% slowdown Intel patch" is required
These patches *do* affect AMD CPUs, because they address one of the
issues for which AMD CPUs are also vulnerable.
![https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif"](https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif"){kind=link}