211–220 of 280 posts
Why does the compiler not warn if you use a 64 bit unsigned integer when a 32 bit signed integer is required?
Earlier quoted context omitted.
GCC's -Wconversion has some issues. For example, good luck getting gcc to /not/ emit a warning for this code, in C or C++. I have yet to find the appropriate cast to avoid a warning. Clang does not warn for this. typedef struct { unsigned value : 4; } S; void foo(S* s, unsigned value) { // error: conversion from 'unsigned int' to 'unsigned char:4' may change value s->value = value; } I mean, I guess I can see the rat…
Does it still warn if you do `s->value = value & 0x0F`? That seems like a reasonable alternative to pragmas if it works.
Earlier quoted context omitted.
Perhaps a distinction here can be made between running as a server OS and a desktop OS. In a server I generally want a crash immediately. But on a desktop I'd rather it limp along and give me a chance to finish writing my Hackernews post.
I'd rather push the other way on that. We should treat desktops with as much security paranoia at servers. I'd much rather _not_ have my desktop "limp along" in a poorly understood and probably exploitable fashion while the malware gets a chance to finish encrypting all my files... If that costs the world the "benefit" of my shared wisdom in a half written Hackernews post, I'm good with that.
Earlier quoted context omitted.
Yes, arbitrary precision integers could theoretically become a C language/library feature. But let's say that it gets proposed and accepted and it's integrated into popular compiler toolchains. The kernel wouldn't leverage it here or likely anywhere else because of its cost. A newly designed OS kernel could perhaps take on this kind of feature. This would be the kind of OS that could be formally verified and would be…
C doesn’t have the abstraction power to make anything with such a datatype.
typedef struct { /* TODO */ } arb_int;
arb_int *new_arb_int(void);
void delete_arb_int(arb_int *);
arb_int *arb_int_add(arb_int *, arb_int *);
arb_int *arb_int_sub(arb_int *, arb_int *);
arb_int *arb_int_mul(arb_int *, arb_int *);
arb_int *arb_int_div(arb_int *, arb_int *);
bool arb_int_gt(arb_int *, arb_int *);
bool arb_int_lt(arb_int *, arb_int *);
bool arb_int_gte(arb_int *, arb_int *);
bool arb_int_lte(arb_int *, arb_int *);
bool arb_int_eq(arb_int *, arb_int *);Earlier quoted context omitted.
On a server I'd usually want it to limp along too... Better fire an alert but keep happy customers than cause a massive outage just because of someone's overly strict checkfail... It depends really what your server does, and what the consequences of it doing the wrong thing are.
Or just don't put stuff that crashes in pid1
Earlier quoted context omitted.
Poorly designed security architecture and division of labor. A more idealized init / systemd would have all of the execution flow of PID 1 mathematically provably correct, and correspondingly have as small a footprint as possible there. All additional functions would run under one or more child processes (where the bulk of systemd would execute).
"Lets put the graphics drivers in ring 0, for better performance!" -- Windows NT architects, 1996 "Ummm, lets not do that, it's not such a great idea..." -- Windows Vista team, 2006
Earlier quoted context omitted.
Yep: https://github.com/systemd/systemd/commit/b34a4f0e6729de292c... strdupa(input) without any length check Fix is to replace it with unbounded malloc() instead of checking for sane length first.
Good find thanks for sharing. And everyone at work gripes about me carrying the size around with a lot of my variables in the form of a struct. It's strictly a reminder to always be checking the size since I'm juggling with shotguns.
Earlier quoted context omitted.
Probably unbounded alloca() as always.
was that a guess? wtf... btw. it would probably be hard to make the same mistake in rust. unless you write your own code for strings or use strdupa, too via libc. I also do never understand why some libraries use "faster" methods everywhere, unless safer ones. it's not like all interfaces to systemd would need to be fast. but they should be secure.
I don't think you could even call strdupa through libc in rust. I would guess that strdupa is either a macro that uses the alloca compiler intrinsic or is itself a compiler intrinsic. Even if it isn't, it will break assumptions the rust compiler makes about the size of the stack frame.
Earlier quoted context omitted.
Wait how does a user space daemon exhausting its stack lead to a kernel panic?
Poorly designed security architecture and division of labor. A more idealized init / systemd would have all of the execution flow of PID 1 mathematically provably correct, and correspondingly have as small a footprint as possible there. All additional functions would run under one or more child processes (where the bulk of systemd would execute).
A proper init system similar to runit or s6 would be written in something safer (minimum unsafe) like Rust, be modular, simpler, follow UNIX philosophy, and not try to do everything in one process. Microkernel-style.
Earlier quoted context omitted.
Poorly designed security architecture and division of labor. A more idealized init / systemd would have all of the execution flow of PID 1 mathematically provably correct, and correspondingly have as small a footprint as possible there. All additional functions would run under one or more child processes (where the bulk of systemd would execute).
"Lets put the graphics drivers in ring 0, for better performance!" -- Windows NT architects, 1996 "Ummm, lets not do that, it's not such a great idea..." -- Windows Vista team, 2006
https://docs.microsoft.com/en-us/previous-versions//cc750820...