<bslsk05>
github.com: llvm-project/private_typeinfo.cpp at main · llvm/llvm-project · GitHub
<moon-child>
you were making your own implementation of the c++ standard library, right?
<Griwes>
yeah, stubbing out as much of _Unwind and __cxa as I can get away with to get a try-catch to "work" until I actually try to throw an exception right now
<Griwes>
and I went fishing to see how the heck libc++abi actually emits the fundamental type rtti, and, well, that's what I found
<moon-child>
perhaps when I go insane I'll make my own c++ implementation
<moon-child>
stdlib is tamer, but .. still
<Griwes>
I mean at least _Unwind, __cxa, and the personality routine are kinda nicely layered
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
<Griwes>
the downside is that they are dealing with a lot of different nonsense all at the same time
ripmalware_ has joined #osdev
ripmalware has quit [*.net *.split]
teroshan9 has quit [*.net *.split]
Celelibi has quit [*.net *.split]
wolfshappen has quit [*.net *.split]
ngc0202 has quit [*.net *.split]
cross has quit [*.net *.split]
Goodbye_Vincent has quit [*.net *.split]
DonRichie has quit [*.net *.split]
rwb has quit [*.net *.split]
stux has quit [*.net *.split]
genpaku has quit [*.net *.split]
Mutabah has quit [*.net *.split]
klys has quit [*.net *.split]
ornitorrincos has quit [*.net *.split]
kristinam has quit [*.net *.split]
gruetzkopf has quit [*.net *.split]
029AAGSSJ has quit [*.net *.split]
bleb has quit [*.net *.split]
marshmallow has quit [*.net *.split]
pg12 has quit [*.net *.split]
mjg_ has quit [*.net *.split]
kanzure has quit [*.net *.split]
teroshan has joined #osdev
cross has joined #osdev
kristinam has joined #osdev
rwb has joined #osdev
Celelibi has joined #osdev
DonRichie has joined #osdev
gruetzkopf has joined #osdev
Mutabah has joined #osdev
ornitorrincos has joined #osdev
bleb has joined #osdev
marshmallow has joined #osdev
mjg_ has joined #osdev
pg12 has joined #osdev
kanzure has joined #osdev
genpaku has joined #osdev
wolfshappen has joined #osdev
Goodbye_Vincent has joined #osdev
029AAGSSJ has joined #osdev
stux has joined #osdev
ngc0202 has joined #osdev
klys has joined #osdev
Celelibi has quit [Max SendQ exceeded]
stux has quit [Max SendQ exceeded]
bleb has quit [Max SendQ exceeded]
rwb has quit [Max SendQ exceeded]
DonRichie has quit [Max SendQ exceeded]
wolfshappen has quit [Max SendQ exceeded]
bleb has joined #osdev
wolfshappen has joined #osdev
rwb has joined #osdev
<doug16k>
wow, anyone noticing huge chunks of time in delay_tsc in linux? my laptop has every other update of perf top showing it at the top using about 12-18%
Celelibi has joined #osdev
chartreuse has quit [Ping timeout: 272 seconds]
<doug16k>
did 3 frames in a row where it was at the top with 20, 28, then 32%
DonRichie has joined #osdev
<doug16k>
ah, kernel io_delay=none should do it
<doug16k>
if it needs a delay I want it to corrupt
<doug16k>
it's not a pentium 233
<doug16k>
no effect
<doug16k>
strange that I haven't seen io_delay at the top of perf top before
<doug16k>
er, delay_tsc I mean
<geist>
hmm, yeah that is odd
<geist>
could it be because it uses a yield or something and your particular core takes forever?
<doug16k>
I looked at the delay_tsc. it could do efficient wait stuff, where you can pause until a tsc value
<doug16k>
on amd it could montiorx mwaitx. in this case it is an intel haswell
<doug16k>
ah, intel's thing is "tpause"
<doug16k>
I used to see a cstate related symbol before. could be it is showing up cleaner now?
<doug16k>
that's neat though, I didn't know that intel and amd both had wait-for-tsc-value instructions
gog has quit [Ping timeout: 272 seconds]
<zid`>
How'd that sneaky bastard manage that, I have a mosquito bite on my finger
<doug16k>
I guess it is fine to ignore if it is probably doing an efficient wait instruction
chartreuse has joined #osdev
<doug16k>
heh, it's hammering rdtscp on haswell
<doug16k>
63% of time in rdtscp insn
<doug16k>
trying to see where the call comes from with -g, now adler2 in libz is suddenly at top, on idling machine
<doug16k>
did something in the bloat suddenly want to check a bunch of checksums? who knows
<doug16k>
-g backtrace says there is no caller
<doug16k>
funny how useless -g is in perf top. it works in my symbol_server module. stack trace are perfect
<doug16k>
probably because I went full OCD on CFI though
<doug16k>
even with a gigantic ring buffer and it not saying any events were lost, I get almost nonsensical perf top -g
<doug16k>
oh wait. sorry, my instrumented profiler did stacks, but sample one is flat. that's right
gog has joined #osdev
LiChen has joined #osdev
<geist>
doug16k: oh huh. didn't know about the wait-for-tsc thing
toluene has quit [Ping timeout: 255 seconds]
toluene has joined #osdev
GeDaMo has joined #osdev
luzy has joined #osdev
terminalpusher has joined #osdev
<doug16k>
it's funny how many complaints linux has about my haswell gaming laptop's ACPI
<doug16k>
and everything works great
<doug16k>
mce happens too. it's rock solid
<doug16k>
it must be mce errata
<doug16k>
linux panics on some mce, right? why does it just continue?
<doug16k>
linux must know about the errata
<doug16k>
example: ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20210730/nsarguments-61)
<Matt|home>
so modern OSs assign virtual memory addresses to programs to run in userland.. which means you can't access real addresses to do something insidious like access kernel memory right?
<heat>
ell comes from el1
<heat>
Matt|home, yes
<heat>
if by real you mean physical
<mrvn>
Matt|home: yes, no, maybe. yes, no, maybe, actually you still can.
<Matt|home>
historically how was this bypassed and what methods do people use nowadays to break out of virtual memory
<mjg_>
you have the wrong model
<mjg_>
have you read about rings?
<mrvn>
Why would you want to break out of virtual memory?
<zid`>
why would you need to break out of it
<mjg_>
he means form security standapoint i presume
<Matt|home>
it's been a long time and im a bit fucked up from covid. all i remember is that the kernel is usually responsible for assigning and mapping virtual addresses to real ones
<zid`>
Once VMM is enabled I never turn it off
<heat>
there is no way to break out of virtual memory
<mjg_>
to mess with memory you shold not ahve access to
<heat>
except trying to do something with DMA
<zid`>
so presumably you're alluding to something else
<mrvn>
You can break out of virtual memory by hammering the DRAM till it bleeds and a bit flips giving you access to the page tables. Then you make your own virtual memory.
<mjg_>
anyhow, it boils down to do the following idea: the cpu runs userspace code while being in an unprivileged mode
<mjg_>
on x86 & friends that's known as ring 3
<mrvn>
I strongly hope hardware has fixed this in the last decade
<Matt|home>
right. that's a feature of x86 right
<mjg_>
all ways to switch the cpu back to privileged mode also make it jump to code pre-installed by the kernel
<Matt|home>
ring modes?
<mrvn>
Matt|home: yes and no. only x86 calls it rings
<heat>
arm calls it exception levels
<Matt|home>
ok
<mjg_>
so there you have it. modulo a cpu backdoor, you literally can't access anything which was not assigned to you
<mrvn>
mjg_: or other hardware fault
<mjg_>
say you want to write to 0x12345abcd
<heat>
you can use DMA
<heat>
but that involves controlling the hardware
<Matt|home>
okay im a big confused. what's the difference between ring levels and virtual addressing.. just permission? e.g. if you're in this memory section you can write to kernel code or something?
<heat>
no
<heat>
imagine you're a user app
<Matt|home>
k
<heat>
ring 0
<heat>
erm, ring 3 I mean
<heat>
you can only access ring 3 pages
<mrvn>
Matt|home: Page tables usualy have 2 (or more) permission fields. One for user access and one for kernel access (arm has more levels with multiple page tables but that's advanced stuff)
<heat>
if you're at ring 0, you can access ring 0, 1, 2 and 3 pages (there are no 1 and 2 pages in this case, but oh well)
<Matt|home>
right. modern systems usually just skip between 0 and 3 iirc
<heat>
yes, and x86 paging doesn't support granularity there
<heat>
doesn't matter though, think kernel and user
<mrvn>
x86 ring 1+2 are basically useless
<Matt|home>
paging is uh... oh jesus it's been forever. lemme look it up..
<heat>
if you're in user mode, you can only access user pages
<mrvn>
Matt|home: think radix tree
<heat>
if you're in kernel mode, you can access kernel and user pages (note: some architectures have extensions to stop you from accidentally accessing user pages)
<mjg_>
does arm have it?
<heat>
yes
<mrvn>
it's a std::map<virt_addr_t, phys_addr_t>
<Matt|home>
.. so i was correct. it's all about permission. if you're in ring 3 you won't be able to see address space outside of what you're allocated
<Matt|home>
but if you're in ring 0 you can access any page?
<heat>
define see?
<heat>
yes
<heat>
unless you enabled one of the aformentioned extensions, but that's another matter
<Matt|home>
and there's no way to break into ring 0 from ring 3
<mrvn>
Matt|home: no, ring0 uses the same page tables. It just has more permissions
<heat>
there is
SGautam has quit [Quit: Connection closed for inactivity]
<heat>
interrupts and syscall
<heat>
you have a few well defined places you can transition from user mode to kernel mode
<heat>
where you can*
<mrvn>
And if you can bribe the guard you can access any memory by adding it to the page table.
<heat>
we have not had a CPU bug that allowed you to get kernel access magically AFAIK
<mrvn>
And the less code you have running in ring0 the less chance of a bug there is, hence the wish for microkernels.
<Matt|home>
in general for the different major OSs: windows/linux/mac/BSD , historically have they all been on par with their kernel code or has windows been trash
<heat>
the nt kernel is good
<heat>
linux is good
<heat>
mac is weird and decent
<heat>
bsds are good but frequently understaffed
<mrvn>
Matt|home: problem is basically all modern hardware is buggy and lets you get around this for reading virtual memory due to speculative execution.
<heat>
that's not the point here, mrvn
<heat>
doesn't help
<mrvn>
Just saying "no bug" is an illusion.
<Matt|home>
okay let me ask a hopefully easier question
<heat>
ok
<heat>
if I'm explaining you how mov works, I'm not doing a deep dive down the CPU stack
<Matt|home>
percentage-wise , how rare are kernel exploits nowadays that do something dangerous like give you ring 0 access
<heat>
not frequent
<mrvn>
I would say unheard of except for indirectly.
<heat>
indirectly? not frequent
<heat>
directly? never happened AFAIK
<heat>
kernel devs are competent
<Matt|home>
mkay. so if you do find something like that either keep it to yourself or report it ASAP i take it
<mrvn>
Usualy you use one exploit to become root and root has enough permisisons to mess with the kernel, like load a module that then runs in ring0
<heat>
root is generally as useful as you can get
<heat>
even then it doesn't guarantee you kernel level access
<heat>
secure boot enabled systems can't load any module, needs to be signed
jafarlihi has joined #osdev
<mrvn>
Doing things in ring0 is damn hard. Better to become root and be able to easily access files.
<Matt|home>
i appreciate the help guys <3
<jafarlihi>
What is the most low-level thing I can hook in Linux kernel to capture all packets raw?
<mrvn>
jafarlihi: wireshark
<mrvn>
there is only one interface
<heat>
baby shark
<jafarlihi>
No, I need to hook deeper to verify if Wireshark is being fed BS
<jafarlihi>
Don't tell me to MITM
<heat>
there's a baby shark video with 10 billion views wtf
<mrvn>
M-not-ITM
<mrvn>
jafarlihi: you could use iptables with the log target. So I stand corrected, there are 2 interfaces.
<heat>
hahahahahhahahahahahaha
<heat>
wtf
<mrvn>
jafarlihi: The chance of something messing with your network data in a way that iptables would show original data and wireshark fake data is basically 0.
<mrvn>
at least accidentally.
<zid`>
and yet pulling apart and fixing an apollo comms computer has tens of thousands
<jafarlihi>
zid`: link?
<zid`>
Modern education has taught a lot of people how to read, but not what to read :P
<bslsk05>
'Ninja Commando Theme (Atari XL)' by zeusgb (00:02:07)
<zid`>
the battle greg soundtrack is stupidly good for just a random arcade shmup
<mjg_>
feel free to punch the cartoon wall, but i think it sounds like crap
luzy has quit [Ping timeout: 244 seconds]
jafarlihi has quit [Quit: WeeChat 3.5]
k0valski18897 has quit [Ping timeout: 272 seconds]
<geist>
huh looks like those waveforms are completely unbalanced
<geist>
i wonder if that's just an artifact of the sound hardware
<geist>
kinda has a shimmery triangle wave sound to it too
<geist>
also re: americans building stuff out of stone. depends geographically. mostly availability of stone and whether or not you're in a fault zone
<mjg_>
what's fault zone?
<mjg_>
whether you are suspectible to being sorted out by a hurricane?
<gog>
everything here is reinforced concrete because earthquakes
<Griwes>
Whether there's a geological fault under your feet or not
<mjg_>
you reminded me of an entire neighborhood built on top of a closed mine
<gog>
haha tectonic plates go brrr
<Griwes>
For instance, I'm about 2? 3? miles away from where the san andreas fault runs through the bay area, so if it decides to do something up here, I'll have a front row seat
<geist>
yah i've seen far more stone or brick houses and buildings in the south and along the rust belt and whatnot
<gog>
Mid-Atlantic ridge here
<geist>
lots of availability of stone or brick and no earthquakes, and good for hurricanes, etc
<geist>
but west coast it's a really bad idea
<Griwes>
Living on the west coast is a bad idea to begin with, geologically, lol
<geist>
but the weather is so nice!
<Griwes>
That it is
<Griwes>
Okay, more on topic a bit, higher level API question of preferences. Should my syscall wrappers, when handed an untyped kernel object reference, and when creating a typed object wrapping that, do a syscall to check that the type of the kernel object matches, or should they just allow further syscalls to fail due to a type mismatch?
<mjg_>
i'm rather confused what are you trying to accomplish here
<mjg_>
i'll note though that this has some smell of TOCTOU
<zid`>
sounds like some complicated highly level microkernel nonsense
<zid`>
so I tuned out
<mjg_>
that is, by the time you finish making the syscall validating thes tuff, another thread could have fucked it up on purpose
<mjg_>
so you need validation all the way anyway
pretty_dumm_guy has joined #osdev
<Griwes>
That'd be defined to have undefined behavior by the wrapper - no destructive touchy of the kernel object tokens while a wrapper is alive
<Griwes>
That needs to be the case for sanity of the api anyway
<mjg_>
do you have userspace threads?
<mjg_>
if you have anything which can mess with memory writable by the thread which wants to do a syscall, see above
noeontheend has joined #osdev
<Griwes>
What does that have to do with anything
<Griwes>
Data races are already UB by definition
<mjg_>
if the kernel syscalls can't cope with bogus arguments, you are compromised
<Griwes>
This is not a question about api correctness, the kernel checks everything every time
<mjg_>
so far it sounds like you want to do one validation pass upfront
<mjg_>
and not do it later
<Griwes>
I'd appreciate it if you didn't assume a lack of basic competence
<mjg_>
i explicitly asked what you are doing
<Griwes>
You've ignored the part of the question that explicitly asked about higher level api wrappers
<mjg_>
if you validate every time, i don't see any point of the exta syscall
<Griwes>
s/api/syscalls/
<mjg_>
it's just more overhead
<Griwes>
Otoh it's learn that things are wrong earlier vs later
<Griwes>
That's the two things I'm trying to weight against each other and I'm failing to reach a firm conclusion
<Griwes>
mjg_: I'd also appreciate if you didn't miss the part where I also explicitly said that the kernel checks everything every call because it must
<immibis>
Griwes: Sounds like too much overhead
<Griwes>
moon-child: and then... assert on mismatch, right? Throwing out of a "debug" mode failure like that would probably not be great, hmm.
<immibis>
mjg_: I don't think you understood Griwes's question, which is about a userspace wrapper.
<immibis>
the question is: should class CSocket {CSocket(int fd);}; check the fd really refers to a socket?
<immibis>
or should it just trust the fd refers to a socket?
<immibis>
there is no security boundary involved, so either answer is reasonable.
<Griwes>
Yeah.
<moon-child>
Griwes: either way, but seems like an orthogonal consideration
<zid`>
Isn't the point of a high level language to stop you being able to do it at compile time
<geist>
There's a direct analogy to that in the zircon C++ wrapper library we have
<geist>
and rust wrappers around the syscall api, since zircon handles are typed, but only the kernel knows the type
<moon-child>
fwiw I think throwing is probably fine. It would probably be an exception that you wouldn't expect to catch, but if you want to be able to, why not?
<geist>
i think there was a discussion about making a call for this, but decided that in general the overhead is too bad, and in general if you use the wrong syscall on the wrong handle it'll just error anyway
<moon-child>
zid`: yeah, ideally here CSocket would create the fd itself. But I can imagine there would be cases where you would need the extra flexibility
<geist>
what we do have for safety purposes is there's a property. you can set on a process that causes it to instantly abort if you use either a bad handle, or the wrong syscall on the handle
<zid`>
moon-child: I'd wrap the socket api
<geist>
used to catch use-after-frees and whatnot
<zid`>
so that it can only return valid struct socket_wrapper guys or whatever
<zid`>
then your other guy will only get either obviously broken casted inputs, or struct socket_wrapper dudes
<geist>
that's the 'assert on mismatch' thing you were mentioning before, performed by the kernel
<Griwes>
Oooh, I like that
<mjg_>
immibis: no i'm sure i got it right. my point was that whatever validation is performed upfront, has to be performed later anyway
<geist>
that being said i assume you have some sort of call to return the type of the handle?
<geist>
or whether or not the handle is valid?
<Griwes>
zid`: yeah in many cases you'll have the wrappers create the kernel objects, but sometimes you can't have that (for instance if you're being given a kernel object token via IPC where it's just a number)
<geist>
i suppose one could do something VLIW like where user space has to pass as part of the syscall args not only the handle but the type it is. or encode the type itself in the handle value, such that it's intrinsic
<Griwes>
geist: eventually I will have such syscalls, yeah
<geist>
since presumably kernel objects cant mutate from one type to another over their lifetime
<geist>
if the type is encoded in the handle value itself then that removes the toctau (aside from the usual handle is replaced whie you look at it thing)
<Griwes>
I think I like the "debug mode but enforced by the kernel" idea the most
<Griwes>
I really need to start getting to the parts of my os that aren't just zircon but differently opinionated lol
<zid`>
If you want it safe just make it safe imo
<geist>
yah we have a set of debug mode bits that can be set on a process (or job maybe). like 'can't use bad handle' or 'can't touch unmapped memory'
<geist>
things that ordinarily would have been just a runtime error or an exception turn into an instantly fatal kill
<zid`>
It just ends up looking like winapi where nobody can do syscalls and everything is through proxies
<geist>
these are less for safety and more of a kernel enforced assert to find bugs
<geist>
and/or try to make it harder for some compromised process to sniff around
<zid`>
safe as in type-safe
mrvn has quit [Ping timeout: 272 seconds]
* geist
nods
<gorgonical>
paging system works now. Gotta implement cpuinfo stuff now because the aspace system freaks out if it doesn't know what pagesize the platform supports
<geist>
ah indeed
<heat>
4096
<geist>
that's actually a tough question: do you make that hard coded at compile time or run time?
<geist>
i think we kinda screwed up in zircon and started off with it hard coded and then tried to claw it back
<geist>
but probably wont be able to pull it off, since there's too much code hard coded with it at 4k
<gorgonical>
the existing code expects to query the hardware and figure it out somehow
<gorgonical>
fill a cpuinfo struct e.g. from device tree and then use that
<geist>
ah thats good. yeah for ARM you gotta expose all of that in a syscall, as i'm sure you're aware
<dh`>
since it should be a per-machine define, if changing it is hard you've done something worng :-)
<geist>
dh`: yesh but i mean making it *dynamic*
<dh`>
in netbsd we have machines where it's not a constant, yeah
<geist>
changing the define is easy, but making it non constant is the hard part
<dh`>
true
<zid`>
and slow :p
<zid`>
4096 is very shiftable etc, but loading it out of memory's going to meal muls and divs and stuff
<geist>
that's debatable. yes in very specific situations but i bet it's really no big deal in the vast majority of code
<zid`>
yea not really a bottleneck, but feelsbadman
<geist>
yeah but modern hardware eats that shit for breakfast
<geist>
and you can try to arrange your code such that it's known to be apower of 2. right
<geist>
but that does beg the question: will a compiler notice the shift and do it accordingly
<dh`>
PAGE_MASK is not a recommended name because you don't know by looking at it whether it's supposed to be 0xfff or 0xfffff000
<geist>
ie, foo / (1U << a_globla_shift_var)
<doug16k>
I'm a shifting enthusiast
<geist>
presumably the compiler will not flatten the 1U << part and then do a naieve divide
<geist>
it'll know by definition the right side is a power of 2
<dh`>
geist: I wouldn't be surprised if today a compiler turned that into foo >> shift_var
<dh`>
but you ought to have written it that way yourself in the first place...
<geist>
but then of course the edge case there is yo ucant spec it to be within a particular range
<geist>
ie, shift is 0..63 or something
<geist>
so it m ight emit code assuming you can shift off the end of it, etc
<geist>
dh`: sure, but i mean if y=what you ended up doing was setting some sort of global PAGE_SIZE define that is implemented as the shift
<geist>
and people naievely use / PAGE_SIZE, as they will do
<heat>
dh`, it does turn it into >>
<moon-child>
probably shift;cmp;cmov
<moon-child>
still way cheaper than a div
<heat>
compilers are big smart
<dh`>
yeah, what I'm saying is don't do that
<geist>
so there's one of the big answers to it: if you *do* make it dynamic, expose it as the shift count only, so that any code downstream may even naively end up doing the right thing
<geist>
sure but i'm saying dont do that, because the vast majority of code in the world will do / PAGE_SIZE
<geist>
even if you tell them not to
<geist>
and by then the compiler has lost that it's a power of 2
<geist>
unless you define page_size in terms of the shift
<dh`>
maybe
<geist>
(this is for the dynamic case)
<heat>
that's not quite true in kernel space tho
<heat>
it's strictly banned in linux AIUI
<geist>
for the static case, yeah either works because it'll probably be a constant
sortie has quit [Quit: Leaving]
<geist>
heat: that's because they dont let you do / in linux kernel
<geist>
which is a bit extreme, but they have Reasons
<heat>
portability baebah
<doug16k>
geist, sounds easy until pointer arithmetic
<dh`>
anyway it shouldn'e be exposed as a constant to userland so the worst you need to do is recompile the kernel
<geist>
dh`: question is should it be exposed as a #define that hides a non constant
<geist>
that's sort of the second tier of this
<heat>
yes
<heat>
why? looks better
<geist>
because now for loops and wehatnot end up a lot more expensive
sortie has joined #osdev
<geist>
since code doesn't know its non constant
<heat>
also fits in with already existing kernel code
<dh`>
there's little call to do any such thing in userland
<dh`>
oh, for a microkernel, hmm
<geist>
well microkernel or not
<heat>
geist, you could const it I imagine
<geist>
heat: but then it's not dynamic
<heat>
it is
<heat>
through Magic(tm)
<dh`>
if it's not a microkernel the only time it really comes up in userland is in linker scripts
<geist>
page size? no way. comes up *all* the time
<geist>
mappping memory for example. you need to know the alignments that are expected
<heat>
it's a common way to scale memory usage I've heard
<dh`>
where? now and then you need page-aligned memory allocations but that's rare
<geist>
sure but that's a thing
xenos1984 has quit [Read error: Connection reset by peer]
<doug16k>
gcc probably coddles linux and avoids optimizations that would need a divide too
<dh`>
most cases you just feed mmap a size and it rounds it up for you
<geist>
well sure. but i'm thinking largely about the large block of 'system code'
<geist>
but you're right,m there's more of it in microkernels
<geist>
drivers, etc frequently care, and now they're in user space
<dh`>
because microkernels export half the VM system to userspace that code needs to know about it
<geist>
well i wouldn't say that, it's more like runtimes (say JITters) or drivers and whatnot
<geist>
and low level library stuff. heaps etc
<geist>
things that futz directly with the VM
<dh`>
wouldn't you? in L4 you have to stick pages into maps by hand with capabilities
<geist>
that's L4s design. dont assume µkernels are all implemented the same way
<geist>
it's a huge wide continuum of design choices
<dh`>
sure but I thought that was fairly standard now
<geist>
nope.
<heat>
did you just map µ into your keyboard for work purposes
<dh`>
new
<dh`>
er
<dh`>
mew
<geist>
not at all. L4 was explicitly designed to be on the extreme minimal end of things. i think of it as like a 2/10, left side of the scale
<geist>
vs stuff on the right side of the µkernel scale, like mach or zircon
<dh`>
as you like, I think it's all misguided ;-)
<geist>
fine. but that doesn't contribute to the discussion
<dh`>
I know
<dh`>
hence the ;-)
tsraoien has quit [Ping timeout: 240 seconds]
<dh`>
anyway to avoid drifting off the original topic, it's reasonable for a microkernel to need to export the page size
<geist>
again i dont think it's a microkernel vs mono thing
<geist>
it's simply a thing. user space needs to know the page size for a variety of reasons
<geist>
if it's static you can hard code it, if it's not static then <problems ensue>
<dh`>
yeah but it comes up rarely and mostly only inside libc if you aren't doing stuff like userland drivers
<geist>
fine. if you insist.
<GeDaMo>
On Linux, compose / u gives µ
<doug16k>
compose?
<dh`>
anyway the really exciting case is if you have heterogeneous cpus and they have different MMU properties
<geist>
(on mac it seems to be option-m gets you µ)
<GeDaMo>
I have compose in place of caps lock
<zid`>
windows is annoying all I can type is é
<GeDaMo>
I forget how I did that :/
<zid`>
and I'm too lazy to make my own layout with a bunch of cool stuff
<geist>
dh`: yeah. actually that's a thing that i've only seen on macos thus far, and it's not talked about much: limiting particular programs to particular cpus based on features of said cpu
<geist>
you cold do it with 12th gen intels if you enabled AVX512 on the big cores, for example
<geist>
but i dont think linux/windows has support for that. yet.
<geist>
but seems that macos quietly does it for their big/little cores with things like the x86 emulation. i think
<mjg_>
afair there is no scheduler support for big/little to begin with
<mjg_>
in linux
<dh`>
in most cases nobody has adequate arrangements for machine models even when they aren't appearing two or more at a time
<geist>
so far arm for example insists that all big.little pairs of cores must have equivalent ISAs and feature sets to avoid the problem
<dh`>
that is a reasonable and sane thing to do, so it won't last :-)
<geist>
all that aside, if you had a hard affinity capability in your scheduler it stands to reason one could simply pin particular programs on particular cores based on what it knows it's going to need
<geist>
and the hard part is all the details of figuring that out
<dh`>
yeah, it's knowing that that's hard
<geist>
or.... trapping the first use of the instruction and then setting it up after the fact
<GeDaMo>
doug16k: it was something to do with setkbdmap
<dh`>
it's already a shitshow if you want to try to compile with the latest vector unit support or not
<geist>
like notice there's an AVX512 and then going, oops gotta run here
<mjg_>
i would imagine elf notes or something
<mjg_>
to indicate what instructions are in use
<mjg_>
i would argue trapping on first use may be way too late performance-wise
<geist>
possibly
<CompanionCube>
heh, the x86_64 openvms apparently just had the production release
<dh`>
yeah you could imagine an elf notes scheme, but it doesn't exist (afaik)
<geist>
oh also in osdev news, apparently DRDOS owner, who apparently owns the rights to CP/M, has declared that you can use CP/M source license free now
<geist>
defacto that's been the case but it's been a grey area legally
<CompanionCube>
this will be cool in the future: 'VSI is also planning on making OpenVMS V9.2 available to hobbyists as soon as more native compilers are available.'
<mjg_>
well now i know what i'm switching to
<geist>
CompanionCube: nice. i was wondering about that
<dh`>
is there a canonical CP/M source floating around?
<bslsk05>
atari.org: The Atari ST Quick FAQ - 3. Hardware
<geist>
that being said hacking my own runtime on top of thigns is also fun, but it's kinda like writing an emulator: you get to explore the hardware in a more intimate level
<GeDaMo>
"3.6 The Universal 4 Inch Drop Fix(tm)."
<geist>
and yeah running modern netbsd on things is kinda ho hum. it's interesting, but my experience is it's usually dissapointing
<dh`>
yeah
<geist>
you get the thing you already know (netbsd) and it runs like shit on old hardware
<geist>
and then, that's it.
<dh`>
yup
<mjg_>
my heard bled when some guy booted linux on E10k
<mjg_>
like what are you even doing
<mjg_>
i could understand if he was porting it at least
<mjg_>
and i'm not even a sun fanboy
<geist>
yah mind you i *have* installs of netbsd on my sparcstation and microvax
<mjg_>
(contrary in f act :>)
<geist>
but that's mostly so i have some known place to get to scsi and test the hardware, etc
<geist>
kinda the equivalent of booting off a usb key to image a hard drive, etc
<dh`>
i am much more inclined to try porting old software to new hardware
<mjg_>
old software tends to be utter crap
<mjg_>
especially if it originated in the unix land
<dh`>
well yes
<geist>
or writing emulators. been done, but it's a way to get familiar with it
<dh`>
sometimes it also needs to be maintained
<geist>
i personally still think things like openvms or 60s-70s things like TOPs-20 and whatnot are interesting to explore as a user or system admin
<geist>
since they're pretty far out of the unix way of thinking, but still functional systems
<geist>
there are ideas there that are simply lost or implicitly not taken because unix
<dh`>
I had my fill of vms in the 90s, but other stuff yeah
<geist>
not that unix is bad per se, but it has particular ways of going about things that are kinda implicit, and have basically informed all surviving oses since
<dh`>
even vms has some salvageable ideas in it
<geist>
yah totally
<dh`>
one thing that struck me in the 90s was you can reconnect to your session if you get hung up on
<dh`>
in unix? fuck that
<dh`>
why can't job control move processes between sessions? it's not actually that difficult
<mjg_>
well unix is workking around it
<mjg_>
tmux
<geist>
yah exacty that's one of the things thats somewhat implicit in unix that has mostly 'infected' everything downsream of it
<geist>
jobs, process heirarchy, etc
<mjg_>
does anyone even use job control anymore?
<geist>
for better or worse, it is just sort of assumed that you create a process and it belongs to the parent (until you make it not by reparenting)
<mjg_>
apart from old farts
<geist>
you mean ctrl-z etc?
<dh`>
what level of "anybody" are you talking about? normals are afraid of opening the shell at all
<mjg_>
./crap &
<mjg_>
anybody using unix systems on daily basis
<geist>
yeah i think most reasonably power users of the posix shell would use that, yes
<geist>
also opening editor, ctrl-z to close it, do something else, fg to bring it back
<mjg_>
my point being that screen (and now tmux) mostly elides any use for it
<geist>
that's pretty. helpful, especially when editing some system config file
<mjg_>
i knew a guy was doin his, except he never fg'ed back but re-opened vim foo.c
<geist>
(hrm, why do i keep getting stray . in my text)
<mjg_>
which already compained that the file is already open in another vim
<mjg_>
and he would override that
<mjg_>
smh
<mjg_>
but ye, a valid use case :)
<dh`>
are you typing on an apple device? I've noticed that lately with my apple device
<dh`>
s
<geist>
dh`: actually yes. I'm noticing it today
<dh`>
hitting space twice is supposed to be a shortcut for period, I think
<geist>
ooooh! yep yep
<dh`>
but I think there are also some recent autocorrect bugs
<geist>
yah, at the end of a word. did they add that? /me goes to figure out how to turn that off
<dh`>
what I really hate is when it autocorrects, you go back and retype it, it autocorrects again
<geist>
yep there's a checkbox for it in the keyboard settings righ tthere. even if it were a good idea i wouldn't want to get used to it because then it'd just be frustrating when not using the mac
<bslsk05>
www.solveyourtech.com: How to Turn Off the iPhone Double Space Period Shortcut - Solve Your Tech
<geist>
yah this is actually on my phyiscal mac. interesting that it doesn't do any of the other autocorrect stuff here (in irccloud in chrome) but the double space thing does
<geist>
so it has some sort of higher priority
<dh`>
I've given up on arguing with it
<geist>
the double space thing does seem like a good idea that can get used to, but dont wanna get tied to apple things
<dh`>
phone keyboards without autocorrect are unusable
<geist>
oh 100%. which is why i just sort of have to deal with it there when i'm on my ipad. what i would like is some way to disable it if i'm using a physicalkeyboard on the ipad
<dh`>
and nobody makes slider phones any more
<geist>
but i mostly consume data when on ipad anyway, except when i type in here sometimes
<geist>
if you see me capitalizing words and whatnot, it's because i'm on it
<geist>
anyway, off to do real work for a bit
<dh`>
maybe I should get a bluetooth keyboard for the phone, since these days the phone rarely leaves the charger so there's no real need for it to be portable
<dh`>
yeah I should work too
doug16k has quit [Quit: Leaving]
GeDaMo has quit [Quit: There is as yet insufficient data for a meaningful answer.]
<geist>
i use one at home, mostly an extravagance, but i have a bit of concern about bluetooth keyboards in the wild. mostly encryption, etc
<geist>
since i *assume* one can easily determine what you're typing based on just spaces between letters
<geist>
one must type without rhythm, so as not to attract the worm
<dh`>
yeah, I leave bluetooth disabled on all devices except when I'm actively using it and only do that at home
<dh`>
(that kind of timing attack is well established, yes)
<friedy>
You can figure out what somebody is typing just by listening to the sound?
<friedy>
Oh you mean Bluetooth keyboard nvm
<dh`>
listening too, yeah
nick64 has joined #osdev
<friedy>
I remember someone telling me that you could take a pair of laptop speakers and turn it into a microphone in software.
<zid`>
any set of either is both
<friedy>
then listen to the keystrokes.
<zid`>
it's just VERY hard to hear a microphone :P
<zid`>
and the hw might not be set up to do it
<dh`>
in software seems unlikely
<gorgonical>
friedy: I saw an interesting talk from a guy from microsoft research about how with a simple circuit you can turn earphones into a mic that can do all sorts of stuff
<friedy>
gorgonical: That's why we need hardware verification. How can we make sure that something we buy does what it's supposed to do.
<gorgonical>
True. The dongle in this case was an amplifier for the reversed mic. The earphones generate current like a mic does but it's very minuscule
<friedy>
I guess you could formally verify hardware, but if your assumptions are wrong then well...
<zid`>
yea the difference is just whether the design is to generate movement in a cone via EMF, or to generate EMF
<zid`>
they're fundamentally the same object
<zid`>
coil with a core connected to a cone
<gorgonical>
turns out the shape of your ear can be interrogated by this device and used as a biometric
<geist>
yah i figure hey folks probably aren't sitting around pointing a mic at your keyboard, but it's probably fairly trivial to just build some little arduino thing that just hoovers up bluetooth for a while and then after the fact decodes keystrokes
<geist>
and yo udont hve to be that visible. seems easy enough to just go out fishing a while and see what you get later
<geist>
mice i have less of a problem with, but it's probably bad for reasons i honestly just dont want to know
<mats1>
bluetooth tends to be more secure, in relative terms
<mats1>
see mousejack for some of the fun neighbourly things you can do with nrf24 devices
* moon-child
points a laser at geist's window and uses it to measure hdd vibrations
<mats1>
wouldn't be surprised if there's a lot of bt devices with nonexistent or shite crypto though
noeontheend has quit [Ping timeout: 272 seconds]
<geist>
yah but that's my point, the space between transmissions on a keyboard are the issue. doesn't matter how crypto it is
<geist>
and i kinda doubt they just cotinually transmit. maybe that's the idea though. once it senses a keystroke it goes into a flood mode for some period of time to hide the keys
<geist>
folks pointing lasers at my windows, well there's not much i can do about that
<mats1>
iirc there's a program at darpa with this scam
<mats1>
keylog via timing and acoustic side channel
<geist>
yah that seems like it'd be easy enough to just do without much effort
<geist>
though maybe you need to have a fairly good model of each person. but i bet most people's typing just falls fairly comfortably within a few buckets
<mats1>
i've read another paper where an attacker consumes keystroke timing information from a user in an interactive ssh session
<mats1>
which wouldn't work on someone who prepares their remote commands into a text editor first
<moon-child>
oh like sniffing net packets?
<moon-child>
neat
<mats1>
yes
<mrvn>
That's like decoding encrypted voice-over-ip by matching the encoded block sizes to vowels.
<moon-child>
seems like a difficulty would be cutting through the chaff
<moon-child>
as well as plain noise
<mrvn>
moon-child: You can produce quite recognisable speach from just the packet sizes of voice-over-ip.
<mrvn>
iirc
<geist>
yah. as a side note apparently that's why Signal uses a constant bit rate codec for voice and video
<geist>
not as optimal, but it's intended to hide that stuff
<mrvn>
Not so sure it matters for video but for voice it's essential. With a known codec you know the bitrate different sounds and words produce.
MarchHare has quit [Ping timeout: 272 seconds]
* gog
chases the laser dots appearing from nowhere
laocid has quit [Quit: Leaving]
nyah has quit [Ping timeout: 240 seconds]
[itchyjunk] has quit [Ping timeout: 244 seconds]
noeontheend has joined #osdev
[itchyjunk] has joined #osdev
<zid`>
good news, there's a car alarm going off
<zid`>
and the owner seems not to care, so I guess I just have to wait for the battery to go flat
frkazoid333 has quit [Ping timeout: 244 seconds]
<zid`>
I hope, if it's a house alarm we're screwed
tsraoien has joined #osdev
<gog>
go put bologna slices on the hood
<zid`>
I'm not sure I have access to bologna, I've never seen any at least
<zid`>
will a haddock do
Gooberpatrol66 has quit [Quit: Leaving]
<gog>
sure
<zid`>
how does one typically put an entire northern italian city state onto a car anyway