Linked by Thom Holwerda on Mon 8th Oct 2018 23:51 UTC
OSNews, Generic OSes

This paper presents an evaluation of the use of a high-level language (HLL) with garbage collection to implement a monolithic POSIX-style kernel. The goal is to explore if it is reasonable to use an HLL instead of C for such kernels, by examining performance costs, implementation challenges, and programmability and safety benefits.

The paper contributes Biscuit, a kernel written in Go that implements enough of POSIX (virtual memory, mmap, TCP/IP sockets, a logging file system, poll, etc.) to execute significant applications. Biscuit makes liberal use of Go's HLL features (closures, channels, maps, interfaces, garbage collected heap allocation), which sub- jectively made programming easier. The most challenging puzzle was handling the possibility of running out of kernel heap memory; Biscuit benefited from the analyzability of Go source to address this challenge.

On a set of kernel-intensive benchmarks (including NGINX and Redis) the fraction of kernel CPU time Biscuit spends on HLL features (primarily garbage collection and thread stack expansion checks) ranges up to 13%. The longest single GC-related pause suffered by NGINX was 115 microseconds; the longest observed sum of GC delays to a complete NGINX client request was 600 microsec- onds. In experiments comparing nearly identical system call, page fault, and context switch code paths written in Go and C, the Go version was 5% to 15% slower.

Scientific papers about operating system experiments - who doesn't love them?

Thread beginning with comment 663537
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[10]: Comment by FlyingJester
by moondevil on Thu 11th Oct 2018 18:32 UTC in reply to "RE[9]: Comment by FlyingJester"
moondevil
Member since:
2005-07-08

According to the Linux Security Summit 2018 talks, 68% of the kernel exploits were caused by out-of-bounds memory corruption.

Reply Parent Score: 3

kwan_e Member since:
2007-02-18

According to the Linux Security Summit 2018 talks, 68% of the kernel exploits were caused by out-of-bounds memory corruption.


Yes, but how many of them lead to actual security breaches. An exploit does not necessary lead to an actual incident. You can have exploits for every part of the kernel, but have they actually resulted in sensitive data being accessed?

Compared to when government employees just leave hard drives around, or banks who lose a truck full of backup tapes, or a shopping website leaving customer details in plain text accessible from the internet.

Reply Parent Score: 2

Alfman Member since:
2011-01-28

kwan_e,

Yes, but how many of them lead to actual security breaches. An exploit does not necessary lead to an actual incident. You can have exploits for every part of the kernel, but have they actually resulted in sensitive data being accessed?


The corollary to this argument is how many breaches are unreported or even undetected? Many companies would rather hide their vulnerabilities...

http://www.osnews.com/story/30776/Google_exposed_user_data_chose_to...

Reply Parent Score: 2