Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1252395 > unrolled thread

Re: [PATCH v8 06/14] task_isolation: provide strict mode configurable signal

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v8 06/14] task_isolation: provide strict mode  configurable signal Steven Rostedt <rostedt@goodmis.org> - 2015-10-21 03:00 +0200
    Re: [PATCH v8 06/14] task_isolation: provide strict mode configurable  signal Chris Metcalf <cmetcalf@ezchip.com> - 2015-10-21 03:40 +0200
      Re: [PATCH v8 06/14] task_isolation: provide strict mode  configurable signal Steven Rostedt <rostedt@goodmis.org> - 2015-10-21 03:50 +0200
      Re: [PATCH v8 06/14] task_isolation: provide strict mode configurable signal Andy Lutomirski <luto@amacapital.net> - 2015-10-21 03:50 +0200
        RE: [PATCH v8 06/14] task_isolation: provide strict mode configurable  signal Gilad Ben Yossef <giladb@ezchip.com> - 2015-10-21 09:20 +0200
          Re: [PATCH v8 06/14] task_isolation: provide strict mode configurable signal Andy Lutomirski <luto@amacapital.net> - 2015-10-21 21:00 +0200
            Re: [PATCH v8 06/14] task_isolation: provide strict mode configurable signal Andy Lutomirski <luto@amacapital.net> - 2015-10-22 23:10 +0200
            RE: [PATCH v8 06/14] task_isolation: provide strict mode configurable  signal Gilad Ben Yossef <giladb@ezchip.com> - 2015-10-24 11:20 +0200

#1252395 — Re: [PATCH v8 06/14] task_isolation: provide strict mode configurable signal

On Tue, 20 Oct 2015 16:36:04 -0400
Chris Metcalf <cmetcalf@ezchip.com> wrote:

> Allow userspace to override the default SIGKILL delivered
> when a task_isolation process in STRICT mode does a syscall
> or otherwise synchronously enters the kernel.
> 

Is this really a good idea? This means that there's no way to terminate
a task in this mode, even if it goes astray.

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1252408 — Re: [PATCH v8 06/14] task_isolation: provide strict mode configurable signal

On 10/20/2015 8:56 PM, Steven Rostedt wrote:
> On Tue, 20 Oct 2015 16:36:04 -0400
> Chris Metcalf <cmetcalf@ezchip.com> wrote:
>
>> Allow userspace to override the default SIGKILL delivered
>> when a task_isolation process in STRICT mode does a syscall
>> or otherwise synchronously enters the kernel.
>>
> Is this really a good idea? This means that there's no way to terminate
> a task in this mode, even if it goes astray.

It doesn't map SIGKILL to some other signal unconditionally.  It just allows
the "hey, you broke the STRICT contract and entered the kernel" signal
to be something besides the default SIGKILL.

-- 
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1252415

On Tue, 20 Oct 2015 21:30:36 -0400
Chris Metcalf <cmetcalf@ezchip.com> wrote:

> On 10/20/2015 8:56 PM, Steven Rostedt wrote:
> > On Tue, 20 Oct 2015 16:36:04 -0400
> > Chris Metcalf <cmetcalf@ezchip.com> wrote:
> >
> >> Allow userspace to override the default SIGKILL delivered
> >> when a task_isolation process in STRICT mode does a syscall
> >> or otherwise synchronously enters the kernel.
> >>
> > Is this really a good idea? This means that there's no way to terminate
> > a task in this mode, even if it goes astray.
> 
> It doesn't map SIGKILL to some other signal unconditionally.  It just allows
> the "hey, you broke the STRICT contract and entered the kernel" signal
> to be something besides the default SIGKILL.
> 

Ah, I misread the change log. Now looking at the actual code, it makes
sense. Sorry for the noise ;-)

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1252416 — Re: [PATCH v8 06/14] task_isolation: provide strict mode configurable signal

