Functionally, nothing. Literally all that the
chroot() call does is update where the kernel anchors path resolution for your process. In particular, unless you also drop root privileges, you can still access
/sys (because you can just make the appropriate
mount() system calls, no external binary needed), you can still access device nodes (you can just create them with the
mknod() system call, again no external binary needed), and really do just about everything else you can imagine.
If you drop root privileges right after entering the chroot (like most well behaved applications do), you can still do anything you could do from the user context you switch to, provided you don't need any external programs or libraries. that aren't in the chroot environment.
Note however that even then, a chroot is of almost zero practical security value by itself. It's actually really easy to escape a chroot through a wide variety of mechanisms (seriously, just search 'escape from chroot' on your favorite search engine, and you'll find results listing at least half a dozen methods). All that's needed to exploit this in any arbitrary application is an ACE vulnerability. In fact,
chroot() was not originally intended for security at all, it was (and still is) a developers tool intended to allow testing new software in an isolated environment (among other things, these days it's more often used to provide an isolated build environment in automated build and CI systems).