<    April 2017    >
Su Mo Tu We Th Fr Sa  
 2  3  4  5  6  7  8  
 9 10 11 12 13 14 15  
16 17 18 19 20 21 22  
23 24 25 26 27 28 29  
00:00 Nobabs27 joined
00:09 blueness joined
00:32 minimalism joined
00:34 dirac joined
00:43 dirac1 joined
00:46 terran joined
00:51 blueness joined
00:58 testing101 joined
01:21 grayhemp_ joined
01:25 grayhemp joined
01:31 s33se_ joined
01:45 tmh1999 joined
01:46 testing101 joined
01:52 slowpak joined
01:53 grayhemp joined
01:59 Emperor_Earth joined
02:15 <danzarov> Hello, guys! Can someone please help me? I'm trying to create my custom iso with some pre-installed packages on it (binaries). For example, I'd like to generate an iso already containing rtorrent package and binary, ready to use, right after booting it, even before running the setup-alpine installer. Well, what I'm doing right now is basically, creating a apkovl file with lbu pkg, then adding the binary
02:15 <danzarov> using 'lbu inc -v /path/to/bin/rtorrent', then adding these package names to /etc/apk/world file and finally creating the iso using the make process and specifying the apkovl.tar.gz file as a APKOVL parameter (make PROFILE=<alpine~> APKOVL=<http..<file>.apkovl.tar.gz> iso). It kinda works, but it messed up the setup-alpine installer and a bunch of other things..any hint on where i should look at to
02:15 <danzarov> accomplish this?
02:20 uriah joined
02:28 <Shiz> danzarov: seems much easier to add the rtorrent .apk to the .iso and then rtorrent to etc/apk/world in your apkovl
02:30 <Shiz> in the apks/$arch directory on the isoy
02:30 <Shiz> you may need to updat the APKINDEX.tar.gz for that, however
02:30 <Shiz> definitely don't add the binary to the lbu
02:31 <Shiz> danzarov: in fact, just adding rtorrent to alpine.packages should do the trick
02:31 <Shiz> in the alpine-iso dir
02:32 <Shiz> and then rtorrent to /etc/apk/world in the lbu
02:39 grayhemp joined
02:43 kl3_ joined
02:44 <danzarov> Shiz: thank you very much for the help! i'll try this! :))
02:56 testing101 joined
03:04 mguentner joined
03:11 scv joined
03:42 mdillon joined
03:53 mguentner joined
04:10 babs_ joined
04:13 minimalism joined
04:33 mdillon joined
04:37 kunev joined
04:40 tmh1999 joined
05:23 grayhemp joined
06:16 mmlb joined
06:28 hendry joined
06:29 <hendry> hi guys, I need to run a shell script as well as nginx in an Alpine docker container, do you guys recommend a particular supervisor for running them reliably?
06:30 gogoprog joined
06:36 wonton joined
06:39 fabled joined
06:41 t0mmy joined
06:47 <hiro> hendry: sh
06:47 <hiro> i'd run a shell script from a shell script
06:53 Kooda[b] joined
06:53 <hendry> hiro: CMD foo.sh and foo.sh has nginx & and myscript() ... yeah
06:56 <hiro> yeah, i'd just try to start nginx in foreground so that you can keep a subshell blocking so that nginx can restart automatically
07:01 <hendry> foreground you mean myscript & nginx -g daemon off? https://github.com/nginxinc/docker-nginx/blob/master/stable/alpine/Dockerfile#L140
07:03 ostera joined
07:11 Kooda[b] joined
07:13 <hiro> i don't know nginx' command line syntax
07:14 <hiro> i just mean that it should keep a process in the foreground as long as it runs and not fork away and then close the process you started first
07:14 <hiro> so that you can keep a shell blocked and run it in a while
07:19 <hiro> so yeah, something like "don't background" "stay in foreground" "don't deamonize" is normally the right one
07:19 <hiro> but check what it does in detail
07:20 <hiro> you don't wanna disable any shit you need for performance or so :)
07:20 <hiro> i have *tried* to look it up, but their man page is shit
07:33 Kooda[b] joined
07:40 grayhemp joined
07:47 Kooda[b] joined
08:08 royger joined
08:20 Kooda[b] joined
08:27 Kooda[b] joined
08:32 ostera joined
08:45 ostera joined
08:51 fekepp joined
08:52 ostera joined
08:52 Kooda[b] joined
08:57 xsteadfastx joined
09:06 ostera joined
09:09 Kooda[b] joined
09:11 grayhemp joined
09:19 ostera joined
09:23 Kooda[b] joined
09:33 ostera joined
09:40 blueness joined
09:43 terra joined
09:46 ostera joined
10:00 ostera joined
10:10 slowpak left
10:12 kahiru joined
10:12 grayhemp joined
10:14 ostera joined
10:21 fekepp joined
10:27 ostera joined
10:34 blueness joined
10:41 ostera joined
10:44 dasher00 joined
10:55 ostera joined
11:08 ostera joined
11:11 gromero joined
11:22 ostera joined
11:25 blueness joined
11:35 ostera joined
11:43 t0mmy joined
11:43 grayhemp joined
11:49 ostera joined
11:53 gvb joined
12:02 ostera joined
12:16 ostera joined
12:30 ostera joined
12:43 ostera joined
12:53 farosas joined
12:57 ostera joined
13:02 cyborg-one joined
13:11 ostera joined
13:17 Kruppt joined
13:20 ostera joined
13:33 ostera joined
13:40 tmh1999 joined
13:47 ostera joined
13:53 lesion joined
13:54 pidsley joined
13:57 mitchty joined
13:58 dminca joined
14:01 ostera joined
14:07 ^ingo^^^ joined
14:14 ostera joined
14:21 uriah joined
14:28 ostera joined
14:41 ostera joined
14:51 ^ingo^^^ left
14:52 grayhemp joined
14:55 ostera joined
15:07 farosas joined
15:09 ostera joined
15:10 minimalism joined
15:17 Skele joined
15:22 ostera joined
15:36 ostera joined
15:36 blackwind_123 joined
15:47 CharlesN joined
15:48 <CharlesN> I have an application crashing on /lib/ld-linux.so.2: not found.Segmentation fault (core dumped), libc6-compat is already installed
15:49 <CharlesN> it's an old application but was working on rhel
15:49 ostera joined
16:03 ostera joined
16:10 <BitL0G1c> CharlesN - glibc & musl c are not binary compatible - the application would need to be built under musl c
16:10 <Xe> BitL0G1c: libc6-compat
16:11 <Xe> CharlesN: `apk add libc6-compat`
16:13 <BitL0G1c> there are still small differences between the c libraries that are enough to cause a segfault. The simplest way to setup a build environment is to create an alpine lxc container
16:15 <BitL0G1c> & apk add alpine-sdk
16:15 <CharlesN> Xe, libc6-compat is already installed
16:15 <Xe> CharlesN: build it on alpine yeah
16:16 <CharlesN> BitL0G1c, Xe I don't have the source code of this program
16:16 ostera joined
16:16 <Xe> CharlesN: try ubuntu then, you're screwed
16:21 <CharlesN> Xe, ok, I'll do that
16:30 farosas joined
16:30 ostera joined
16:33 grayhemp joined
16:36 sergey_ joined
16:36 <uriah> hmm... seeing what BitL0G1c just wrote makes me think my current work is to no avail
16:38 <CharlesN> Xe, it worked on centos7 with the glibc.i686
16:38 <CharlesN> package
16:39 <uriah> i was hoping i'd be able to get widevine working in alpine just by patching musl with an implementation of the missing symbols for libwidevinecdm.so (firefox), but i guess those "small differences" probably would cause it to segfault anyway
16:39 kl3 joined
16:39 <uriah> who knows, though... it isn't like the code i wrote would be up to par :-/
16:39 <uriah> s/par/standards/
16:41 czart_ joined
16:43 <uriah> BitL0G1c: do you think things might be different/similar in my case?
16:44 ostera joined
16:57 ostera joined
16:59 <BitL0G1c> uriah - in every case it would be best to build completely under musl. if alpine hasn't done it yet - void linux probably has
17:01 <uriah> BitL0G1c: well libwidevine.so is a blob shipped by google, but i think it's compiled for glibc
17:02 <kaniini> the glibc emulation is very much work in progress
17:03 grayhemp joined
17:03 <uriah> kaniini: do you mean libc6-compat?
17:04 <kaniini> yes
17:04 <uriah> ok
17:04 <kaniini> however, widevine is something we want to have work
17:04 <uriah> ok
17:04 <kaniini> so i will probably look at it soon
17:05 <uriah> well
17:05 <uriah> there is this thread: http://www.openwall.com/lists/musl/2015/06/17/1
17:05 <uriah> and i've "tried" to get the suggestions in that thread implemented, but i really think i screwed up / don't know what i'm doing
17:06 <uriah> but of course you've already seen what i've been saying in #musl ;)
17:07 <uriah> i'd submit my current patch to their mailing list, but i have a feeling something is terribly wrong with it, as it triggers grsec limits
17:09 <uriah> so i'm waiting, i have some friends who might be able to take a look / be my second set of eyes/brains... but until then, not sure, as i'm pretty exhausted lately (been dealing with increased inner madness), and don't really feel like i have the energy to figure out things properly
17:10 <uriah> anyway
17:11 <uriah> there's also the fact that i haven't yet run the test c code for these functions which is shipped with glibc code
17:11 ostera joined
17:11 rollniak joined
17:11 <uriah> it's pretty pointless to submit a patch when it's untested imho
17:12 <uriah> but yeah, as i said, i think i need to refresh myself by taking a break from it for 1/2 day to a day or two
17:14 <uriah> kaniini: if you're interested at all, and have a bit of free time to review what i did (it really won't be up to standards in some places), you can look at the latest patch/incremental patch set here: http://sprunge.us/dOhJ [full patch, includes both patches from thread] - http://sprunge.us/BYPf [incremental, shows changes i made to the first patch, and includes non-erroneous changes made from second
17:14 <uriah> patch itt]
17:15 <uriah> but yeah, you probably don't want to run it
17:15 <uriah> not in its current form
17:15 <TemptorSent> uriah: What would probably help is to make a matrix showing the inputs and results in the glibc test files, then determine the logic required to get the same results, rather than trying to reinvent them.
17:16 <TemptorSent> I think you're running in circles trying to make the code 'right' when the behavior expected may not reflect what you expect.
17:16 <uriah> agreed
17:16 <uriah> i've just exhausted myself, and require a breather, i think
17:17 <TemptorSent> Good plan.
17:17 <uriah> :.
17:17 <uriah> :>
17:17 <uriah> most of what i did is, to be honest, "monkey see, monkey do"
17:17 <uriah> which i know is wrong
17:17 preyalone joined
17:18 orbiter joined
17:18 <TemptorSent> Yeah, considering glibc is using some strange semantics in places that don't translate to musl.
17:19 <uriah> hmm...
17:22 t0mmy joined
17:25 ostera joined
17:25 <uriah> TemptorSent: you're probably pretty busy with things, but would you mind taking a look at the sanity of __realpath_chk() in that patch for me please?
17:25 <uriah> i probably made it wrong heh
17:26 <uriah> anyway
17:26 <uriah> i'm going to go play some drums
17:26 <uriah> and maybe take a walk
17:26 gopar joined
17:26 <uriah> cause i feel like i'm intellectually drained
17:26 <uriah> it'll likely help me continue
17:26 <uriah> ttyl ;)
17:28 firebird_ joined
17:29 <TemptorSent> uriah: post the link here please?
17:32 sparklyballs joined
17:33 Berra joined
17:34 grayhemp_ joined
17:34 <kaniini> overall the patch looks mostly okay
17:34 <uriah> TemptorSent: original patch: http://www.openwall.com/lists/musl/2015/06/17/1 - my full patch: http://sprunge.us/dOhJ - changes between the two: http://sprunge.us/BYPf
17:35 ostera joined
17:35 <uriah> kaniini: well, the conditionals are probably mistaken in some places
17:35 <uriah> and i do some rather messy stuff, i think, in some of the functions
17:36 grayhemp_ joined
17:37 <tmh1999> kaniini : what should I do if the builder has network problem fetching packages (404, timeout,etc.) but my local builder does not ?
17:38 grayhemp joined
17:40 <kaniini> i'm not sure
17:40 <kaniini> the builder maintainer i guess should fix it :p
17:45 <uriah> kaniini: if you've spotted any obvious issues, please let me know and i'll try to work on them.
17:46 <kaniini> __vasprintf_chk doesnt check anything
17:46 <kaniini> same for vdprintf
17:46 <kaniini> etc
17:46 <uriah> ok
17:47 <kaniini> stuff like this is wrong:
17:47 <kaniini> + if (count > buflen && r > buflen) a_crash();
17:47 <uriah> those are from the original patch, if it's wrong it must not have been noticed by musl devs
17:47 <kaniini> you should check count > buflen before making the syscall
17:47 <uriah> hmm, ok
17:47 <uriah> i'll change all of those then
17:47 <uriah> so i split them into two conditionals, with the syscall between them?
17:47 <kaniini> that way you know which condition caused it
17:47 <kaniini> yes
17:47 <uriah> true ok
17:48 <uriah> thanks
17:48 <uriah> that shouldn't be too difficult to deal with
17:48 <kaniini> security 101 is never check your inputs at the same time that you check your outputs
17:48 <uriah> good point
17:48 <kaniini> inputs should be checked first, then the wrapped function, then the output should be checked
17:51 <uriah> ok
17:53 <dalias> kaniini, are you sure?
17:53 <kaniini> i am quite sure
17:53 <uriah> uh oh :-/
17:54 grayhemp joined
17:54 <dalias> kaniini, not sure about confstr but for some calls that's definitely wrong and for others it's arguably wrong
17:54 <dalias> for instance this is well-defined
17:55 jzono1 joined
17:55 <kaniini> well i guess it depends
17:55 <dalias> char buf[2]; snprintf(buf, 100, "%c", 65);
17:55 <dalias> it's awful style but well-defined
17:57 <dalias> in the case of __read_chk, the second test "r > buflen" will always be false
17:57 <dalias> i don't know a good way to write this
17:58 <dalias> well..
17:58 <dalias> it would always be false except that this is backwards i think:
17:58 <dalias> buflen>count ? buflen : count
17:58 <uriah> oh ok
17:58 <uriah> sorry about that
17:58 <dalias> should be < rather than > i think, right?
17:58 mortis304 joined
17:59 <uriah> dalias: it's probably wrong everywhere i put it then
17:59 <dalias> yeah i think you did max where you meant min in all those places
17:59 <uriah> ok
17:59 <uriah> my mistake
18:00 <uriah> yeah i see what i did wrong there
18:00 <uriah> i'll fix it
18:01 <uriah> dalias: so, you don't want me to split the conditionals, though?
18:01 <dalias> hm?
18:01 <uriah> like kaniini was suggesting i do
18:01 <dalias> it's not a matter of splitting them or not splitting them
18:01 <dalias> it's a matter of when you can determine that UB was invoked
18:01 <kaniini> yes, what i was really saying is
18:01 <kaniini> you should check
18:02 <kaniini> and make sure that you crash at earliest possible opportunity
18:02 <uriah> ok
18:02 <kaniini> so that if you run gdb
18:02 <dalias> kaniini, i think what you're saying is the problem with the original patch, though
18:02 <uriah> sorry, but could you guys clarify what UB means?
18:02 <kaniini> you know what specifically caused the problem
18:02 <kaniini> uriah: undefined behaviour
18:02 <uriah> oh ok
18:02 <kaniini> doing something you shouldn't be
18:02 <uriah> ty
18:02 <dalias> it caught lots of caller_passed_len > compiler_determined_buf_len cases that were not undefined behavior
18:02 <dalias> like my snprintf example
18:03 <kaniini> dalias: indeed
18:03 <dalias> and in many of them, like read(), i don't know a good fix...
18:03 <kaniini> dalias: so its a little trickier
18:03 <dalias> yes
18:03 <dalias> there's a lot of trickiness/subtlety to this
18:03 <dalias> and some of it is even about things where the correct interpretation of the standard is unclear :(
18:03 <uriah> :-/
18:04 <uriah> i see...
18:04 <dalias> fwiw passing (size_t)-1 to read() for "unlimited length", which seems (per posix) like it should be safe and valid as long as the actual file size is bounded and fits in the buffer...
18:04 <dalias> ...causes the kernel to return -EFAULT
18:05 <uriah> hmm...
18:05 <dalias> and i don't see any valid way to work around that
18:05 <dalias> so it's possible that posix is just wrong/unclear and passing a value larger than the buffer size should just be UB
18:05 <dalias> in which case it would be fine to do what kaniini suggests and a_crash() immediately if that happens
18:06 <dalias> so part of what has been stalling this issue is not missing code
18:06 <dalias> but missing interpretation of the standard :(
18:06 <uriah> i see
18:06 <kaniini> it seems to me that it should be undefined behaviour in the _chk() case
18:07 <kaniini> but that is based on about 5 minutes of thinking about the problem
18:08 <uriah> dalias: kaniini: btw thanks for taking time out of your day for this... i'll try not to disappoint
18:09 <uriah> but yeah, sorry if some of the later code changes i made make you cringe :-/
18:10 <kaniini> dalias: in my opinion, i stand by what i originally said -- checked calls must be UB if the value is larger than buffer size
18:10 <kaniini> dalias: because silent truncation is arguably a security risk in many cases
18:11 <kaniini> which is really the alternative
18:11 <dalias> i gave you a strong example where that's not valid -- the snprintf one
18:12 <dalias> the ultimate example of this is all uses of sprintf
18:12 <dalias> which are just calls to snprintf with n==SIZE_MAX
18:12 <dalias> others are less clear
18:13 <uriah> dalias: you might call me on this later, but yeah, i can see why it's important for this kind of info to be put on the mailing list instead of in an irc channel...
18:13 <dalias> another pretty good example is wc[r]tomb where in general you need to know the conversion will fit
18:14 <dalias> but if you already measured before starting the conversion, just passing MB_LEN_MAX on each call makes sense
18:14 <dalias> when it comes time to convert the terminating null char there will only be 1 byte left in the buffer, but the call with MB_LEN_MAX is still valid because the code already determined that the total length fits
18:16 <kaniini> right that is basically what i'm saying
18:16 <dalias> so it's not a matter of "are there cases where you can't assume UB just because n>bos?"
18:16 <dalias> but rather "where is the cutoff point where assuming n>box implies UB?"
18:18 <TemptorSent> Hmm, shouldn't any attempt that exceeds the bounds explicitly given fail?
18:19 cyborg-one joined
18:19 <TemptorSent> And only then check if the result would fit in the specified buffer if it's SMALLER than the max allowable?
18:20 <kaniini> yes
18:20 <TemptorSent> The three options for behavior in the _chk functions are a_crash, return <error value>, or return value that function returns.
18:20 <kaniini> that is what i am saying :p
18:21 <dalias> the goal is to crash if performing the operation would invoke ub
18:21 blueness joined
18:21 <dalias> the problem is that sometimes you can't determine if the operation would invoke ub without performing it
18:22 <TemptorSent> If the specified output buffer is larger than the max size returned by the function, it's safe to call the function.
18:22 <uriah> ah...
18:22 <dalias> in the case of snprintf you can
18:22 grayhemp joined
18:22 <dalias> pass min(n, buf_size)
18:23 <TemptorSent> If it's smaller, we need allocate a buffer of the max size the function can return, evaluate the function to that buffer, then crash if it wouldn't fit, otherwise return the result.
18:23 <uriah> dalias: i guess in these cases there would need to be a special helper function that could somehow determine whether UB would be invoked on the kernel level?
18:23 <dalias> then crash if return value is >buf_size
18:23 <kaniini> isnt it possible to find out from snprintf
18:23 <kaniini> how much space is actually required
18:23 <dalias> right
18:23 <kaniini> i recall doing this once
18:23 <TemptorSent> The safe way to do it is waste some known stack rather than heap.
18:23 <dalias> snprintf returns the space actually required (-1)
18:23 <kaniini> right -1 indeed
18:24 <kaniini> :)
18:24 <dalias> temptorsent, no, that's just going to overflow your stack
18:24 <dalias> which is even worse
18:24 <kaniini> yeah dont use stack for that
18:24 <TemptorSent> dalias: Not when you allocate a FIXED size.
18:24 <dalias> depends on how large it is, but in order to do that for read you'd need to allocate an arbitrarily large temp buffer i think...
18:25 <TemptorSent> LiENUS: char tmp[PATH_MAX]
18:25 <TemptorSent> ie char tmp[PATH_MAX]
18:25 <dalias> for readlink it should be safe to do that
18:25 <uriah> is readlink actually ok?
18:25 <TemptorSent> For anything you have a known limit, that should be safe.
18:25 <dalias> temptorsent, depends on how high that known limit is
18:26 <TemptorSent> for snprintf, you could do it chunkwise I suppose.
18:26 <dalias> 4k, sure, ok
18:26 <kaniini> yes path_max is sane for readlink
18:26 <kaniini> imo
18:26 <dalias> temptorsent, snprintf cannot be done chunkwise but it's not needed at all
18:26 <dalias> snprintf returns the amount that would have been needed
18:26 <kaniini> yes with snprintf you use -1
18:26 <dalias> -1?
18:26 <dalias> snprintf only returns -1 on error
18:26 <kaniini> for the size
18:26 <dalias> the -1 i said above was -1 offset from buffer size
18:27 <dalias> you don't pass -1 either
18:27 <uriah> hmm...
18:27 <kaniini> yes
18:27 <kaniini> exactly
18:27 <kaniini> bufsize-1
18:27 <uriah> ok there's another problem with my code then i think, this being read
18:27 <dalias> you do vsnprintf(buf, min(n, buf_size), fmt, ap);
18:27 <kaniini> if it returns that it needs more
18:27 <kaniini> fail
18:27 <dalias> and then if the return value is >= buf_size you crash
18:27 <uriah> see all of that strnlen(foo, bar) + 1 stuff?
18:27 <kaniini> yep
18:27 grayhemp joined
18:27 <uriah> it probably shouldn't be everywhere, right?
18:28 <dalias> that safely checks for UB in the caller without invoking UB
18:28 <TemptorSent> Sorry, not snprintf, v*printf
18:28 <TemptorSent> That's the set that needs chunking.
18:28 <dalias> chunking is just not possible at all
18:28 <kaniini> vsnprintf does not need chunking
18:28 <dalias> you can't break up format strings
18:28 <dalias> thankfully you don't need to
18:29 <kaniini> you handle it like snprintf
18:29 <TemptorSent> No, I mean in checking the allocation.
18:29 <dalias> the snprintf api is nice
18:29 <TemptorSent> You can check the buffer, then check the result size and crash at both points if it exceeds.
18:30 <TemptorSent> So you can avoid passing bad params to snprintf, then check the return, then evaluate.
18:30 <TemptorSent> Which doesn't work for reading streams.
18:32 blueness joined
18:32 <TemptorSent> But I guess if we're going to crash anyway, we probably don't care if we read more than we actually processed from the stream.
18:33 <TemptorSent> Although that could break certain corner cases.
18:33 <dalias> read() writes data to memory
18:33 <dalias> the overread from the stream is rather irrelevant
18:33 <dalias> it's the overwrite to memory that could give an attacker a way in
18:34 <dalias> even if you would catch it later after the syscall returns
18:34 <uriah> hmm...
18:34 <TemptorSent> True, but the overread will leave the stream at an unexpected point, so the next reader may get unexpected input.
18:34 <dalias> temptorsent, that happens anyway if you called a non-checking read()
18:35 <dalias> it's UB anyway
18:35 <dalias> one of the manifestations of UB is leaving files seeked to the wrong position
18:35 <TemptorSent> Yeah, it should probably either reset or close the fd, not sure if a_crash does that...
18:35 <dalias> we're just trying to reduce or eliminate the scope of manifestations that an attacker can easily exploit
18:35 <dalias> no, it shouldn't
18:36 <dalias> doing anything else after UB is detected increases the likelihood that an attacker can gain control
18:36 <dalias> you just need the process to die asap
18:36 <dalias> making syscalls is not even safe
18:37 <TemptorSent> Hmm, something should clean up stale fds and other open resources or it will zombie.
18:37 <dalias> when a process dies all of its files are closed
18:37 <TemptorSent> I haven't looked at how a_crash actually crashes.
18:37 <dalias> it executes a faulting or illegal instruction
18:38 <dalias> ideally it would raise SIGKILL
18:38 <TemptorSent> Okay, that should break a blocked io I guess, unlike sigkill.
18:38 <dalias> but that requires making a syscall that's more work to do securely
18:39 <dalias> and something trappable is more nice if you want to run it under a debugger
18:39 <TemptorSent> The kernel will kick it out on illegal instruction.
18:39 <dalias> the kernel will raise SIGSEGV or SIGILL
18:39 <dalias> SIGILL is preferable because it's less likely the program traps it
18:39 <TemptorSent> Yeah, but it also will zombie if the kernel doesn't kick it with a blocked open resource, or at least it did.
18:40 <dalias> if the process has threads in a D state that's not something you can fix
18:40 <dalias> zombie is the wrong word
18:40 <dalias> it has a specific meaning that's completely different
18:40 <dalias> D state is a kernel bug
18:40 <TemptorSent> zombies are processes that can't close but aren't scheduled last I checked.
18:40 <dalias> no
18:41 <dalias> zombies are process ids from processes whose parents have not yet waited on them
18:41 <dalias> they carry with them some minimal accounting data that's waiting for the parent to see it
18:41 <dalias> normally they only exist momentarily
18:41 <dalias> but some buggy programs make child processes and don't wait on them
18:42 <dalias> and then the zombie hangs around
18:42 <TemptorSent> Right, what happens when we crash? Any child processes end up Z
18:42 <dalias> eventually if the parent dies the zombie will be reparented to pid 1 (init) and init will wait on it
18:42 <dalias> no
18:42 <dalias> if a process's parent dies it gets reparented to init
18:42 <dalias> and init waits on all children that exit
18:43 <TemptorSent> Okay, so a_crash is seen as legitimate exit point and is handled like a termination and avoids that, good!
18:43 <dalias> all it does is cause the process to crash the same way it would if the cpu caught it doing UB
18:44 <dalias> like dereferencing a null pointer
18:44 <TemptorSent> Things have improved a bit since I was messing with the libc/kernel guts back in the late '90s
18:44 <* uriah> feels like TemptorSent is finding a renewed calling :)
18:45 <TemptorSent> *lol* uriah -- yeah, I need a few things to work :)
18:45 <uriah> :>
18:46 <uriah> does anyone here know how long sprunge.us keeps pastes hosted for?
18:46 <dalias> uriah, seemingly forever :-p
18:46 <uriah> nice
18:47 <dalias> i think they have some heuristic where huge ones, or ones from clients that send abusively many, get purged quickly
18:47 <dalias> but everything else just sticks around
18:47 <uriah> ok that's surprising though
18:47 <dalias> i don't know exactly how it works
18:47 <uriah> cause they only have a certain amount of addresses possible, right?
18:47 <dalias> the sw is all open source tho
18:47 <dalias> i don't think they reuse addresses at all
18:47 <TemptorSent> Does a_crash itself provide anything to help unwind the call stack for the debugger?
18:47 <dalias> the number of addresses should be unlimited
18:48 <dalias> temptorsent, no, the compiler already does that
18:49 <TemptorSent> Okay, so no additional state about the crash is stored. How well does that work out with stripped binaries?
18:49 <TemptorSent> I haven't gotten into fortify far enough to see how they're doing things internally.
18:51 <TemptorSent> Obviously they build a little black-magick in to the code-generation...
18:52 <TemptorSent> I guess delving into that is on my todo list, since I need it for an upcoming project anyway.
18:53 <uriah> kaniini: how often do the channel logs rotate / get pushed to the web? i'm going to be rebooting before resuming work on this stuff, and am running in a live environment
18:53 <uriah> would be good to reference myself from the things discussed here
18:56 <uriah> seems to be live - good :)
18:56 <TemptorSent> uriah: The appear to be long-lived and updated nearly real time.
18:56 <uriah> nice
19:01 <* uriah> wishes he had more than a stack of blank dvd's to back things up on externally before rebooting
19:01 <uriah> the dvd burner i have is uh... slightly malfunctioning
19:03 <uriah> anyway, i'll use the burner
19:14 s4nni joined
19:16 <uriah> ok, bbl
19:16 <uriah> shutting down, and will grab a bite to eat
19:16 tmh1999 joined
19:26 minimalism joined
19:33 ostera joined
19:40 grayhemp joined
19:44 grayhemp joined
19:55 ostera joined
19:56 uriah joined
19:57 <uriah> ahh... replenished.
19:58 <uriah> nothing like living in a country where tim horton's is just down the street
20:02 ostera joined
20:14 <uriah> kaniini: is it normal for the execution of `./path/to/ld-musl-x86_64.so.1 /path/to/test/bin` to segfault with a grsec catch shown in dmesg out-of-the-box in alpine, or would that be due to errors in my code making a bad request?
20:15 <uriah> (i suspect the latter)
20:15 <uriah> it's one of those RLIMIT_CORE catches
20:17 tmh1999 joined
20:21 <uriah> anyway... wrt to me changing my patch, does one of you have time to specify where UB would be a problem wrt calling the function before checking please? i understand now how it's a sticky situation, considering the conditional can't really be split, because the second condition needs to be matched for the first condition not to have false positives
20:21 Skele joined
20:21 <uriah> iirc, it's not the case everywhere
20:21 <uriah> oops iiuc*
20:22 grayhemp joined
20:25 ostera joined
20:29 Dentych joined
20:29 Dentych joined
20:33 ostera joined
20:41 ostera joined
20:58 rollniak joined
21:04 pidzero joined
21:18 ogres joined
21:21 grayhemp joined
21:23 ostera joined
21:24 stwa joined
21:32 ostera joined
21:38 dlaube joined
21:41 ostera joined
21:47 blueness joined
21:50 ostera joined
21:51 grayhemp joined
21:51 alacerda joined
21:54 <darkfader> hmm, any ideas about when we get the last xen security patch?
21:55 <uriah> :)
21:59 ostera joined
22:13 ostera joined
22:14 gopar joined
22:16 fekepp joined
22:32 gopar joined
22:33 gopar joined
23:08 gopar joined
23:17 ostera joined
23:33 syntrx joined
23:34 gopar joined
23:46 ostera joined
23:48 <minimalism> Can any of Alpine's ISOs boot in UEFI mode during installation?