Re: Capabilities, Anybody?

Liste des GroupesRevenir à c arch 
Sujet : Re: Capabilities, Anybody?
De : jgd (at) *nospam* cix.co.uk (John Dallman)
Groupes : comp.arch
Date : 17. Mar 2024, 12:52:04
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <memo.20240317115228.20436F@jgd.cix.co.uk>
References : 1
<https://www.capabilitieslimited.co.uk/_files/ugd/f4d681_e0f23245dace46629
7f20a0dbd22d371.pdf> wrote:

Fontconfig's serialization code heavily relied on being able
to create pointers from arbitrary pointer arithmetic, and this
is not compatible with CHERI.

Can you describe this in more detail? The library I work on manages its
memory in a very detailed way. It asks the host application to allocate
largeish blocks for it, and then subdivides the blocks itself, in many
ways, creating lots of pointers to entities within them.

That sounds a lot like "create pointers from arbitrary pointer
arithmetic." It's somewhat like the way a C run-time library gets memory
from the OS and manages the heap, only with specialisation for the sizes
of memory blocks that are used in large numbers. This is done to avoid
horrific heap fragmentation that would otherwise happen.

Presumably, this will require support in the library, analogous to the
way support is required in glibc?

Presumably sizeof(void*) == 16? Do any pointer types remain 8-byte, or do
they all grow to 16 bytes?

Given that Morello will run non-CHERI ARM64 code, how are the transitions
between CHERI and vanilla code handled? Must a process be one or the
other?

In article <Ory*7U4Ez@news.chiark.greenend.org.uk>,
theom+news@chiark.greenend.org.uk (Theo) wrote:

Should be - it's mostly making things play by the rules. Once they
play by the rules then it means they will work the same (or less
buggily) on a regular C platform.
 
The above link describes the changes - a number being replacing
'long' with intptr_t, some undefined behaviour, bad use of
realloc(). 

The things that look challenging on a skim of the report are both in the
"language run-time" category.

We have our own implementation of printf, which has a lot of machine-
specific code in it. That's done so that it can be extended with new
formatter codes at run-time: we add a few hundred formatters that know
about lots of internal types, many of them large structures. That tells
me that I'm going to have to treat the CHERI-enabled version of a
platform as a distinct platform, but that was likely inevitable anyway.

The interfaces that let our LISP interpreter in the test harness call C
code, and vice-versa are also a potential problem.

That realloc() bug was a beauty. It was a silly piece of code anyway, but
would work on most flat-address-space machines without capabilities.

Some of it was modernisation of old codebases (eg add C11 atomics),

To replace GCC __sync_* intrinsics, I see. Probably a good idea anyway,
and worth investigating.

Do you want to compartmentalise that shared library, ie put in trust
boundaries between the library and its caller?

No, so things should be straightforward, provided the linker and run-time
are willing to include the library in the same compartment as its caller.
I presume that's possible?

If you just want to run the shared library as-is, you can recompile
it and get bounds checking etc.

Compartmentalising the library's data reading is superficially attractive,
but it's pretty complicated. Specifically, expanding the save format to
the in-memory format can use large chunks of the library's code that are
also used in doing operations on in-memory data in response to API calls.


I believe Morello Linux is able to support console-mode apps - ie
it has support context switching and use of capabilities in userspace,
with some support in glibc. I believe there is now a dynamic linker,
but not sure of the status. 

To do porting work, I'd need X11 for debugging graphics, and some
prospect of commercial demand for CHERI-enabled libraries. Here, the
familiar chicken-and-egg problem with new architectures rears its head.

That might be overcome if, for example, ARM Ltd was to adopt a
CHERI-based architecture as ARMv10. But something like that would be
needed to build commercial momentum. Without such a commitment, CHERI may
well fade away.

John