On Tue, Oct 20, 2015 at 6:30 PM, Chris Metcalf <cmetcalf@ezchip.com> wrote:
> On 10/20/2015 8:56 PM, Steven Rostedt wrote:
>>
>> On Tue, 20 Oct 2015 16:36:04 -0400
>> Chris Metcalf <cmetcalf@ezchip.com> wrote:
>>
>>> Allow userspace to override the default SIGKILL delivered
>>> when a task_isolation process in STRICT mode does a syscall
>>> or otherwise synchronously enters the kernel.
>>>
>> Is this really a good idea? This means that there's no way to terminate
>> a task in this mode, even if it goes astray.
>
>
> It doesn't map SIGKILL to some other signal unconditionally.  It just allows
> the "hey, you broke the STRICT contract and entered the kernel" signal
> to be something besides the default SIGKILL.
>

...which has the odd side effect that sending a non-fatal signal from
another process will cause the strict process to enter the kernel and
receive an extra signal.

I still dislike this thing.  It seems like a debugging feature being
implemented using signals instead of existing APIs.  I *still* don't
see why perf can't be used to accomplish your goal.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1252507 — RE: [PATCH v8 06/14] task_isolation: provide strict mode configurable signal

DQoNCj4gRnJvbTogQW5keSBMdXRvbWlyc2tpIFttYWlsdG86bHV0b0BhbWFjYXBpdGFsLm5ldF0N
Cj4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDIxLCAyMDE1IDQ6NDMgQU0NCj4gVG86IENocmlz
IE1ldGNhbGYNCj4gU3ViamVjdDogUmU6IFtQQVRDSCB2OCAwNi8xNF0gdGFza19pc29sYXRpb246
IHByb3ZpZGUgc3RyaWN0IG1vZGUNCj4gY29uZmlndXJhYmxlIHNpZ25hbA0KPiANCj4gT24gVHVl
LCBPY3QgMjAsIDIwMTUgYXQgNjozMCBQTSwgQ2hyaXMgTWV0Y2FsZiA8Y21ldGNhbGZAZXpjaGlw
LmNvbT4NCj4gd3JvdGU6DQo+ID4gT24gMTAvMjAvMjAxNSA4OjU2IFBNLCBTdGV2ZW4gUm9zdGVk
dCB3cm90ZToNCj4gPj4NCj4gPj4gT24gVHVlLCAyMCBPY3QgMjAxNSAxNjozNjowNCAtMDQwMA0K
PiA+PiBDaHJpcyBNZXRjYWxmIDxjbWV0Y2FsZkBlemNoaXAuY29tPiB3cm90ZToNCj4gPj4NCj4g
Pj4+IEFsbG93IHVzZXJzcGFjZSB0byBvdmVycmlkZSB0aGUgZGVmYXVsdCBTSUdLSUxMIGRlbGl2
ZXJlZA0KPiA+Pj4gd2hlbiBhIHRhc2tfaXNvbGF0aW9uIHByb2Nlc3MgaW4gU1RSSUNUIG1vZGUg
ZG9lcyBhIHN5c2NhbGwNCj4gPj4+IG9yIG90aGVyd2lzZSBzeW5jaHJvbm91c2x5IGVudGVycyB0
aGUga2VybmVsLg0KPiA+Pj4NCjxzbmlwPg0KPiA+DQo+ID4gSXQgZG9lc24ndCBtYXAgU0lHS0lM
TCB0byBzb21lIG90aGVyIHNpZ25hbCB1bmNvbmRpdGlvbmFsbHkuICBJdCBqdXN0IGFsbG93cw0K
PiA+IHRoZSAiaGV5LCB5b3UgYnJva2UgdGhlIFNUUklDVCBjb250cmFjdCBhbmQgZW50ZXJlZCB0
aGUga2VybmVsIiBzaWduYWwNCj4gPiB0byBiZSBzb21ldGhpbmcgYmVzaWRlcyB0aGUgZGVmYXVs
dCBTSUdLSUxMLg0KPiA+DQo+IA0KDQo8c25pcD4NCj4gDQo+IEkgc3RpbGwgZGlzbGlrZSB0aGlz
IHRoaW5nLiAgSXQgc2VlbXMgbGlrZSBhIGRlYnVnZ2luZyBmZWF0dXJlIGJlaW5nDQo+IGltcGxl
bWVudGVkIHVzaW5nIHNpZ25hbHMgaW5zdGVhZCBvZiBleGlzdGluZyBBUElzLiAgSSAqc3RpbGwq
IGRvbid0DQo+IHNlZSB3aHkgcGVyZiBjYW4ndCBiZSB1c2VkIHRvIGFjY29tcGxpc2ggeW91ciBn
b2FsLg0KPiANCg0KSXQgaXMgbm90IChqdXN0KSBhIGRlYnVnZ2luZyBmZWF0dXJlLiBUaGVyZSBh
cmUgd29ya2xvYWRzIHdlcmUgbm90IHBlcmZvcm1pbmcgYW4gYWN0aW9uIGlzIG11Y2ggcHJlZmVy
cmVkIHRvIGJlaW5nIGxhdGUuDQoNCkNvbnNpZGVyIHRoZSBmb2xsb3dpbmcgYXJ0aWZpY2lhbCBi
dXQgcmVwcmVzZW50YXRpdmUgc2NlbmFyaW86IGEgdGFzayBydW5uaW5nIGluIHN0cmljdCBpc29s
YXRpb24gaXMgY29udHJvbGxpbmcgYSByYWRpb3RoZXJhcHkgYWxwaGEgZW1pdHRlci4NClRoZSBj
b2RlIHJ1bnMgaW4gYSB0aWdodCBldmVudCBsb29wLCByZWFkaW5nIGFuIE1NSU8gcmVnaXN0ZXIg
d2l0aCBsb2NhdGlvbiBkYXRhLCBtYWtpbmcgc29tZSBjYWxjdWxhdGlvbiBhbmQgaW4gcmVzcG9u
c2Ugd3JpdGluZyBhbiANCk1NSU8gcmVnaXN0ZXIgdGhhdCB0cmlnZ2VycyB0aGUgYWxwaGEgZW1p
dHRlci4gQXMgYSBzYWZldHkgbWVhc3VyZSwgZWFjaCB0cmlnZ2VyIGlzIGZvciBhIHNwZWNpZmlj
IHZlcnkgc2hvcnQgdGltZSBmcmFtZSAtIHRoZSBhbHBoYSBlbWl0dGVyIA0KYXV0byBzdG9wcy4N
Cg0KVGhlIGNvZGUgaGFzIGEgc3RyaWN0IGFzc3VtcHRpb24gdGhhdCBubyBtb3JlIHRoYW4gWCBj
eWNsZXMgcGFzcyBiZXR3ZWVuIHJlYWRpbmcgdGhlIHZhbHVlIGFuZCB0aGUgcmVzcG9uc2UgYW5k
IHRoZSBzeXN0ZW0gaXMgYnVpbHQgaW4gDQpzdWNoIGEgd2F5IHRoYXQgYXMgbG9uZyBhcyB0aGUg
Y29kZSBoYXMgbWFzdGVyeSBvZiB0aGUgQ1BVIHRoZSBhc3N1bXB0aW9uIGhvbGRzIHRydWUuIElm
IHNvbWV0aGluZyBicmVha3MgdGhpcyBhc3N1bXB0aW9uICh1bnBsYW5uZWQNCmNvbnRleHQgc3dp
dGNoIHRvIGtlcm5lbCksIHdoYXQgeW91IHdhbnQgdG8gZG8gaXMganVzdCBzdG9wIHBsYWNlDQpy
YXRoZXIgdGhhbiBmaXJlIHRoZSBhbHBoYSBlbWl0dGVyIFggbmFub3NlY29uZHMgdG9vIGxhdGUu
DQoNClRoaXMgZmVhdHVyZSBsZXRzIHlvdSBzYXk6IGlmIHRoZSAiY29udHJhY3QiIG9mIGlzb2xh
dGlvbiBpcyBicm9rZW4sIG5vdGlmeS9raWxsIG1lIGF0IG9uY2UuDQoNCkZvciBjb2RlIHdoZXJl
IGlzb2xhdGlvbiBpcyBpbXBvcnRhbnQsIHRoZSBjb3JyZWN0bmVzcyBvZiBhIGNhbGN1bGF0aW9u
IGlzIGRlcGVuZGVudCBvbiB0aW1pbmcuIEl0J3MgbGlrZSB5b3Ugd291bGQgYWNjZXB0IHRoZSBr
ZXJuZWwgdG8NCmtpbGwgYSB0YXNrIGlmIGl0IHJlYWQgZnJvbSBhbiB1bm1hcHBlZCB2aXJ0dWFs
IGFkZHJlc3MgcmF0aGVyIHRoYW4gcmV0dXJuaW5nIGdhcmJhZ2UgZGF0YS4gV2l0aCBhbiBpc29s
YXRlZCB0YXNrLCB0aGUgcmlnaHQgZGF0YSBhY3RlZCBvbiANCmxhdGVyIHRoYW4geW91IHRoaW5r
IGlzIGdhcmJhZ2UganVzdCB0aGUgc2FtZS4NCg0KSSBob3BlIHRoaXMgc2hlZHMgc29tZSBsaWdo
dCBvbiB0aGUgaXNzdWUuDQoNClRoYW5rcywNCkdpbGFkDQoNCg==
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1253124 — Re: [PATCH v8 06/14] task_isolation: provide strict mode configurable signal

