Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft open-sources LiteBox, a security-focused library OS

github.com

Post reply on HN
Print view View original

101–110 of 239 posts

Re: Microsoft open-sources LiteBox, a security-focused library OS

#101

Post by necovek »

CasualSuperman wrote: post #13

With how buggy their flagship OS has become, why would I trust anything else they release to be better? Or even if it does work well now, why should I expect it to stay that way? Microsoft has burned through all possible goodwill at this point, at least for me.

Windows is ultimately a lot more complex, and not open source. This also builds on the Linux ecosystem, so even if it comes from Microsoft, I imagine engineering culture is different from that on Windows and especially their online platforms (that's even worse than Windows if you ask me!).

Re: Microsoft open-sources LiteBox, a security-focused library OS

#103

Post by kccqzy »

bri3d wrote: post #66
kccqzy wrote: post #63

Earlier quoted context omitted.

> So for example with this project, you could take a Linux application's codebase, recompile it linked to LiteBox If you have to recompile, you might as well choose to recompile to WASM+WASI. The sandboxing story here is excellent due to its web origins. I thought the point of LiteBox is that recompilation isn’t needed.

Looking more closely, it looks like there are some "North" sides (platforms) with ABI shims (currently Linux and OP-TEE), but others (Windows, for example), would still require recompilation. > If you have to recompile, you might as well choose to recompile to WASM+WASI. I disagree here; this ignores the entire swath of functionality that an OS or runtime provides? Like, as just as an example, I can't "just recompile…

I had previous experience with WASM on TEE. Just use the foreign function interface. Remember WASM isn’t native code so you still need other native code to run WASM (such as wasmtime), and you can import other native functions into WASM through the runtime.

Re: Microsoft open-sources LiteBox, a security-focused library OS

#104

Post by replooda »

simonw wrote: post #90
CasualSuperman wrote: post #13

With how buggy their flagship OS has become, why would I trust anything else they release to be better? Or even if it does work well now, why should I expect it to stay that way? Microsoft has burned through all possible goodwill at this point, at least for me.

Microsoft employ over 100,000 engineers. I'd advise against assuming that everything produced by any of them is bad because of bugs in Windows.

The criticism was directed at the company's product, not the employees...

Re: Microsoft open-sources LiteBox, a security-focused library OS

#105

Post by m132 »

jph00 wrote: post #76
mananaysiempre wrote: post #70

Earlier quoted context omitted.

> Kernel and low level stuff are actually very stable and good. In their intended applications, which might or might not be the ones you need. The slowness of the filesystem that necessitated a whole custom caching layer in Git for Windows, or the slowness of process creation that necessitated adding “picoprocesses” to the kernel so that WSL1 would perform acceptably and still wasn’t enough for it to survive, those a…

This is not due to slowness of the file system. Native ntfs tools are much faster than Unix ones in some situations. The issue is that running Unix software on windows will naturally have a performance impact. You see the same thing in reverse using Wine on Linux. Windows uses a different design for IO so requires software to be written with that design in mind.

> Native ntfs tools are much faster than Unix ones in some situations. The issue is that running Unix software on windows will naturally have a performance impact. You see the same thing in reverse using Wine on Linux.

Not true. There are increasingly more cases where Windows software, written with Windows in mind and only tested on Windows, performs better atop Wine.

Sure, there are interface incompatibilities that naturally create performance penalties, but a lot of stuff maps 1:1, and Windows was historically designed to support multiple user-space ABIs; Win32 calls are broken down into native kernel calls by kernel32, advapi32, etc., for example, similar to how libc works on Unix-like operating systems.

Re: Microsoft open-sources LiteBox, a security-focused library OS

#106

Post by dooglius »

CasualSuperman wrote: post #13

With how buggy their flagship OS has become, why would I trust anything else they release to be better? Or even if it does work well now, why should I expect it to stay that way? Microsoft has burned through all possible goodwill at this point, at least for me.

MSR is a somewhat independent org; you should be making predictions based on other MSR projects

Re: Microsoft open-sources LiteBox, a security-focused library OS

#107

Post by mananaysiempre »

p_ing wrote: post #82
mananaysiempre wrote: post #70

Earlier quoted context omitted.

> Kernel and low level stuff are actually very stable and good. In their intended applications, which might or might not be the ones you need. The slowness of the filesystem that necessitated a whole custom caching layer in Git for Windows, or the slowness of process creation that necessitated adding “picoprocesses” to the kernel so that WSL1 would perform acceptably and still wasn’t enough for it to survive, those a…

The file system isn't slow. The slowness will be present in any file system due to the file system filters that all file system calls pass though.

Right, by “file system” here I mean all of the layers between the application talking in terms of named files and whatever first starts talking in terms of block addresses.

Also, as far as my (very limited) understanding goes, there are more architectural performance problems than just filters (and, to me, filters don’t necessarily sound like performance bankruptcy, provided the filter in question isn’t mandatory, un-removable Microsoft Defender). I seem to remember that path parsing is accomplished in NT by each handler chopping off the initial portion that it understands and passing the remaining suffix to the next one as an uninterpreted string (cf. COM monikers), unlike Unix where the slash-separated list is baked into the architecture, and the former design makes it much harder to have (what Unix calls) a “dentry cache” that would allow the kernel to look up meanings of popular names without going through the filesystem(s).

Re: Microsoft open-sources LiteBox, a security-focused library OS

#108

Post by exceptione »

p_ing wrote: post #71
exceptione wrote: post #65

Earlier quoted context omitted.

NTFS, not so great.

NTFS is just fine. Stable, reliable, fast, plenty of features for a general purpose file system.

Even with Defender etc off, it is not fun. Lots of small file IO brings it on its knees. Some wants to blame the Windows I/O system, I don't know, but what I do know is that when people choose NTFS it is because they haven't an alternative. Nobody chooses it based on its quality attributes. I dare to say there is no NTFS system that is faster than an EXT4 system.

If even MS internal teams rather want to avoid it, it seems like it isn't a great offering. https://news.ycombinator.com/item?id=41085376#41086062

Re: Microsoft open-sources LiteBox, a security-focused library OS

#109

Post by [deleted] »

replooda wrote: post #104
simonw wrote: post #90

Earlier quoted context omitted.

Microsoft employ over 100,000 engineers. I'd advise against assuming that everything produced by any of them is bad because of bugs in Windows.

The criticism was directed at the company's product, not the employees...

[deleted]

Re: Microsoft open-sources LiteBox, a security-focused library OS

#110

Post by stackghost »

rendaw wrote: post #75
cbondurant wrote: post #18

at first I thought library OS might have meant an OS meant for use at a library. Honestly far less interesting to know I was wrong.

Is it not? You link the "library os" and you no longer need an os (when running in a supervisor) IIUC.

I think parent poster was referring to an actual library, i.e. where you would borrow books.

That's also what I thought this was, and came to the comments expecting to see something neat about why libraries might need bespoke operating systems.

Post reply on HN