Hacker News new | ask | show | jobs
by chinarulezzz 2918 days ago
>Memory Safe + Fast

$ grep 'unsafe {' -R ~/oxy --include=*.rs | wc -l

13

Not bad.

3 comments

That is not bad after all, I am not bashing oxy, haven't studied it yet, but don't forget that the dependencies could be using more, and there is a fair few of them[0].

https://github.com/oxy-secure/oxy/blob/571ef12199f8b0f3eca55...

btw, a tool for quickly counting unsafe in dependencies: https://github.com/anderejd/cargo-geiger
It's a good start, but the problems with SSH lately have largely been things like timing attacks that even the smartest compiler won't catch.

In fact a smart optimizing compiler can make that even harder to avoid since it is more difficult to know exactly what machine code it will produce.

I wonder how efficient a counter-measure would be adding small random delays in every part of code, possibly injected at MIR or LLVM level. It might drown any timing information in random noise.

They will definitely lower the performance, but likely a bit slower and more secure connection process is preferable to a less secure one.

From my current understanding adding random noise doesn’t affect most timing attacks because it is averaged out. I may be wrong though
Making everything fixed-time, no matter how fast, would actually have the needed effect, random noise can be statistically removed.
I thought timing attacks only matter for clear data to encrypted data and back part of the library, and as long as they didn’t write any data parsing that is content specific pre or post encryption their encryption and didn’t write their own encryption then there shouldn’t be any major holes.
I think they're all used for FFI:

- in ui.rs, for resetting the blocking state of stdin via fcntl

- in tuntap.rs, for an ioctl to do some tun/tap setup, and resetting errno beforehand

- in pty.rs, for ioctls for controlling terminal admin and setting the terminal size

- in util.rs, for getting the current UID, calling getpwnam or getpwuid, and extracting field values from the resulting passwd struct

I have to confess that i don't know the details of the Linux API well enough to know for sure, but they all look eminently reasonable.