On Tue, Oct 20, 2015 at 11:41 PM, Gilad Ben Yossef <giladb@ezchip.com> wrote:
>
>
>> From: Andy Lutomirski [mailto:luto@amacapital.net]
>> Sent: Wednesday, October 21, 2015 4:43 AM
>> To: Chris Metcalf
>> Subject: Re: [PATCH v8 06/14] task_isolation: provide strict mode
>> configurable signal
>>
>> On Tue, Oct 20, 2015 at 6:30 PM, Chris Metcalf <cmetcalf@ezchip.com>
>> wrote:
>> > On 10/20/2015 8:56 PM, Steven Rostedt wrote:
>> >>
>> >> On Tue, 20 Oct 2015 16:36:04 -0400
>> >> Chris Metcalf <cmetcalf@ezchip.com> wrote:
>> >>
>> >>> Allow userspace to override the default SIGKILL delivered
>> >>> when a task_isolation process in STRICT mode does a syscall
>> >>> or otherwise synchronously enters the kernel.
>> >>>
> <snip>
>> >
>> > It doesn't map SIGKILL to some other signal unconditionally.  It just allows
>> > the "hey, you broke the STRICT contract and entered the kernel" signal
>> > to be something besides the default SIGKILL.
>> >
>>
>
> <snip>
>>
>> I still dislike this thing.  It seems like a debugging feature being
>> implemented using signals instead of existing APIs.  I *still* don't
>> see why perf can't be used to accomplish your goal.
>>
>
> It is not (just) a debugging feature. There are workloads were not performing an action is much preferred to being late.
>
> Consider the following artificial but representative scenario: a task running in strict isolation is controlling a radiotherapy alpha emitter.
> The code runs in a tight event loop, reading an MMIO register with location data, making some calculation and in response writing an
> MMIO register that triggers the alpha emitter. As a safety measure, each trigger is for a specific very short time frame - the alpha emitter
> auto stops.
>
> The code has a strict assumption that no more than X cycles pass between reading the value and the response and the system is built in
> such a way that as long as the code has mastery of the CPU the assumption holds true. If something breaks this assumption (unplanned
> context switch to kernel), what you want to do is just stop place
> rather than fire the alpha emitter X nanoseconds too late.
>
> This feature lets you say: if the "contract" of isolation is broken, notify/kill me at once.

