<geist>
oh yeah i should try to add a bochs interface too, curious if that comes up on qemu-arm and qemu-riscv on top of pci
<geist>
well, seems to come up, justh ave to initialize it i guess
<geist>
hmm, seems hard to initialize on arm. it comes up unitilialized, and even linux doesn't initialize it, though it detects it
<geist>
probably some magic vbe stuff you have to write to it a-la how firmware would
<geist>
oh scratch that, linux does eventually initialize it
Lumia has quit [Quit: ,-]
mzxtuelkl has joined #osdev
alpha2023 has joined #osdev
<mrvn>
kingoffrance: extern int foo; is like a prototype, int foo; is a definition.
aoei has joined #osdev
<kingoffrance>
yeah, declaration, definition. i wasnt 100% sure i wasnt missing something, stayed silent but had to chime in late to make myself feel better. also: nethackscoreboard what? welcome aoei
<aoei>
thanks, and er that's just some website that some people on the internet use to track their stats for the computer game 'nethack' and some variants thereof
dude12312414 has joined #osdev
<kingoffrance>
yes, there used to be a devnull halloween tournament or some such :D anyhow
<aoei>
true
<aoei>
im also a dev for the new crappy tournament that holds the same calendar slot but cannot hold the candle to the /dev/null nethack tournament of old
dude12312414 has quit [Client Quit]
<aoei>
(that calendar slot being the month of November)
<aoei>
there's also a better tournament that happens during the month of June but I'm not involved in that as a dev or anything
<aoei>
tbh im surprised you ask about my hostmask at all lol, i only popped in cuz i heard that this channel exists and i have some contacts who are hanging out here
<bslsk05>
github.com: lk/asm.h at master · littlekernel/lk · GitHub
<clever>
ah, this is what i was looking for
<clever>
these macros i think generate debug info, including the size of the function
<mrvn>
the functions in the syscall table might also be out of order and have other functions between them.
<clever>
yeah, the FUNCTION macro does 3 things, 1: defines x as a global symbol, 2: defines its type as function, 3: defines the symbol to point to the current addr
CaCode has quit [Ping timeout: 246 seconds]
<mrvn>
and not all functions may be in the symbol table
<clever>
and END_FUNCTION just does .size on x
Ali_A has joined #osdev
<heat>
get the symbol for the syscall table, get the number of syscalls, now you know everything
<heat>
kallsyms
<l337h4x0r>
I want to copy the syscall body to check against later for modification
<heat>
well, you're kind of screwed
<clever>
a rootkit could set a breakpoint on the syscall entry-point
<clever>
and then do nasty stuff, without ever modifying the body of the syscall
<heat>
a rootkit can install itself as a hypervisor and trap accesses to the syscall stuff
<heat>
you'll never ever notice
<clever>
yep
<heat>
the best protection is to enable secure boot
<l337h4x0r>
can i check what hypervisors are installed?
<heat>
no
<heat>
you are running under the hypervisor
<heat>
you can try and find out if you're under one, but that's non-trivial if the hypervisor writer knows what they're doing and wants to hide it
<heat>
this is why anti-cheats aren't trivial
<clever>
i think this is why you can disable the hypervisor support in the bios
<heat>
you can't know if the bios is running under a hypervisor either :)
<clever>
if you trust that the bios hasnt been hijacked, you can know that the cpu has hypervisor support disabled
<clever>
yeah, you need to trust the bios
<heat>
again, secure boot
<clever>
yep
<clever>
secure boot does multiple things there
<clever>
it can both protect the bios itself, and it can ensure only the OS can run, and not the rootkit hypervisor
<heat>
a rootkit can even install itself in SMM
<heat>
then you can't ever detect it
<clever>
if secure-boot is doing its job properly, and used correctly, only authorized code will ever get into ring0 level, and can interact with things like the hypervisor and SMM
<heat>
clever, the OS will also only load signed kernel modules
<l337h4x0r>
would it need to utilzie SMM vulnb?
<heat>
yes
<clever>
heat: yeah, thats part of using secure boot correctly, dont just let untrusted code into ring0
<l337h4x0r>
well we've seen CIA toolkit, they are not that advanced
<heat>
yes they are
<heat>
we've even seen white hat exploits of SMM
<clever>
arm seems more well designed in this respect
<heat>
fwiw intel is phasing out smm, or at least slimming it down considerably
<clever>
EL0=userland, EL1=kernel, EL2=hypervisor, EL3 is kinda like SMM? but more meant for secure firmware
<clever>
and if your running in EL1, there is no way to ever get access to EL2 or EL3 modes, other then a hypercall/smc into firmware that is already in that mode
<clever>
so you can only run code in EL2 mode, if the existing EL2/EL3 allows it
<clever>
an area that is a mess on x86, isnt hypervisor also ring0?
<heat>
no
<clever>
what ring is the hypervisor in?
<heat>
depends on how you're looking at things
<heat>
if you're under it, like -2
<heat>
if you're not under it, ring 0
<clever>
which makes rings kind of relative
<heat>
yes
<heat>
-1 and -2 and whatnot aren't real
<clever>
but arm doesnt have that mess, EL1 is always kernel, and EL2 is always hypervisor
<heat>
only 0...3 exist
<j`ey>
clever: what about nested virtualisation? :P
<clever>
j`ey: good point, that complicates things
<l337h4x0r>
How common is enabled secure boot these days? Do Windows laptops on the shop come with it enabled?
<heat>
yes
<clever>
l337h4x0r: but in that state, i would consider it totally useless
<l337h4x0r>
It is not that common with people running linux though?
<l337h4x0r>
clever: what do you mean
<heat>
no
<clever>
the microsoft keys, have been used to sign the windows bootloader on the install dvd
mzxtuelkl has quit [Quit: Leaving]
<mrvn>
x86 rings 1/2 are kind of lost territory
<clever>
the bootloader on the install dvd, has a debug feature, that lets it run unsigned binaries
<j`ey>
clever: Apple M2 has nested virt!
<clever>
so a rootkit can use the officially signed bootloader from an install dvd, to run the unsigned rootkit
<clever>
and then run your os, and claim everything is secure
<clever>
MS cant have the keys revoked, because then every install dvd becomes a coaster
<clever>
so its only secure, if you manually revoke the MS keys, and then enroll your own keys, and sign a binary you trust
<mrvn>
And if that wasn't the case making secureboot insecure the NSA could just go to MS and demand the key to sign their own rootkit.
<heat>
you'll never be able to defeat the NSA
<mrvn>
and then china steals that from the CIA and soon every evil has it
<clever>
yeah, thats a threat any time your trusting private keys that an external party holds
<clever>
the same is a risk with the broadcom/rpf secureboot on the CM4
<clever>
the trust root is based on an rsa2048 key, where the public is baked into the maskrom
<clever>
and a TLA could force broadcom to give up the private
<mrvn>
yeah. I want the key read from some dip switches.
<clever>
i would prefer a key read from OTP
<clever>
so i can burn my own key after purchase
<clever>
the RPF secure-boot kinda does that
<mrvn>
clever: how do you burn it a second time?
<clever>
mrvn: you dont
<clever>
for the RPF CM4 secure-boot, the sha256 of a public key is burned into OTP, and the pubkey itself lives in external SPI flash
<clever>
BUT!, the code that validates that hash and enforces it, is itself signed by the broadcom keypair, that is baked into the rom itself
<mrvn>
that's why I want dip switches. So I can change the hash.
<clever>
but if its dip switches, an evil made can just change the key, and run their own stuff
<mrvn>
clever: sure. they can just replace the CM4 module with their own anyway.
<dh`>
any scheme that has one single key of failure for an entire ecosystem makes cracking that key too lucrative
<mrvn>
if they have physical access you have lost
<clever>
mrvn: which is where the 2nd part comes in, store your LUKS key in the OTP
<clever>
so if the SoC is replaced in any way, the key for the rootfs is lost
<clever>
any replacement of the CM4/SoC, results in the new module being unable to read your rootfs, so it just doesnt boot
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
<mrvn>
they can just grab the key when you boot
<l337h4x0r>
What the hell is CM4?
<mrvn>
l337h4x0r: raspberry PI compute module 4
<clever>
mrvn: they cant grab the keys when you boot, because the secure-boot ensures only an authorized kernel can boot
<clever>
tamper with the kernel/firmware, and it wont boot, so you cant access the keys
<mrvn>
clever: yes, so they let the authorized kernel boot and grab the key by patching into the memory bus.
<clever>
yeah, thats about the only attack that would work there
<mrvn>
if they have physical access you have lost
<clever>
either hack the ddr4 bus directly, or get the broadcom keypair that is the trust-root
opal has quit [Quit: i'm never coming back]
the_lanetly_052_ has joined #osdev
Ali_A has quit [Quit: Connection closed]
kspalaiologos has joined #osdev
the_lanetly_052 has quit [Ping timeout: 255 seconds]
opal has joined #osdev
opal has quit [Remote host closed the connection]
<bauen1>
mrvn: most SoCs have some internal SRAM that is big enough to hold multiple private keys, or even come with some dedicated crypto hardware where you can put in some keys ; now of course using that in a way that's secure isn't all that trivial
<clever>
the broadcom soc's also have internal sram, which is used by the bootrom for the stack and such, prior to cache-as-ram being enabled
<clever>
some of the state for hmac checking is also left in the internal sram, which leaks the keys
<bauen1>
I have yet to see a SoC that doesn't mess up their secure boot implementation in one way or another .... (Have yet to take a look at NXP iirc someone told me they have a decent setup)
<clever>
for the bcm2711B1 and bcm2711C0, there are 4 rsa pubkeys in the rom, there is an OTP bit to disable each permanently, and the signature on a binary includes a key-index
<clever>
but the root problem, is that broadcom likely knows the private for all 4
Likorn has joined #osdev
opal has joined #osdev
<clever>
for every pi soc, including the above 2, there is also an hmac mode
<clever>
where a 20 byte constant in the rom, is XOR'd with a 16 byte semi-constant in the OTP, to create an hmac-sha1 key
<clever>
on the bmc2836 and bcm2837, there are no bugs i'm aware of, but once you gain execute, you can dump the keys, and you now own the device
<clever>
but the bcm2835 (pi0/pi1/roku2) has a timing exploit
<clever>
but, RPF is burning the same key into the OTP, for every single pi in a given model
<clever>
so if you buy a pi via the normal channels, the signing key is already known by others, and your screwed
wxwisiasdf has joined #osdev
<clever>
ive heard rumors that you could buy a CM3 with the keys unburnt
<clever>
and then your able to setup proper per-device keys, so even if the attacker can find an exploit, you can patch the software, and then they have to either perform a downgrade attack or find a new exploit
<clever>
and breaking one device doesnt automatically break all
wxwisiasdf has quit [Quit: Lost terminal]
blockhead has joined #osdev
Ali_A has joined #osdev
gildasio has quit [Ping timeout: 268 seconds]
<ddevault>
only two things now stand between me and running doom on my kernel: sleep(2) and a suitable C environment
opal has quit [Remote host closed the connection]
opal has joined #osdev
gildasio has joined #osdev
<mrvn>
ddevault: suitabke C env: set stack, clear .bss, run init_array, done. Sleep? No timers?
<mrvn>
where does doom sleep()? I would believe usleep() but not sleep()
<ddevault>
I also need to write up some C code for syscalls etc
<ddevault>
doom sleeps between frames
<mrvn>
run doom in kernel mode
<ddevault>
no, the whole point is to run it properly as a userspace program
<mrvn>
sleep pauses for N seconds. Not between frames
<ddevault>
usleep, sure
<ddevault>
it's not unix, no one needs a syscall to sleep for seconds
srjek has joined #osdev
Likorn has quit [Quit: WeeChat 3.4.1]
Burgundy has joined #osdev
Likorn has joined #osdev
<l337h4x0r>
I want to hook into process creation and ask the user to whitelist the process before running it, how do I go about detecting new process and pausing it?
<l337h4x0r>
From LKM
<l337h4x0r>
What should I hook into?
<ddevault>
you should probably look for it in the docs, then grep, then write to LKML
<ddevault>
not sure you'll find answers in here
<l337h4x0r>
Do I cover everything with just fork and exec hooks?
<ddevault>
exec alone would probably be sufficient
<ddevault>
this is a very weaksauce security idea fyi
<l337h4x0r>
what's ur idea of strongsauce?
<l337h4x0r>
Do all exec variants end up calling exec?
<ddevault>
containers, or not letting untrusted binaries get onto the system in the first place
<l337h4x0r>
can't do shit about package supply chain on dev machine
<ddevault>
signed executables
<ddevault>
well, package supply chain is the right solution
<ddevault>
so your solution, while perhaps out of your reach for whatever reason, is weaksauce, I'm afraid
<l337h4x0r>
what do you mean by out of your reach? lol
<ddevault>
>can't do shit
<ddevault>
I assure you that you can do shit, I assume there's something which makes you feel like you can't
<ddevault>
like it'd be a lot of work to overhaul a linux distro or something
<ddevault>
but all of them already do package signatures, so
<ddevault>
if it's just a learning exercise, then by all means, worth doing
<l337h4x0r>
doesn't have to be silver bullet, it adds up
<ddevault>
yeah but this one is not really any kind of bullet
<l337h4x0r>
why? it'd stop some npm package from spawning a process
<ddevault>
and it would be super complicated and well beyond the average user's understanding to maintain
<ddevault>
yeah, then mysteriously break it
<l337h4x0r>
better than having it run shit
<ddevault>
and mysteriously break a bunch of other stuff
<ddevault>
and it's trivially worked around by, like, running a python script instead
<l337h4x0r>
im not being targeted by nsa
<ddevault>
unless you intend to whitelist not just argv[0] but the entire argument string
<l337h4x0r>
can just make a special list for interpreters
<ddevault>
well, go for it
<ddevault>
but it is weaksauce
<l337h4x0r>
windows sells shit like glasswire
<mrvn>
You don't need to fork or exec to execute code. Any program can just mmap/mprotect and execute any code.
<ddevault>
for your use-case you should probably just run untrusted software in a container
<ddevault>
good point
<ddevault>
very weaksauce, then
<l337h4x0r>
cant deal with overhead of containers when you gotta churn out tickets
<ddevault>
it's probably weaksauce on windows, too
<ddevault>
what overhead
<mrvn>
or create a file ina dir and execute it, like "./bin/bash". How many users will allow it?
<l337h4x0r>
i dont care about users
<ddevault>
really? you are one
<l337h4x0r>
ill weave together scripts and shit
<ddevault>
you will just end up with security theater
<ddevault>
you'll put trust in a tool that does not work
<ddevault>
if you need a secure solution, use containers
<l337h4x0r>
by containers you dont mean docker right?
<ddevault>
docker is one of many ways to work with containers on linux
<j`ey>
ddevault: you pass a cap to helios::irqcontrol_issue, but it's hardcoded to rt::irqcontrol_label::ISSUE, so no need to pass one
<ddevault>
anyway, you should take this to #linux instead
<l337h4x0r>
but docker is lots of complexity that will slow you down no matter how many scripts you throw at it
<ddevault>
j`ey: err, I don't understand
<ddevault>
helios::irqcontrol_issue does not take a label
<bslsk05>
git.sr.ht: ~sircmpwn/helios: vulcan: use parameter for irqcontrol_issue - sourcehut git
<ddevault>
thanks!
<j`ey>
np
<l337h4x0r>
i asked in #linux if every variant of exec ends up calling exec and they just said "what?"
<l337h4x0r>
lol
<ddevault>
you're on the wrong track, my friend
<ddevault>
if you're prepared to write code to solve this problem, why not look into making containers easier to use (or at least learning about more solutions than just docker)
<ddevault>
user is in predictable paths in vulcan/helios/
<j`ey>
thx
Ali_A has quit [Quit: Connection closed]
Likorn has quit [Quit: WeeChat 3.4.1]
andreas303 has joined #osdev
<j`ey>
ddevault: arch::ipc_recv_into(&recv.state.regs,..) I dont really get this, it's copying some data in some regs structure of another thread.. that might be running or?
SGautam has quit [Quit: Connection closed for inactivity]
<ddevault>
the other thread is not running
<ddevault>
this is a single core non-preemptable kernel
<ddevault>
in any case, the other thread is always blocked
<ddevault>
so even after SMP we'll be golden
<ddevault>
well, mostly. Some shit will have to be fixed
<j`ey>
oh
l337h4x0r has quit [Quit: WeeChat 3.5]
ArcticMonkey has joined #osdev
elastic_dog has quit [Ping timeout: 264 seconds]
Likorn has joined #osdev
elastic_dog has joined #osdev
<geist>
yawn good afternoon everyone
<zid`>
if someone knocks on my door can you let me know
<heat>
depends on the type of food you ordered and if there's any for me
<zid`>
doner wrap, no
<heat>
🙅
<zid`>
what's that in a non-bitmap font?
<heat>
🙅🙅🙅🙅🙅🙅
<zid`>
what're those in a non-bitmap font?
<geist>
dont let them in!
<heat>
screw you and your terminals
<zid`>
I just really like the look of fixedsys
<geist>
(i can't tell what it is here either, it's too small)
<geist>
the f0 and 0a are not part of it, presumably
<clever>
\Test_User: yeah, there is the problem of how irc doesnt really support non-ascii, and every client in the channel has to agree on an encoding
<zid`>
if they don't agree on utf-8 they are however, incorrect
<clever>
ove seen some channels that are split between #foo and #foo.utf8, and a bot converts and bridges them
<geist>
f0 is the text direction marker and the 0a is a CR
<clever>
zid`: in this case, it was s-jis in one room, and utf8 in another
<zid`>
s-jis is about the only other time I see people not using utf-8 yea
<zid`>
but they're still wrong
<heat>
geist, plenty of emojis are composable
<heat>
not just country flags
<clever>
i cant even remember how to configure encoding in irssi
<zid`>
yea there's skin tones and all sorts of stuff
<heat>
even letters
<heat>
(see arabic)
<heat>
all of this makes text rendering non-trivial
<zid`>
which is why you should NEVER try to process strings as language
<zid`>
you ask the unicode and font libraries to turn it into textures it tells you the size of, the end
GeDaMo has quit [Quit: There is as yet insufficient data for a meaningful answer.]
<geist>
Ah looks like sparse files are effectively implemented in nfs v4.2
<geist>
As in prior to that it’s usual semantics: placesyou haven’t written to may be sparse,but the server sends back a string of zeros andyoucan’t DEALLOCATE spots in a file
<geist>
But full support for it is in 4.2 because there’s some new READ_PLUS command that can avoid sending zeros and DEALLOCATE
<geist>
I am interested because i have a bunch of qemu qcow2 images sitting on top of NFS and alas they can’t be reallocated as holes appear, so they tend to grow over time
<geist>
Qemu seems to be fairly good at recycling unused spots in the file since the file itself has its own allocation scheme and knows which parts are unused, but if a file ever grows it doesn’t seem to ever be shrunk or sparsified because nfs 4.1
<geist>
if you're curious about the performance, it's pretty good. but it's a fairly high end synology server and i'm connected to it with 10gbe. the latter seems to make all the difference
<geist>
makes the fairly chattiness of the NFS protocol and the latency go down. nfs v4 helps a lot too, since i think it adds a bunch of batched command stuff and lets the client hold oplocks on the underlying .img files
Lumia has joined #osdev
<gamozo>
Good morning cuties
<psykose>
evening precious
<geist>
hola
* mjg_
blushes
Lumia has quit [Quit: ,-]
Burgundy has quit [Ping timeout: 255 seconds]
jack_rabbit has joined #osdev
knusbaum has quit [Ping timeout: 268 seconds]
<heat>
has any system experimented with deferring tlb shootdowns completely?
<heat>
for user-space as well, not just the kernel
<heat>
i'm thinking it's possible, but non-trivial
<heat>
you need to poison a bunch of pages while the region isn't completely flushed
rorx has quit [Ping timeout: 255 seconds]
<heat>
you can't just say "root can do it" because then root could mess with a kernel module and inject code, defeating signed modules
<geist>
i think you have to define a little closer precisely what sort of tlb shootdowns you're deferring
<geist>
also the architecture, since they have different tools to solve it
<heat>
unmap
<heat>
x86
<heat>
or any x86-like mechanism where you actually need to IPI
<geist>
user space mappings? jkernel mappings?
<heat>
yes user-space
<heat>
I know linux for instance already does it on kernel mappings
<geist>
yeah, so the obvious thing to do is only shoot down for cpus that have the aspace active
<geist>
though the use of PCID changes that calculus somewhat (makes it a much more complicated problem)
<geist>
bbiab, gotta go mow the lawn
<heat>
yes, i'm thinking about like totally deferring it until it switches tasks
<heat>
a-la linux
<heat>
(linux for vmalloc)
<heat>
you should have enough 64-bit address space for that
RAMIII has quit [Quit: WeeChat 3.5]
gxt has quit [Ping timeout: 268 seconds]
<gamozo>
Does anyone know off the top of their heads if armv8.2-a is a superset of armv8.0-a?
gxt has joined #osdev
<gamozo>
Gah I need to do more aarch64, I'm so out of touch
<geist>
gamozo: yes
<geist>
more correctly you should look at the manual and see what parts of it are mandatory and what aren't
<gamozo>
Sounds good, the ARM ARM?
<gamozo>
And thanks
<geist>
it's complicated, but on the surface a armv8.x revision is really just a collection of features, but to be called level X or Y there's a list of features that are mandatory and that aren't
<geist>
including previous versions' mandatory features
<gamozo>
Makes sense
<heat>
the arm leg hehehehehehe
<gamozo>
I'll try to find the official source then, I never like using wikis for stuff this detailed (when making an emulator)
<geist>
yes ARM ARM
<geist>
it is the ultimate truth to ARM, but of course it's hyper complicated. so it goes.
<gamozo>
The challenge is what makes it fun :)
<gamozo>
Looks like a reasonably easy-to-read manual
<geist>
and the armv8 arm got a lot more wordy than v7. i was just reading the other the v7 vs v8 manual describing what instructions can align trap
<geist>
and you can tell it ws two different set of writers: the v7 spec is 'here is a table' and the v8 spec is like 3 pages of paragraphs describing the rules for deciding which instruction should or shouldn't trap
<gamozo>
Does the ARMv8 ARM cover the 32-bit modes or do I still haev to have the ARMv7 ARM for that?
<geist>
arm8 cores 32bit modes
<geist>
covers
<gamozo>
awesome
<geist>
armv8. you know what i mean
<gamozo>
yeah
<geist>
the v8 spec is more complicated because i think it is trying to be more 'correct' from a rules point of view. almost written more to a future implementer of a core than a software person using it
<heat>
:(
<geist>
which kinda makes sense. prior to v8 cores there was only a handful of non ARM implementers of cores, now there are lots
<gamozo>
Yeah, for sure. Definitely seems stricter. I remember them coming out with the XML-definition of the instructions was a big deal