On Tue, May 09, 2023 at 05:54:26PM -0400, Kent Overstreet wrote: > > I think it'd be much more practical to find some way of making > vmalloc_exec() more palatable. What are the exact concerns? Having a vmalloc_exec() function (whether it is not exported at all, or exported as a GPL symbol) makes it *much* easier for an exploit writer, since it's a super convenient gadget for use with Returned-oriented-programming[1] to create a writeable, executable space that could then be filled with arbitrary code of the exploit author's arbitrary desire. [1] https://en.wikipedia.org/wiki/Return-oriented_programming The other thing I'll note from examining the code generator, is that it appears that bcachefs *only* has support for x86_64. This brings me back to the days of my youth when all the world was a Vax[2]. :-) 10. Thou shalt foreswear, renounce, and abjure the vile heresy which claimeth that ``All the world's a VAX'', and have no commerce with the benighted heathens who cling to this barbarous belief, that the days of thy program may be long even though the days of thy current machine be short. [ This particular heresy bids fair to be replaced by ``All the world's a Sun'' or ``All the world's a 386'' (this latter being a particularly revolting invention of Satan), but the words apply to all such without limitation. Beware, in particular, of the subtle and terrible ``All the world's a 32-bit machine'', which is almost true today but shall cease to be so before thy resume grows too much longer.] [2] The Ten Commandments for C Programmers (Annotated Edition) https://www.lysator.liu.se/c/ten-commandments.html Seriously, does this mean that bcachefs won't work on Arm systems (arm32 or arm64)? Or Risc V systems? Or S/390's? Or Power architectuers? Or Itanium or PA-RISC systems? (OK, I really don't care all that much about those last two. :-) When people ask me why file systems are so hard to make enterprise ready, I tell them to recall the general advice given to people to write secure, robust systems: (a) avoid premature optimization, (b) avoid fine-grained, multi-threaded programming, as much as possible, because locking bugs are a b*tch, and (c) avoid unnecessary global state as much as possible. File systems tend to violate all of these precepts: (a) people chase benchmark optimizations to the exclusion of all else, because people have an unhealthy obsession with Phornix benchmark articles, (b) file systems tend to be inherently multi-threaded, with lots of locks, and (c) file systems are all about managing global state in the form of files, directories, etc. However, hiding a miniature architecture-specific compiler inside a file system seems to be a rather blatent example of "premature optimization". - Ted