That's a fair point.  It's risky, though, for quite a few reasons.

1. If someone builds an alpha emitter like this, they did it wrong.
The kernel should write a trigger *and* a timestamp to the hardware
and the hardware should trigger at the specified time if the time is
in the future and throw an error if it's in the past.  If you need to
check that you made the deadline, check the actual desired condition
(did you meat the deadline?) not a proxy (did the signal fire?).

2. This strict mode thing isn't exhaustive.  It's missing, at least,
coverage for NMI, MCE, and SMI.  Sure, you can think that you've
disabled all NMI sources, you can try to remember to set the
appropriate boot flag that panics on MCE (and hope that you don't get
screwed by broadcast MCE on Intel systems before it got fixed
(Skylake?  Is the fix even available in a released chip?), and, for
SMI, good luck...

3. You haven't dealt with IPIs.  The TLB flush code in particular
seems like it will break all your assumptions.

Maybe it would make sense to whack more of the moles before adding a
big assertion that there aren't any moles any more.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1254177 — Re: [PATCH v8 06/14] task_isolation: provide strict mode configurable signal

On Thu, Oct 22, 2015 at 1:44 PM, Chris Metcalf <cmetcalf@ezchip.com> wrote:
> On 10/21/2015 02:53 PM, Andy Lutomirski wrote:
>>
>> On Tue, Oct 20, 2015 at 11:41 PM, Gilad Ben Yossef <giladb@ezchip.com>
>> wrote:
>>>
>>>
>>>> From: Andy Lutomirski [mailto:luto@amacapital.net]
>>>> Sent: Wednesday, October 21, 2015 4:43 AM
>>>> To: Chris Metcalf
>>>> Subject: Re: [PATCH v8 06/14] task_isolation: provide strict mode
>>>> configurable signal
>>>>
>>>> On Tue, Oct 20, 2015 at 6:30 PM, Chris Metcalf <cmetcalf@ezchip.com>
>>>> wrote:
>>>>>
>>>>> On 10/20/2015 8:56 PM, Steven Rostedt wrote:
>>>>>>
>>>>>> On Tue, 20 Oct 2015 16:36:04 -0400
>>>>>> Chris Metcalf <cmetcalf@ezchip.com> wrote:
>>>>>>
>>>>>>> Allow userspace to override the default SIGKILL delivered
>>>>>>> when a task_isolation process in STRICT mode does a syscall
>>>>>>> or otherwise synchronously enters the kernel.
>>>>>>>
>>> <snip>
>>>>>
>>>>> It doesn't map SIGKILL to some other signal unconditionally.  It just
>>>>> allows
>>>>> the "hey, you broke the STRICT contract and entered the kernel" signal
>>>>> to be something besides the default SIGKILL.
>>>>>
>>> <snip>
>>>>
>>>> I still dislike this thing.  It seems like a debugging feature being
>>>> implemented using signals instead of existing APIs.  I *still* don't
>>>> see why perf can't be used to accomplish your goal.
>>>>
>>> It is not (just) a debugging feature. There are workloads were not
>>> performing an action is much preferred to being late.
>>>
>>> Consider the following artificial but representative scenario: a task
>>> running in strict isolation is controlling a radiotherapy alpha emitter.
>>> The code runs in a tight event loop, reading an MMIO register with
>>> location data, making some calculation and in response writing an
>>> MMIO register that triggers the alpha emitter. As a safety measure, each
>>> trigger is for a specific very short time frame - the alpha emitter
>>> auto stops.
>>>
>>> The code has a strict assumption that no more than X cycles pass between
>>> reading the value and the response and the system is built in
>>> such a way that as long as the code has mastery of the CPU the assumption
>>> holds true. If something breaks this assumption (unplanned
>>> context switch to kernel), what you want to do is just stop place
>>> rather than fire the alpha emitter X nanoseconds too late.
>>>
>>> This feature lets you say: if the "contract" of isolation is broken,
>>> notify/kill me at once.
>>
>> That's a fair point.  It's risky, though, for quite a few reasons.
>>
>> 1. If someone builds an alpha emitter like this, they did it wrong.
>> The kernel should write a trigger *and* a timestamp to the hardware
>> and the hardware should trigger at the specified time if the time is
>> in the future and throw an error if it's in the past.  If you need to
>> check that you made the deadline, check the actual desired condition
>> (did you meat the deadline?) not a proxy (did the signal fire?).
>
>
> Definitely a better hardware design, but as we all know, hardware
> designers too rarely consult the software people who have to
> right the actual code to properly drive the hardware :-)
>
> My canonical example is high-performance userspace network
> drivers, and though dropping is packet is less likely to kill a
> patient, it's still a pretty bad thing if you're trying to design
> a robust appliance.  In this case you really want to fix application
> bugs that cause the code to enter the kernel when you think
> you're in the internal loop running purely in userspace.  Things
> like unexpected page faults, and third-party code that almost
> never calls the kernel but in some dusty corner it occasionally
> does, can screw up your userspace code pretty badly, and
> mysteriously.  The "strict" mode support is not a hypothetical
> insurance policy but a reaction to lots of Tilera customer support
> over the years to folks failing to stay in userspace when they
> thought they were doing the right thing.

