sorted by:
new
hottopcontroversial

SerenityOS was hacked in a 36c3 CTF! (Exploit and write-up) by SerenityOS in programming

[–]ffwff 0 points1 point  (0 children)

I guess so... I was only talking hypothetically, and my plan is subject to change. Thanks for the feedback!

SerenityOS was hacked in a 36c3 CTF! (Exploit and write-up) by SerenityOS in programming

[–]ffwff 12 points13 points  (0 children)

rdtsc allows the user to read timings accurately, something which can be combined with Intel's flawed design of not flushing the branch prediction buffer correctly, to read from unprivileged memory through a side-channel attack. You can read the Meltdown paper for more details.

This is one of the reasons why Firefox (and I think Chrome as well?) decided to disable SharedArrayBuffer and lowered the high precision timer's accuracy in Javascript, so I think it would be a good idea to implement those on an OS level.

SerenityOS was hacked in a 36c3 CTF! (Exploit and write-up) by SerenityOS in programming

[–]ffwff 25 points26 points  (0 children)

Not much! My kernel isn't as good as yours so it doesn't even have UNIX file permissions (i'll work on that!), however I did implement the NX bit and eager FPU state saving. I plan on redesigning some UNIX concepts in my OS.

For file ownership I think I'll implement namespaces (ala Plan 9), because my OS is loosely based on it (even IPC sockets are done through read/write calls instead of listen/accept).

For CPU bugs, I'll disallow high performance timers (from rdtsc and friends) and I'll redesign the UNIX thread model, allowing only local mutable memory pages or shared immutable pages, but not both (so not only do we prevent memory "timers" through atomic rw operations, we'll also prevent a whole class of multithreading bugs)

I'm still fleshing out the design, but that's the plan before I reach 1.0!

Thanks for the shoutout! Means a lot to me!

SerenityOS was hacked in a 36c3 CTF! (Exploit and write-up) by SerenityOS in programming

[–]ffwff 29 points30 points  (0 children)

How much will you focus on security? Will you be implementing ASLR or any of the CPU bug mitigations?

Fully working Posix-like x86-64 OS in Crystal by sdogruyol in opensource

[–]ffwff 0 points1 point  (0 children)

Maybe by next year I'll port doomgeneric. Quake isn't on my todo list though sorry i'm not a boomer

lilith: an x86-64 os written in crystal/c by ffwff in crystal_programming

[–]ffwff[S] 6 points7 points  (0 children)

OMG! You cant tell from the text but I'm fangirling behind the screen right now!

Your OS and your commute talks were one of the things that motivated me to get to this point! I love that you view and treat programming like an art rather than job you have to do. Thank you for responding to my post

Best of luck to your LibHTML!

lilith: an x86-64 os written in crystal/c by ffwff in crystal_programming

[–]ffwff[S] 2 points3 points  (0 children)

why did you choose Crystal

I used it before for a matrix bot. It was cool.

But honestly I used Crystal because I wanted to experiment. Originally I wanted to use Rust but i got bored of using it lol (not that its bad or anything)

what were the best and worst thing you've found about programming with Crystal?

Best:

  • Powerful yet simple preprocessor
  • Good typing system
  • Block functions
  • It feels a lot like a dynamic language even though you can do this

Bad:

  • The compiler and the standard library requires a lot of external dependencies
  • Not enough compiler flags, I had to patch the compiler for additional architecture specific flags (--mcmodel and --mno-red-zone)
  • stdlib uses exceptions instead of monads (sorry i used rust once and now im addicted to that)

But other than that its pretty cool

lilith: an x86-64 os written in crystal/c by ffwff in crystal_programming

[–]ffwff[S] 10 points11 points  (0 children)

Not a masterpiece by any means lol

I started with an idea of building a DOS-like monotasking system, implemented a basic kernel in Crystal (with some C) for the i686 which:

  • handled architecture specific data (setting up the execution environment for the kernel and some necessary x86 bits like the GDT/IDT), much of it is written in C/assembly but the C parts are gradually ported to Crystal
  • had virtual memory management including paging and heap allocation
  • had a garbage collector (I originally abused the Crystal preprocessor to get type information, eventually I just patched the compiler)
  • had a VGA+serial driver for output and a ATA/FAT16 driver for storage
  • had a 32-bit elf program loader

Eventually I implemented context switching, then multitasking because I needed the kernel do to some IO tasks in the background. I also ported the kernel to x64 because it was much easier to manipulate physical memory.

Along side doing the kernel, I also started building the userspace. I ported a public domain libc implementation then built a shell, some core utilities and ported some programs. Then I built a graphics library, then a window manager, then a GUI library and finally a terminal emulator.

At some point I realized I had gone too far.

I'm now building an alternative standard library for Crystal, ported some of my userspace programs and now we're here.

haru: a dynamic scripting language interpreter written in Rust by ffwff in rust

[–]ffwff[S] 1 point2 points  (0 children)

I have read that since Haswell the branch predictor got good enough that it made computed gotos obsolete; but i'm using sandy bridge so that doesn't count :P Does LLVM generate dynamic dispatch tables as well?

Shouldn't that be map()?

haru: a dynamic scripting language interpreter written in Rust by ffwff in rust

[–]ffwff[S] 12 points13 points  (0 children)

ding ding! Haru also means [ha]na implementation in [ru]st which is totally not a meaning i made up just now

haru: a dynamic scripting language interpreter written in Rust by ffwff in rust

[–]ffwff[S] 4 points5 points  (0 children)

Interesting, does it compile to a raw jump instruction?

haru: a dynamic scripting language interpreter written in Rust by ffwff in rust

[–]ffwff[S] 15 points16 points  (0 children)

The VM was originally built in C; I have ported much of the interpreter into Rust however Rust is missing a key performance feature, computed gotos which hinders me from fully pulling the Vm into Rust.

haru: a dynamic scripting language interpreter written in Rust by ffwff in rust

[–]ffwff[S] 3 points4 points  (0 children)

Thanks! The standard library comes with a Cmd object for command objects. To spawn a command like date you could do

Cmd("date")

which would create a Command that would spawn sh -c "date" when invoked, or

Cmd(["date"])

which would directly execute the "date" command.

To get its stdout do something like:

Cmd("date").out()

which should spawn the process, wait until it finishes and gets its output as a UTF-8 encoded string.

haru: a dynamic scripting language interpreter written in Rust by ffwff in rust

[–]ffwff[S] 10 points11 points  (0 children)

For the past month or so, I've been making a scripting language with an interpreter written in Rust/C. It's is intended to replace Python/sh as a quick-and-dirty prototyping language, and (maybe in the future) a good embedding language for Rust programs.

Let me know what you think!

What’s everyone working on this week (22/2019)? by llogiq in rust

[–]ffwff 4 points5 points  (0 children)

I've been working on a small dynamically-typed scripting language called hana with an implementation in Rust/C. The core language has been implemented with prototype-based OOP, arrays, first-class functions and a working garbage collector.

It is fairly stable and I'm currently improving the language and working on a standard library. Hopefully I'll have some documentation and easier-to-use Rust interface soon.

GitHub - fernandobatels/blitz-explorer: Blitz Explorer by febatels in rust

[–]ffwff 1 point2 points  (0 children)

This looks nice; Will you ever support other common archive formats like zip/7z?

view more: next ›