<jrtc27>
looks like it might just be isolating rtld's tls from the rest of the world's though at the moment, don't obviously see something stopping that (which is a bit of an oversight...)
<jrtc27>
I'll go poke Dapeng on our Slack
<sorear>
how does rtld figure out which tls to use when invoked from an untrusted environment?
<jrtc27>
I'm not so clued up on all the implementation details, but I would guess it would do it with the same per-compartment trampolines it sets up for normal function calls
* jrtc27
notes the manpage makes no mention of trampolines...
<jrtc27>
see libexec/rtld-elf/aarch64/rtld_c18n_asm.S for various trampoline fragment templates
<jrtc27>
I'd suggest chatting with Dapeng on CHERI-CPU Slack if you want to learn more about the library compartmentalisation design
<sorear>
so I don't think this can be implemented on riscv64 without a system call, since it's relying on an unforgeable thread ID in order to find the correct TLS on compartment switches
shamoe has quit [Quit: Connection closed for inactivity]
stolen has joined #riscv
Stat_headcrabed has joined #riscv
unlord has quit [Changing host]
unlord has joined #riscv
dlan has quit [Remote host closed the connection]
dlan has joined #riscv
Stat_headcrabed has quit [Quit: Stat_headcrabed]
foton has quit [Ping timeout: 255 seconds]
MaxGanzII_ has joined #riscv
<sorear>
jrtc27: do you mean per-thread pages? most pages in a posix address space are per-process :)
<jrtc27>
you were concerned with processes
<jrtc27>
for threads, the number of harts isn't relevant
<jrtc27>
just the number of threads
<sorear>
if you have more threads than harts, you only need as many "thread ID pages" as there are harts, because you can write the new thread ID into the page when you switch threads on that hart
<sorear>
but you need to use a version of the process address space that maps the correct hart's copy of the thread ID page at the thread ID location
<sorear>
if you have a process with one thread, you could have one version of the process address space at a time, but that would require editing page tables every time that thread is scheduled on a new hart
<jrtc27>
if you want to be smart like that
<jrtc27>
or just don't
<jrtc27>
each thread gets its own real page, and that's that
<jrtc27>
what userspace does with it is its choice
<jrtc27>
it's what, 20k, 24k per thread?
<jrtc27>
that's nothing in a modern OS
<sorear>
years ago there was an extension in the works to make ASIDs optionally equivalent between harts for more efficient use of shared L2 TLBs, i don't know if that's still in the works but it would also have problems with any version of this approach
<sorear>
20k, 24k whats? minimum stack size?
<jrtc27>
bytes
<sorear>
yes but for what
<jrtc27>
one 4k page for the page itself, 4 or 5 more for the levels of page table
<jrtc27>
or 3 in puny sv39 land
<jrtc27>
and yeah asids get fun
<sorear>
if you give each thread its own real page, you need a satp switch on every thread switch, which historically defeats the purpose of having threads at all
<jrtc27>
well it depends on how you do asids doesn't it
<jrtc27>
satp switch isn't going to add noticeable overhead when you're already in the os if you can keep the asid
<jrtc27>
anyway, must go for a bit
<jrtc27>
it's probably not the right design but it's not entirely stupid
<jrtc27>
but if you need to mess with asid architecture to make it work well then I guess you might as well just add the one register you need to make it all irrelevant
<sorear>
so satp switch to a new page table base with the same asid, then sfence.vma on the thread page in the scheduler? might work although I'm nervous about assuming that a sfence.vma to a single page will be cheap on all relevant impls
ezulian has joined #riscv
<jrtc27>
yes
<jrtc27>
it's basically just a special modified asid reuse problem
<jrtc27>
and, eh, if software assumes it's fast people will build it fast lest their products be deemed glacial crap
<jrtc27>
:)
<jrtc27>
anyway, really off now
ezulian has quit [Remote host closed the connection]
stolen has quit [Quit: Connection closed for inactivity]
Stat_headcrabed has joined #riscv
Stat_headcrabed has quit [Quit: Stat_headcrabed]
davidlt has joined #riscv
davidlt has quit [Remote host closed the connection]
davidlt has joined #riscv
gianluca has quit [Ping timeout: 256 seconds]
gianluca has joined #riscv
alexghiti has joined #riscv
alexghiti has quit [Ping timeout: 256 seconds]
alexghiti has joined #riscv
alexghiti has quit [Ping timeout: 264 seconds]
junaid_ has joined #riscv
junaid_ has quit [Quit: leaving]
jmdaemon has quit [Ping timeout: 256 seconds]
heat has joined #riscv
crossdev has quit [Ping timeout: 252 seconds]
Andre_Z has joined #riscv
shamoe has joined #riscv
Tenkawa has joined #riscv
<sorear>
interesting that morello gives m-mode free license to create capabilities in registers and write to tag memory
Stat_headcrabed has joined #riscv
esv has joined #riscv
<sorear>
E2H strikes, i was going to ask what the difference was between CPTR_EL2.TC and CPTR_EL2.CEN ...
esv has quit [Ping timeout: 260 seconds]
crabbedhaloablut has quit []
crabbedhaloablut has joined #riscv
esv has joined #riscv
davidlt has quit [Ping timeout: 260 seconds]
<sorear>
kind of odd that cheriot went with a load barrier instead of a store barrier for revocation, there are fewer of those and they're less latency sensity
<courmisch>
I see anathematic Armv8 register names!
<sorear>
what of it
<sorear>
the Am29000 has a branch target cache which stores the first 16 bytes of code at the *targets* of up to 32 branches; i haven't seen that in any modern design, instruction caches and zero-bubble BTBs/next line predictors work too well, but I wonder if it could be a relevant implementation strategy for cheri-type designs where accessing the instruction cache requires a bounds check. a BTC is _not memory_
alexghiti has joined #riscv
Andre_Z has quit [Quit: Leaving.]
MaxGanzII_ has quit [Remote host closed the connection]
MaxGanzII_ has joined #riscv
jacklsw has joined #riscv
n_crm has quit [Quit: ...]
n_crm has joined #riscv
ldevulder has quit [Ping timeout: 264 seconds]
Stat_headcrabed has quit [Quit: Stat_headcrabed]
ksbedfordjr has joined #riscv
<ksbedfordjr>
hey guys
<ksbedfordjr>
what is the server or debian
<ksbedfordjr>
i am having a a odd pkg issue
<ksbedfordjr>
willl post in a min
Stat_headcrabed has joined #riscv
<ksbedfordjr>
it has to do with the start-stop-daemon
<ksbedfordjr>
driving me up a wall
Stat_headcrabed has quit [Client Quit]
<ksbedfordjr>
running build for error
davidlt has joined #riscv
davidlt has quit [Remote host closed the connection]
crossdev has quit [Read error: Connection reset by peer]
erg__ has joined #riscv
erg_ has quit [Ping timeout: 260 seconds]
jacklsw has quit [Quit: Back to the real life]
epony has joined #riscv
psydroid has joined #riscv
esv has quit [Remote host closed the connection]
esv has joined #riscv
ksbedfordjr has quit [Quit: Leaving...]
notgull has joined #riscv
hightower2 has joined #riscv
erg__ has quit [Ping timeout: 240 seconds]
esv has quit [Quit: Leaving]
esv has joined #riscv
notgull has quit [Ping timeout: 256 seconds]
crabbedhaloablut has quit []
crabbedhaloablut has joined #riscv
notgull has joined #riscv
MaxGanzII_ has quit [Remote host closed the connection]
MaxGanzII_ has joined #riscv
MaxGanzII_ has quit [Remote host closed the connection]
MaxGanzII_ has joined #riscv
sevan has quit [Ping timeout: 256 seconds]
EchelonX has joined #riscv
notgull has quit [Ping timeout: 268 seconds]
stolen has quit [Quit: Connection closed for inactivity]
esv has quit [Ping timeout: 268 seconds]
sevan has joined #riscv
sevan has joined #riscv
sevan has quit [Changing host]
khem has joined #riscv
esv has joined #riscv
notgull has joined #riscv
BootLayer has quit [Quit: Leaving]
<dh`>
if you start messing with the mmu to add magic for per-thread pages, the simplest way to do it is with a register to override the page table
esv has quit [Ping timeout: 276 seconds]
esv has joined #riscv
<sorear>
override how
esv has quit [Quit: Leaving]
esv has joined #riscv
<dh`>
simple example: add a register that provides the page table entry for the last page of virtual memory
<dh`>
or the tlb entry, if the tlb entry has more stuff in it
<dh`>
that won't do for threads in user processes, but you could add a second register that holds the virtual address to override
<dh`>
and require an sfence.vma for changing the override address to avoid weirdnesses
<dh`>
it assumes that one page is enough, but it normally is
davidlt has quit [Ping timeout: 260 seconds]
mlw has quit [Ping timeout: 264 seconds]
<sorear>
if I'm going to add a register i might as well add tpidruro and not mess with the translation logic
erg__ has joined #riscv
erg__ has quit [Remote host closed the connection]
<pabs3>
Tenkawa: merged-/usr isn't done in Debian. because usrmerge does terrible hacks behind dpkg's back, and dpkg doesn't like that, we have to do some more terrible hacks to move files inside the .deb files to /usr, to ensure that files don't just disappear on upgrades that move files from / to /usr, and we aren't fixing dpkg, so packages outside of Debian will have the same issue without the same workarounds
<Tenkawa>
pabs3: "Where" it's done is irrelevant... Debian is "using" a combined /usr structure
foton has joined #riscv
<Tenkawa>
That's the only thing I was pointing out
<pabs3>
"done" is the word I was reacting too, perhaps I misread what you meant by it
<Tenkawa>
How/Where/Why... that's for the Debian core to fix... on a running system.. . Debian rootfs /usr and /usr/sbin are not unique
<Tenkawa>
er /sbin
<pabs3>
right
<Tenkawa>
Some people still didn't know that
<pabs3>
huh, its been that way for years
<jrtc27>
sorear: SCTAG exists because Arm were concerned about swap performance, but their firmware turns it off and everyone agrees it shouldn't make it into a product
<Tenkawa>
I know.... "long story..."
<Tenkawa>
lol
foton has quit [Ping timeout: 256 seconds]
foton_x has joined #riscv
<sorear>
why shouldn't it make it into a product? double standard where power/clock glitches setting chcr_el2.settag=1 is considered a catastrophic security flaw, but power/clock glitches setting the tag of a c register is fine?
<jrtc27>
don't care about glitches, if your hardware isn't digital then that's not our problem to solve
<jrtc27>
it shouldn't exist as an option for software to use, as it provides an architectural way to totally bypass the security
<jrtc27>
the only reason you'd want it to exist if there are things that need it to exist, but there aren't, so it shouldn't
<sorear>
but if it were a write-only capability register that contained an infinity cap, that would be fine
sm2n has quit [Read error: Connection reset by peer]
raghavgururajan has quit [Read error: Connection reset by peer]
catcream_ has quit [Read error: Connection reset by peer]
jleightcap has quit [Remote host closed the connection]
sumoon has quit [Remote host closed the connection]
shreyasminocha has quit [Read error: Connection reset by peer]
BratishkaErik has quit [Remote host closed the connection]
pld has quit [Remote host closed the connection]
yyp has quit [Remote host closed the connection]
sumoon has joined #riscv
raghavgururajan has joined #riscv
catcream_ has joined #riscv
shreyasminocha has joined #riscv
pld has joined #riscv
sm2n has joined #riscv
yyp has joined #riscv
BratishkaErik has joined #riscv
jleightcap has joined #riscv
<jrtc27>
hm? write-only capability register?
<sorear>
sorry, write-only capability system register
<sorear>
if you have an infinity cap in a register or system register then any operation is monotonic...
<jrtc27>
if it's write-only then you by definition cannot access it and therefore should not regard it as part of your transitively reachable set of authorities
<sorear>
make it read-write-WARL then, writes to Null or Infinity only
<jrtc27>
and then you don't need the magic instruction
<jrtc27>
you can just read it and buildcap
<jrtc27>
and then no capability forgery is present
<jrtc27>
and who needs a register, just put it in memory somewhere, and you can even have more flexibility than just null or infinity
<jrtc27>
and then you don't need any special architecture
<jrtc27>
this is the point, it buys you nothing but pollutes the architecture to have such an instruction
<jrtc27>
so long as you have an efficient buildcap thing
<jrtc27>
and if you put it in memory, you can build a little compartment to contain the powerful thing
<jrtc27>
which gives you much more fine-grained control over who can use it and for what, with the right software framework
<jrtc27>
rather than an all-or-nothing if and only if M-mode (and hopefully ASR)
<sorear>
CHERI documents are inconsistent on whether buildcap can create sealed capabilities without O(N object types) steps
<sorear>
if the choice is between SCTAG and a hundred ISAv9 CCopyType operations for the object types present in my system...
<jrtc27>
we carefully designed the instructions to not need that
<jrtc27>
clearly O(N) would be untenable
<jrtc27>
we're not stupid...
<jrtc27>
our CHERI has never had SCTAG in it, that was Arm's doing for Morello
<sorear>
"permit a fast branchless rederivation sequence with multiple sealing authorities with a single CBuildCap and a set of CCopyType and CCSeal pairs" i didn't find the definition of "sealing authority" and the only thing I could think of at the time is that it meant one per object type
<sorear>
apparently "pairs" means "one pair"
mwette has joined #riscv
<jrtc27>
it's however many you hav
<jrtc27>
you start with one almighty one and can subdivide it however you like
<jrtc27>
if you want one per otype you can, but that's not particularly efficient if you're juggling a large number of them
<jrtc27>
sealing authority is just a valid unsealed capability with seal permission
JanC_ has joined #riscv
JanC has quit [Killed (lead.libera.chat (Nickname regained by services))]