But this is *exactly* the case where perf or other out-of-band
debugging could be a much better solution.  Perf could notify a
non-isolated thread that an interrupt happened, you'd still drop a
packet or two, but you wouldn't also drop the next ten thousand
packets while handling the signal.

>
>> 2. This strict mode thing isn't exhaustive.  It's missing, at least,
>> coverage for NMI, MCE, and SMI.  Sure, you can think that you've
>> disabled all NMI sources, you can try to remember to set the
>> appropriate boot flag that panics on MCE (and hope that you don't get
>> screwed by broadcast MCE on Intel systems before it got fixed
>> (Skylake?  Is the fix even available in a released chip?), and, for
>> SMI, good luck...
>
>
> You are confusing this strict mode support with the debug
> support in patch 07/14.

Nope.  I'm confusing this strict mode with what Gilad described: using
strict mode to cause outright shutdown instead of failure to meet a
deadline.

(FWIW, you could also use an ordinary hardware watchdog timer to
promote your failure to meet a deadline to a shutdown.  No new kernel
support needed.)

>
> Strict mode is for synchronous application errors.  You might
> be right that there are cases that haven't been covered, but
> certainly most of them are covered on the three platforms that
> are supported in this initial series.  (You pointed me to one
> that I would have missed on x86, namely the bounds check
> exception from a bad bounds setup.)  I'm pretty confident I
> have all of them for tile, since I know that hardware best,
> and I think we're in good shape for arm64, though I'm still
> coming up to speed on that architecture.

Again, for this definition of strict mode, I still don't see why it's
the right design.  If you want to debug your application to detect
application errors, use a debugging interface.

>
> NMIs and machine checks are asynchronous interrupts that
> don't have to do with what the application is doing, more or less.
> Those should not be delivered to task-isolation cores at all,
> so we just generate console spew when you set the
> task_isolation_debug boot option.  I honestly don't know enough
> about system management interrupts to comment on that,
> though again, I would hope one can configure the system to
> just not deliver them to nohz_full cores, and I think it would
> be reasonable to generate some kernel spew if that happens.

Hah hah yeah right.  On most existing Intel CPUs, you *cannot*
configure machine checks to do anything other than broadcast to all
cores or cause immediate shutdown.  And getting any sort of reasonable
control over SMI more or less requires special firmware.

>
>> 3. You haven't dealt with IPIs.  The TLB flush code in particular
>> seems like it will break all your assumptions.
>
>
> Again, not a synchronous application error that we are trying
> to catch with this signalling mechanism.
>
> That said it could obviously be a more general application error
> (e.g. a process with threads on both nohz_full and housekeeping
> cores, where the housekeeping core unmaps some memory and
> thus requires a TLB flush IPI).  But this is covered by the
> task_isolation_debug patch for kernel/smp.c.
>
>> Maybe it would make sense to whack more of the moles before adding a
>> big assertion that there aren't any moles any more.
>
>
> Maybe, but I've whacked the ones I know how to whack.
> If there are ones I've missed I'm happy to add them in a
> subsequent version of this series, or in follow-on patches.
>

I agree that you can, in principle, catch all the synchronous
application errors using this mechanism.  I'm saying that catching
them seems quite useful, but catching them using a prctl that causes a
signal and explicitly does *not* solve the deadline enforcement
problem seems to have dubious value in the upstream kernel.

You can't catch the asynchronous application errors with this
mechanism (or at least your ability to catch them depends on which
patch version IIRC), which include calling anything like munmap or
membarrier in another thread.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1255149 — RE: [PATCH v8 06/14] task_isolation: provide strict mode configurable signal

Hi Andy,

Thank for the feedback.


> From: Andy Lutomirski [mailto:luto@amacapital.net]
> Sent: Wednesday, October 21, 2015 9:53 PM
> To: Gilad Ben Yossef
> Cc: Chris Metcalf; Steven Rostedt; Ingo Molnar; Peter Zijlstra; Andrew
> Morton; Rik van Riel; Tejun Heo; Frederic Weisbecker; Thomas Gleixner; Paul
> E. McKenney; Christoph Lameter; Viresh Kumar; Catalin Marinas; Will Deacon;
> linux-doc@vger.kernel.org; Linux API; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v8 06/14] task_isolation: provide strict mode
> configurable signal
> 