Date Sujet#  Auteur
9 Mar 24 * Capabilities, Anybody?78Lawrence D'Oliveiro
9 Mar 24 +* Re: Capabilities, Anybody?74mitchalsup@aol.com (MitchAlsup1)
9 Mar 24 i+- Re: Capabilities, Anybody?1BGB
9 Mar 24 i+* Re: Capabilities, Anybody?71BGB
9 Mar 24 ii+* Re: Capabilities, Anybody?61Robert Finch
9 Mar 24 iii+- Re: Capabilities, Anybody?1Lawrence D'Oliveiro
10 Mar 24 iii`* Re: Capabilities, Anybody?59BGB
10 Mar 24 iii +- Re: Capabilities, Anybody?1Chris M. Thomasson
10 Mar 24 iii `* Re: Capabilities, Anybody?57Theo Markettos
10 Mar 24 iii  +* Re: Capabilities, Anybody?4John Dallman
11 Mar 24 iii  i`* Re: Capabilities, Anybody?3Theo
17 Mar 24 iii  i `* Re: Capabilities, Anybody?2John Dallman
18 Mar 24 iii  i  `- Re: Capabilities, Anybody?1Robert Finch
10 Mar 24 iii  +* Re: Capabilities, Anybody?19MitchAlsup1
11 Mar 24 iii  i`* Re: Capabilities, Anybody?18Theo Markettos
11 Mar 24 iii  i +* Re: Capabilities, Anybody?10MitchAlsup1
11 Mar 24 iii  i i`* Re: Capabilities, Anybody?9Theo Markettos
11 Mar 24 iii  i i +- Re: Capabilities, Anybody?1George Neuner
11 Mar 24 iii  i i `* Re: Capabilities, Anybody?7Michael S
11 Mar 24 iii  i i  +- Re: Capabilities, Anybody?1Michael S
11 Mar 24 iii  i i  `* Re: Capabilities, Anybody?5Michael S
11 Mar 24 iii  i i   `* Broken Date formats4Michael S
11 Mar 24 iii  i i    `* Re: Broken Date formats3Michael S
11 Mar 24 iii  i i     `* Re: Broken Date formats2Michael S
11 Mar 24 iii  i i      `- Re: Broken Date formats1Michael S
11 Mar 24 iii  i `* Re: Capabilities, Anybody?7Chris M. Thomasson
12 Mar 24 iii  i  `* Re: Capabilities, Anybody?6Chris M. Thomasson
13 Mar 24 iii  i   `* Re: Capabilities, Anybody?5BGB
14 Mar 24 iii  i    `* Re: Capabilities, Anybody?4Chris M. Thomasson
14 Mar 24 iii  i     `* Re: Capabilities, Anybody?3BGB
14 Mar 24 iii  i      `* Re: Capabilities, Anybody?2Chris M. Thomasson
16 Mar 24 iii  i       `- Re: Capabilities, Anybody?1BGB
10 Mar 24 iii  `* Re: Capabilities, Anybody?33BGB
11 Mar 24 iii   `* Re: Capabilities, Anybody?32Robert Finch
11 Mar 24 iii    `* Re: Capabilities, Anybody?31BGB
13 Mar 24 iii     `* Re: Capabilities, Anybody?30Robert Finch
13 Mar 24 iii      +* Re: Capabilities, Anybody?24MitchAlsup1
13 Mar 24 iii      i`* Re: Capabilities, Anybody?23Robert Finch
13 Mar 24 iii      i +* Re: Capabilities, Anybody?21MitchAlsup1
14 Mar 24 iii      i i`* Re: Capabilities, Anybody?20Robert Finch
14 Mar 24 iii      i i +- Re: Capabilities, Anybody?1Lawrence D'Oliveiro
14 Mar 24 iii      i i `* Re: Capabilities, Anybody?18MitchAlsup1
14 Mar 24 iii      i i  `* Re: Capabilities, Anybody?17Lawrence D'Oliveiro
14 Mar 24 iii      i i   +* Re: Capabilities, Anybody?10MitchAlsup1
14 Mar 24 iii      i i   i`* Re: Capabilities, Anybody?9Lawrence D'Oliveiro
15 Mar 24 iii      i i   i `* Re: Capabilities, Anybody?8MitchAlsup1
15 Mar 24 iii      i i   i  +* Re: Capabilities, Anybody?2Chris M. Thomasson
15 Mar 24 iii      i i   i  i`- Re: Capabilities, Anybody?1Chris M. Thomasson
15 Mar 24 iii      i i   i  `* Re: Capabilities, Anybody?5Lawrence D'Oliveiro
15 Mar 24 iii      i i   i   `* Re: Capabilities, Anybody?4Chris M. Thomasson
15 Mar 24 iii      i i   i    `* Re: Capabilities, Anybody?3Lawrence D'Oliveiro
15 Mar 24 iii      i i   i     `* Re: Capabilities, Anybody?2Lawrence D'Oliveiro
15 Mar 24 iii      i i   i      `- Re: Capabilities, Anybody?1Chris M. Thomasson
14 Mar 24 iii      i i   +* Re: Capabilities, Anybody?5Lawrence D'Oliveiro
15 Mar 24 iii      i i   i`* Re: Capabilities, Anybody?4MitchAlsup1
15 Mar 24 iii      i i   i +- Re: Capabilities, Anybody?1Lawrence D'Oliveiro
18 Mar 24 iii      i i   i +- Re: Capabilities, Anybody?1Paul A. Clayton
18 Mar 24 iii      i i   i `- Re: Capabilities, Anybody?1MitchAlsup1
15 Mar 24 iii      i i   `- Re: Capabilities, Anybody?1MitchAlsup1
14 Mar 24 iii      i `- Re: Capabilities, Anybody?1Theo Markettos
13 Mar 24 iii      `* Re: Capabilities, Anybody?5BGB
14 Mar 24 iii       `* Re: Capabilities, Anybody?4Robert Finch
14 Mar 24 iii        `* Re: Capabilities, Anybody?3BGB
14 Mar 24 iii         +- Re: Capabilities, Anybody?1Lawrence D'Oliveiro
15 Mar 24 iii         `- Re: Capabilities, Anybody?1MitchAlsup1
10 Mar 24 ii`* Re: Capabilities, Anybody?9Theo Markettos
11 Mar 24 ii `* Re: Capabilities, Anybody?8BGB
11 Mar 24 ii  +* Re: Capabilities, Anybody?2Robert Finch
12 Mar 24 ii  i`- Re: Capabilities, Anybody?1BGB
12 Mar 24 ii  +* Re: Capabilities, Anybody?2BGB
12 Mar 24 ii  i`- Re: Capabilities, Anybody?1MitchAlsup1
14 Mar 24 ii  `* Re: Capabilities, Anybody?3Theo Markettos
14 Mar 24 ii   +- Re: Capabilities, Anybody?1MitchAlsup1
14 Mar 24 ii   `- Re: Capabilities, Anybody?1BGB
9 Mar 24 i`- Re: Capabilities, Anybody?1Lawrence D'Oliveiro
9 Mar 24 `* Re: Capabilities, Anybody?3Robert Finch
9 Mar 24  `* Re: Capabilities, Anybody?2Lawrence D'Oliveiro
9 Mar 24   `- Re: Capabilities, Anybody?1Robert Finch

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal