By: dmcq (dmcq.delete@this.fano.co.uk), September 28, 2021 9:59 am
Room: Moderated Discussions
Linus Torvalds (torvalds.delete@this.linux-foundation.org) on September 27, 2021 12:58 pm wrote:
> Linus Torvalds (torvalds.delete@this.linux-foundation.org) on September 27, 2021 10:20 am wrote:
> >
> > Oh, the implementation differences can be huge. Do you "integrate" the pointer
> > with the capability data like Cheri does? Or do you keep them independent so
> > that you can use one "segment" with multiple indexes (like i386 did)?
>
> Thinking about it, the biggest difference is not that the i386 model made the segment
> be very clearly separate from the pointer, but that the i386 segment model itself
> was based on indirection and explicit software management of segments.
>
> IOW, you never loaded "a segment". You loaded a "segment selector", and the hardware then
> looked up the actual segment data from a "segment table" (actually, two different ones,
> but at that point we're going off into "irrelevant implementation details" weeds).
>
> That makes perfect sense in one way, but one of the limitations in that segment model was that it didn't
> allow users of segments to easily "sub-segment" things or do other things on their own. The only thing you
> as a user saw was the selector value, and while you could query certain state (like the segment limit),
> you couldn't really do operations on segments - you had to create a new entry in the segment table.
>
> Contrast this to the Cheri model, which doesn't have that indirection through a segment table,
> and you can create a new segment ("capability pointer") from an existing valid one. So you
> can take a big segment, and create a new smaller subset of it (or a read-only one from a
> read-write one) and just use it without going through that "segment table" thing.
>
> Is that "fundamentally different"? No. The i386 model is one of an explicit software-managed segment
> table, while the Cheri one is comes with hardware support for managing your segments.
>
> Does the Cheri model seem much better? Ahh, there's the nub. It sure as heck looks a lot cleaner
> than i386 segments did (I say "i386", but it was really the 286 that introduced them).
>
> But looks can be deceiving.
>
> The Cheri model requires hidden bits of memory from hardware, for example.
> The Cheri model also makes all pointers really really big.
>
> So it's not some kind of "Cheri is obviously better". Cheri looks much nicer, but
> it has serious downsides, and the big difference is that we know the i386 model
> sucked, we don't have the same kind of lots of experience with the Cheri model.
>
> With Cheri you can do pointer compression (and if Cheri were to become popular, I bet people would
> try to do so), and you'd probably end up making your data structures use a lot of "index off a base
> pointer" instead of using a pointer. Because a 128-bit pointer is just really really big and wastes
> a lot of memory (it also has to be 128-bit aligned, because of how that verification bit works).
>
> That "pointer compression" was actually very very natural in the i386 model. It is not natural in the Cheri
> model. It requires that "one single base pointer". And that's fundamentally what the "segment selector" is.
>
> And yes, we've seen this before: people did some of that kind of work when moving to 64-bit
> architectures, and it sure wasn't all fun and games. On the whole, most projects kept using
> pointers, rather than "index plus base pointer", because managing the base pointer is just
> too painful, and it really doesn't work well when you have multiple allocations.
>
> And that "too painful" becomes even more true when you have
> segments / capability pointers and multiple allocations.
>
> Maybe the i386 segment model with pointer compression using
> explicit near and far pointers wasn't wrong after all?
>
> See? i386 segments really aren't so conceptually different from Cheri capability pointers. Very different
> implementation choices, and very different trade-offs. We know the i386 segment model was horrible
> to use. Does Cheri fix the problems? It's not immediately and trivially obvious. That "use index off
> a base pointer" doesn't look so different from near and far pointers, now does it?
>
> There's a reason Cheri is a "research project".
>
> But there is no real reason to claim that capabilities are fundamentally different from segments.
>
> Linus
THe bits of CHERI that worry me most are anything to do with revoking capabilities and stopping them being saved in a caled domain. THe i386 segments are easier that way but they just don't have the same flexibilty of use. I don't think conflating them achieves any useful purpose. There are other segment based system which are much closer like the Burroughs large systems for instance.
> Linus Torvalds (torvalds.delete@this.linux-foundation.org) on September 27, 2021 10:20 am wrote:
> >
> > Oh, the implementation differences can be huge. Do you "integrate" the pointer
> > with the capability data like Cheri does? Or do you keep them independent so
> > that you can use one "segment" with multiple indexes (like i386 did)?
>
> Thinking about it, the biggest difference is not that the i386 model made the segment
> be very clearly separate from the pointer, but that the i386 segment model itself
> was based on indirection and explicit software management of segments.
>
> IOW, you never loaded "a segment". You loaded a "segment selector", and the hardware then
> looked up the actual segment data from a "segment table" (actually, two different ones,
> but at that point we're going off into "irrelevant implementation details" weeds).
>
> That makes perfect sense in one way, but one of the limitations in that segment model was that it didn't
> allow users of segments to easily "sub-segment" things or do other things on their own. The only thing you
> as a user saw was the selector value, and while you could query certain state (like the segment limit),
> you couldn't really do operations on segments - you had to create a new entry in the segment table.
>
> Contrast this to the Cheri model, which doesn't have that indirection through a segment table,
> and you can create a new segment ("capability pointer") from an existing valid one. So you
> can take a big segment, and create a new smaller subset of it (or a read-only one from a
> read-write one) and just use it without going through that "segment table" thing.
>
> Is that "fundamentally different"? No. The i386 model is one of an explicit software-managed segment
> table, while the Cheri one is comes with hardware support for managing your segments.
>
> Does the Cheri model seem much better? Ahh, there's the nub. It sure as heck looks a lot cleaner
> than i386 segments did (I say "i386", but it was really the 286 that introduced them).
>
> But looks can be deceiving.
>
> The Cheri model requires hidden bits of memory from hardware, for example.
> The Cheri model also makes all pointers really really big.
>
> So it's not some kind of "Cheri is obviously better". Cheri looks much nicer, but
> it has serious downsides, and the big difference is that we know the i386 model
> sucked, we don't have the same kind of lots of experience with the Cheri model.
>
> With Cheri you can do pointer compression (and if Cheri were to become popular, I bet people would
> try to do so), and you'd probably end up making your data structures use a lot of "index off a base
> pointer" instead of using a pointer. Because a 128-bit pointer is just really really big and wastes
> a lot of memory (it also has to be 128-bit aligned, because of how that verification bit works).
>
> That "pointer compression" was actually very very natural in the i386 model. It is not natural in the Cheri
> model. It requires that "one single base pointer". And that's fundamentally what the "segment selector" is.
>
> And yes, we've seen this before: people did some of that kind of work when moving to 64-bit
> architectures, and it sure wasn't all fun and games. On the whole, most projects kept using
> pointers, rather than "index plus base pointer", because managing the base pointer is just
> too painful, and it really doesn't work well when you have multiple allocations.
>
> And that "too painful" becomes even more true when you have
> segments / capability pointers and multiple allocations.
>
> Maybe the i386 segment model with pointer compression using
> explicit near and far pointers wasn't wrong after all?
>
> See? i386 segments really aren't so conceptually different from Cheri capability pointers. Very different
> implementation choices, and very different trade-offs. We know the i386 segment model was horrible
> to use. Does Cheri fix the problems? It's not immediately and trivially obvious. That "use index off
> a base pointer" doesn't look so different from near and far pointers, now does it?
>
> There's a reason Cheri is a "research project".
>
> But there is no real reason to claim that capabilities are fundamentally different from segments.
>
> Linus
THe bits of CHERI that worry me most are anything to do with revoking capabilities and stopping them being saved in a caled domain. THe i386 segments are easier that way but they just don't have the same flexibilty of use. I don't think conflating them achieves any useful purpose. There are other segment based system which are much closer like the Burroughs large systems for instance.
Topic | Posted By | Date |
---|---|---|
POWER10 SAP SD benchmark | anon2 | 2021/09/06 02:36 PM |
POWER10 SAP SD benchmark | Daniel B | 2021/09/07 01:31 AM |
"Cores" (and SPEC) | Rayla | 2021/09/07 06:51 AM |
"Cores" (and SPEC) | anon | 2021/09/07 02:56 PM |
POWER10 SAP SD benchmark | Anon | 2021/09/07 02:24 PM |
POWER10 SAP SD benchmark | Anon | 2021/09/07 02:27 PM |
Virtually tagged L1-caches | sr | 2021/09/08 04:49 AM |
Virtually tagged L1-caches | dmcq | 2021/09/08 07:22 AM |
Virtually tagged L1-caches | sr | 2021/09/08 07:56 AM |
Virtually tagged L1-caches | Hugo Décharnes | 2021/09/08 07:58 AM |
Virtually tagged L1-caches | sr | 2021/09/08 09:09 AM |
Virtually tagged L1-caches | Hugo Décharnes | 2021/09/08 09:46 AM |
Virtually tagged L1-caches | sr | 2021/09/08 10:35 AM |
Virtually tagged L1-caches | Hugo Décharnes | 2021/09/08 11:23 AM |
Virtually tagged L1-caches | sr | 2021/09/08 11:40 AM |
Virtually tagged L1-caches | anon | 2021/09/09 02:16 AM |
Virtually tagged L1-caches | Konrad Schwarz | 2021/09/10 04:19 AM |
Virtually tagged L1-caches | Hugo Décharnes | 2021/09/10 05:59 AM |
Virtually tagged L1-caches | anon | 2021/09/14 02:17 AM |
Virtually tagged L1-caches | dmcq | 2021/09/14 08:34 AM |
Or use a PLB (NT) | Paul A. Clayton | 2021/09/14 08:45 AM |
Or use a PLB | Linus Torvalds | 2021/09/14 02:27 PM |
Or use a PLB | anon | 2021/09/14 11:15 PM |
Or use a PLB | Michael S | 2021/09/15 02:21 AM |
Or use a PLB | dmcq | 2021/09/15 02:42 PM |
Or use a PLB | Konrad Schwarz | 2021/09/16 03:24 AM |
Or use a PLB | Michael S | 2021/09/16 09:13 AM |
Or use a PLB | --- | 2021/09/16 12:02 PM |
PLB reference | Paul A. Clayton | 2021/09/18 01:35 PM |
PLB reference | Michael S | 2021/09/18 03:14 PM |
Demand paging/translation orthogonal | Paul A. Clayton | 2021/09/19 06:33 AM |
Demand paging/translation orthogonal | Michael S | 2021/09/19 08:10 AM |
PLB reference | Carson | 2021/09/20 09:19 PM |
PLB reference | sr | 2021/09/20 05:02 AM |
PLB reference | Michael S | 2021/09/20 06:03 AM |
PLB reference | Linus Torvalds | 2021/09/20 11:10 AM |
Or use a PLB | sr | 2021/09/20 03:32 AM |
Or use a PLB | sr | 2021/09/21 08:36 AM |
Or use a PLB | Linus Torvalds | 2021/09/21 09:04 AM |
Or use a PLB | sr | 2021/09/21 09:48 AM |
Or use a PLB | Linus Torvalds | 2021/09/21 12:55 PM |
Or use a PLB | sr | 2021/09/22 05:55 AM |
Or use a PLB | rwessel | 2021/09/22 06:09 AM |
Or use a PLB | Linus Torvalds | 2021/09/22 10:50 AM |
Or use a PLB | sr | 2021/09/22 12:00 PM |
Or use a PLB | dmcq | 2021/09/22 03:07 PM |
Or use a PLB | Etienne Lorrain | 2021/09/23 07:50 AM |
Or use a PLB | anon2 | 2021/09/22 03:09 PM |
Or use a PLB | dmcq | 2021/09/23 01:35 AM |
Or use a PLB | ⚛ | 2021/09/23 08:37 AM |
Or use a PLB | Linus Torvalds | 2021/09/23 11:01 AM |
Or use a PLB | gpd | 2021/09/24 02:59 AM |
Or use a PLB | Linus Torvalds | 2021/09/24 09:45 AM |
Or use a PLB | dmcq | 2021/09/24 11:43 AM |
Or use a PLB | sr | 2021/09/25 09:19 AM |
Or use a PLB | Linus Torvalds | 2021/09/25 09:44 AM |
Or use a PLB | sr | 2021/09/25 10:11 AM |
Or use a PLB | Linus Torvalds | 2021/09/25 10:31 AM |
Or use a PLB | sr | 2021/09/25 10:52 AM |
Or use a PLB | Linus Torvalds | 2021/09/25 11:05 AM |
Or use a PLB | sr | 2021/09/25 11:23 AM |
Or use a PLB | rwessel | 2021/09/25 02:29 PM |
Or use a PLB | sr | 2021/09/30 11:22 PM |
Or use a PLB | rwessel | 2021/10/01 05:19 AM |
Or use a PLB | David Hess | 2021/10/01 09:35 AM |
Or use a PLB | rwessel | 2021/10/02 03:47 AM |
Or use a PLB | sr | 2021/10/02 10:16 AM |
Or use a PLB | rwessel | 2021/10/02 10:53 AM |
Or use a PLB | Linus Torvalds | 2021/09/25 10:57 AM |
Or use a PLB | sr | 2021/09/25 11:07 AM |
Or use a PLB | Linus Torvalds | 2021/09/25 11:21 AM |
Or use a PLB | sr | 2021/09/25 11:40 AM |
Or use a PLB | nksingh | 2021/09/27 08:07 AM |
Or use a PLB | ⚛ | 2021/09/27 08:02 AM |
Or use a PLB | Linus Torvalds | 2021/09/27 09:20 AM |
Or use a PLB | Linus Torvalds | 2021/09/27 11:58 AM |
Or use a PLB | dmcq | 2021/09/28 09:59 AM |
Or use a PLB | sr | 2021/09/25 09:34 AM |
Or use a PLB | rwessel | 2021/09/25 02:44 PM |
Or use a PLB | sr | 2021/10/01 12:04 AM |
Or use a PLB | rwessel | 2021/10/01 05:33 AM |
I386 segmentation highlights | sr | 2021/10/04 06:53 AM |
I386 segmentation highlights | Adrian | 2021/10/04 08:53 AM |
I386 segmentation highlights | sr | 2021/10/04 09:19 AM |
I386 segmentation highlights | rwessel | 2021/10/04 03:57 PM |
I386 segmentation highlights | sr | 2021/10/05 10:16 AM |
I386 segmentation highlights | Michael S | 2021/10/05 11:27 AM |
I386 segmentation highlights | rwessel | 2021/10/05 03:20 PM |
Or use a PLB | JohnG | 2021/09/25 09:18 PM |
Or use a PLB | ⚛ | 2021/09/27 06:37 AM |
Or use a PLB | Heikki Kultala | 2021/09/28 02:53 AM |
Or use a PLB | rwessel | 2021/09/28 06:29 AM |
Or use a PLB | David Hess | 2021/09/23 05:00 PM |
Or use a PLB | Adrian | 2021/09/24 12:21 AM |
Or use a PLB | dmcq | 2021/09/25 11:41 AM |
Or use a PLB | blaine | 2021/09/26 10:19 PM |
Or use a PLB | David Hess | 2021/09/27 10:35 AM |
Or use a PLB | blaine | 2021/09/27 04:19 PM |
Or use a PLB | Adrian | 2021/09/27 09:40 PM |
Or use a PLB | Adrian | 2021/09/27 09:59 PM |
Or use a PLB | dmcq | 2021/09/28 06:45 AM |
Or use a PLB | rwessel | 2021/09/28 06:45 AM |
Or use a PLB | David Hess | 2021/09/28 11:50 AM |
Or use a PLB | Etienne Lorrain | 2021/09/30 12:25 AM |
Or use a PLB | David Hess | 2021/10/01 09:40 AM |
MMU privileges | sr | 2021/09/21 10:07 AM |
MMU privileges | Linus Torvalds | 2021/09/21 12:49 PM |
Virtually tagged L1-caches | Konrad Schwarz | 2021/09/16 03:18 AM |
Virtually tagged L1-caches | Carson | 2021/09/16 12:12 PM |
Virtually tagged L1-caches | anon2 | 2021/09/16 04:16 PM |
Virtually tagged L1-caches | rwessel | 2021/09/16 05:29 PM |
Virtually tagged L1-caches | sr | 2021/09/20 03:20 AM |
Virtually tagged L1-caches | --- | 2021/09/08 01:28 PM |
Virtually tagged L1-caches | anonymou5 | 2021/09/08 07:28 PM |
Virtually tagged L1-caches | anonymou5 | 2021/09/08 07:34 PM |
Virtually tagged L1-caches | --- | 2021/09/09 09:14 AM |
Virtually tagged L1-caches | anonymou5 | 2021/09/09 09:44 PM |
Multi-threading? | David Kanter | 2021/09/09 08:32 PM |
Multi-threading? | --- | 2021/09/10 08:19 AM |
Virtually tagged L1-caches | sr | 2021/09/11 12:19 AM |
Virtually tagged L1-caches | sr | 2021/09/11 12:36 AM |
Virtually tagged L1-caches | --- | 2021/09/11 08:53 AM |
Virtually tagged L1-caches | sr | 2021/09/11 11:43 PM |
Virtually tagged L1-caches | Linus Torvalds | 2021/09/12 10:10 AM |
Virtually tagged L1-caches | sr | 2021/09/12 10:57 AM |
Virtually tagged L1-caches | dmcq | 2021/09/13 07:31 AM |
Virtually tagged L1-caches | sr | 2021/09/20 03:11 AM |
Virtually tagged L1-caches | sr | 2021/09/11 01:49 AM |
Virtually tagged L1-caches | Linus Torvalds | 2021/09/08 11:34 AM |
Virtually tagged L1-caches | dmcq | 2021/09/09 01:46 AM |
Virtually tagged L1-caches | dmcq | 2021/09/09 01:58 AM |
Virtually tagged L1-caches | sr | 2021/09/11 12:29 AM |
Virtually tagged L1-caches | dmcq | 2021/09/11 07:59 AM |
Virtually tagged L1-caches | sr | 2021/09/11 11:57 PM |
Virtually tagged L1-caches | dmcq | 2021/09/12 07:44 AM |
Virtually tagged L1-caches | sr | 2021/09/12 08:48 AM |
Virtually tagged L1-caches | dmcq | 2021/09/12 12:22 PM |
Virtually tagged L1-caches | sr | 2021/09/20 03:40 AM |
Where do you see this information? (NT) | anon2 | 2021/09/09 01:45 AM |
Where do you see this information? | sr | 2021/09/11 12:40 AM |
Where do you see this information? | anon2 | 2021/09/11 12:53 AM |
Where do you see this information? | sr | 2021/09/11 01:08 AM |
Thank you (NT) | anon2 | 2021/09/11 03:31 PM |