> >> >> On Tue, 20 Oct 2015 16:36:04 -0400
> >> >> Chris Metcalf <cmetcalf@ezchip.com> wrote:
> >> >>
> >> >>> Allow userspace to override the default SIGKILL delivered
> >> >>> when a task_isolation process in STRICT mode does a syscall
> >> >>> or otherwise synchronously enters the kernel.
> >> >>>
> > <snip>
> >> >
> >> > It doesn't map SIGKILL to some other signal unconditionally.  It just allows
> >> > the "hey, you broke the STRICT contract and entered the kernel" signal
> >> > to be something besides the default SIGKILL.
> >> >
> >>
> >
> > <snip>
> >>
> >> I still dislike this thing.  It seems like a debugging feature being
> >> implemented using signals instead of existing APIs.  I *still* don't
> >> see why perf can't be used to accomplish your goal.
> >>
> >
> > It is not (just) a debugging feature. There are workloads were not
> performing an action is much preferred to being late.
> >
> > Consider the following artificial but representative scenario: a task running
> in strict isolation is controlling a radiotherapy alpha emitter.
> > The code runs in a tight event loop, reading an MMIO register with location
> data, making some calculation and in response writing an
> > MMIO register that triggers the alpha emitter. As a safety measure, each
> trigger is for a specific very short time frame - the alpha emitter
> > auto stops.
> >
> > The code has a strict assumption that no more than X cycles pass between
> reading the value and the response and the system is built in
> > such a way that as long as the code has mastery of the CPU the assumption
> holds true. If something breaks this assumption (unplanned
> > context switch to kernel), what you want to do is just stop place
> > rather than fire the alpha emitter X nanoseconds too late.
> >
> > This feature lets you say: if the "contract" of isolation is broken, notify/kill
> me at once.
> 
> That's a fair point.  It's risky, though, for quite a few reasons.
> 
> 1. If someone builds an alpha emitter like this, they did it wrong.
> The kernel should write a trigger *and* a timestamp to the hardware
> and the hardware should trigger at the specified time if the time is
> in the future and throw an error if it's in the past.  If you need to
> check that you made the deadline, check the actual desired condition
> (did you meat the deadline?) not a proxy (did the signal fire?).
> 

As I wrote above it is an *artificial* scenario. 

Yes, hardware and systems can be designed better, but they are not
always are and in these kind of systems, you really do want to have
double or triple checks.

Knowing such systems, even IF the hardware was designed as you 
specified (and I agree it should!) you would still add the software
protection.

> 2. This strict mode thing isn't exhaustive.  It's missing, at least,
> coverage for NMI, MCE, and SMI.  Sure, you can think that you've
> disabled all NMI sources, you can try to remember to set the
> appropriate boot flag that panics on MCE (and hope that you don't get
> screwed by broadcast MCE on Intel systems before it got fixed
> (Skylake?  Is the fix even available in a released chip?), and, for
> SMI, good luck...

You are right - it isn't exhaustive. It is one piece in a bigger puzzle.
Many of the other bits are platform specific and some of them have
been dealt with on the platform that care about these things.

Yes, we don't have dark magic to detect SMIs. Is that a reason to penalize
platforms where there is no such thing as SMI? 
 
 
> 3. You haven't dealt with IPIs.  The TLB flush code in particular
> seems like it will break all your assumptions.
>

But we have - in the general context. Consider this patch set from 2012 -
https://lwn.net/Articles/479510/

Not finished for sure. But what we have is now useful enough that it is used
in the real world for different workloads on different platforms, from packet
 processing, through HPC to high frequency trading.

> Maybe it would make sense to whack more of the moles before adding a
> big assertion that there aren't any moles any more.
> 

hm... maybe you are reading too much into this specific feature - its a 
"notify me, the application, if I asked you to do something that violates 
my previous request to be isolated", rather than "notify me whenever isolation is broken".

Does that make more sense?

Thanks,
Gilad--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web