senozhatsky

That's sort of how Linux kernel trace-events are implemented [1]. E.g.

    DECLARE_EVENT_CLASS(sched_wakeup_template,
    
     TP_PROTO(struct task_struct *p),
    
     TP_ARGS(__perf_task(p)),
    
     TP_STRUCT__entry(
          __array( char, comm, TASK_COMM_LEN )
          __field( pid_t, pid   )
          __field( int, prio   )
          __field( int, target_cpu  )
     ),
    
     TP_fast_assign(
          memcpy(__entry->comm, p->comm, TASK_COMM_LEN);
          __entry->pid  = p->pid;
          __entry->prio  = p->prio; /* XXX SCHED_DEADLINE */
          __entry->target_cpu = task_cpu(p);
     ),
    
     TP_printk("comm=%s pid=%d prio=%d target_cpu=%03d",
          __entry->comm, __entry->pid, __entry->prio,
          __entry->target_cpu)
    );

[1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds...

I wish they offered a paid version of the browser that would have ublock enabled.

> meaning no local variables (still heavy usage of push/pop within a procedure, does this count as a local?)

Isn't it (push/pop) how locals basically work?

Knuth's MIX computer with its 6-bit bytes and 5-byte words (IIRC) came to my mind [0]

[0] https://en.wikipedia.org/wiki/MIX

OK, understood. So what you meant was more like

   puts()'s attack surface is smaller than printf()'s.

This is not how your message appeared to me - "printf() is vulnerable to injections, use puts() instead". Both are vulnerable to "unintended read()-s".

Looks even better!

Good point. I suppose that you are talking about overwriting terminating NUL, do I get it right? puts() is vulnurable in exactly same way.

> No. You don't really want to do that. If you're doing that, use puts

This is not the case for RO strings, is it?

I see. So when for a char pointer one needs to do

        printf("%p\n", v);

the Generic call must look like this

        displayln((const void *)v);

is it really better?

Could be. But wouldn't then displayln() require the same string placeholder? Be it "%s", or "{1}" or someting else.

   > printf("%s\n", "Hello, World!");
   >
   > That's an awful lot of symbolic syntax.

Well... Because it should have been

    printf("Hello, World!\n");

in the first place?

One can do something like

    printf("%s,%s%c\n", "Hello", "World", '!');

and claim that C is awful and that

    displayln("Hello, World!");

is so much better.

I think Hyundai/Kia had self driving systems in development for the past, what, 5 years? Kia debuted its DriveWise in 2016. So they don't start from scratch.

I pretend that '-s' stands for "source", not "symbolic"; and source file follows -s(ource) option. IOW `ln -s A B' is `link source A to B'.

Somehow reminds me of this conversation [0]:

  > Al Viro asked if there is a plan to allow mounting hand-crafted XFS or ext4
  > filesystem images. That is an easy way for an attacker to run their own code
  > in ring 0, he said. The filesystems are not written to expect that kind of
  > (ab)use. When asked if it really was that easy to crash the kernel with a
  > hand-crafted filesystem image, Viro said: "is water wet?" 

[0] https://lwn.net/Articles/718639/

From the article - "No other agent had served Moscow for so well or so long."

That's very questionable. No one knows who the greatest spy was/is.

Yeah. OOM-kill handling wants to be a silver bullet, sort of. For instance, Linux kernel provides a number of I/O schedulers or net schedulers, etc. to pick from, but OOM kill is "one size fits all". And it doesn't really look like things are going to change [1][2][3].

[1] https://lore.kernel.org/lkml/alpine.DEB.2.21.1810221406400.1...

[2] https://lore.kernel.org/lkml/20181024155454.4e63191fbfaa0441...

[3] https://lore.kernel.org/lkml/20181023055655.GM18839@dhcp22.s...

lkml.org has been unstable for the past few... umm years, so The Linux Foundation runs its own lkml archive - lore.kernel.org/lkml/

Alternative link, just in case: https://lore.kernel.org/lkml/d9802b6a-949b-b327-c4a6-3dbca48...

Maybe. But I can count something like 6 or 7 buildings on that pic which look glassy to me. I'd say there are several glassy (which reflect sky and water) buildings there [1][2].

[1] https://www.shutterstock.com/video/clip-7263112-panning-time...

[2] https://www.shutterstock.com/video/clip-27791884-victoria-ha...

Edit: added more links.

I like glassy buildings. Can stare at them for minutes; the article makes little sense to me. E.g. Hong Kong Harbour skyline, which is quite "glassy". Many people travel to take a look at it.

[1] https://www.tripsavvy.com/thmb/SPLQhcPHF_u06LNEFd1qIc4p_3Q=/...

Slightly off topic. Can't help it, but the motif for pain (introduced @ 9:37) sounds to me like, I don't know, Windows (?) error/warning sound. Is it just me?

> There is one thing I can't understand from the article: it says a low birth rate as a reason of an increase in migration. Why would a low birth rate lead to more migration?

Good question. My understanding is that (from the article)

    The low birthrate is leading to severe labor shortages ... prompting the
    country to welcome more foreign workers.

So foreign workers (e.g. from South-East Asia?) make it harder for Koreans to find a job in SK? But it's all the same (severe labor shortages) in Japan, if not worse.

A very cool domain name, by the way.

> That is indeed very surprising. I think the fact that Go isn't dead-slow can be attributed mainly to the sheer speed of CPUs.

Well, I suspect that in any reasonably complex C/C++ application (e.g. firefox) compilers do pass params via stack and probably they do so rather often. Even on x86_64.

/usr/lib/firefox/firefox objdump:

        a8b8:       48 83 ec 40             sub    $0x40,%rsp
        a8bc:       48 89 d3                mov    %rdx,%rbx
        a8bf:       48 89 f5                mov    %rsi,%rbp
        a8c2:       49 89 ff                mov    %rdi,%r15
        a8c5:       64 48 8b 04 25 28 00    mov    %fs:0x28,%rax
        a8cc:       00 00 
        a8ce:       48 89 44 24 38          mov    %rax,0x38(%rsp)
        a8d3:       44 8b 76 10             mov    0x10(%rsi),%r14d
        a8d7:       44 8b 62 10             mov    0x10(%rdx),%r12d
        a8db:       48 89 74 24 20          mov    %rsi,0x20(%rsp)
        a8e0:       48 89 54 24 28          mov    %rdx,0x28(%rsp)
        a8e5:       c7 44 24 30 02 00 00    movl   $0x2,0x30(%rsp)
        a8ec:       00 
        a8ed:       48 8d 7c 24 20          lea    0x20(%rsp),%rdi
        a8f2:       e8 39 fd ff ff          callq  a630 <_ZN7mozilla11Compression3LZ417decompressPartialEPKcmPcmPm@@Base+0x2c0>
    --
      etc.

/usr/lib/firefox/libxul.so objdump:

      81cf5e:       48 89 44 24 30          mov    %rax,0x30(%rsp)
      81cf63:       4c 89 7c 24 58          mov    %r15,0x58(%rsp)
      81cf68:       4d 89 cf                mov    %r9,%r15
      81cf6b:       f2 44 0f 11 64 24 60    movsd  %xmm12,0x60(%rsp)
      81cf72:       e8 a9 00 00 00          callq  81d020 <mont_mulf_noconv@@xul66+0xa30>
    --
      etc.

> This is very surprising for a language that targets somewhat high performance.

> Looks like it's a 5-10% performance hit, but makes it easier to provide good backtrace information

Very interesting indeed.

Well, forcing your compiler to start passing parameters via stack is pretty simple and it's not so uncommon.

And probably (and maybe) the Go team just wanted to make things simple. Otherwise they would need to have two parameter passing implementations and sometimes even use a mixed one - when platform does not have enough registers (e.g. 6 CPU registers and a function which takes 6+ params), so some parameters would be passed via registers, some via stack; or maybe all of them via stack. And so on. So I am byuing the "good backtrace" point.

For example, suppose I have a silly logging function my_func() [C code], which takes 8 params:

    __attribute__ ((noinline)) 
    void my_func(const char *module, const char *func, const char *level,
                 int line, int B, int C,
                 const char *app, const char *session)
    {
        printf("%s:%s:%s:%d %d %s %s\n", module, func, level,
               line, B + C, app, session);
    }

    int main()
    {
        my_func("core", __func__, "error", 1, 2, 3, "a.out", "dummy");
        return 0;
    }

Let's compile it with gcc (-O2) for ARM and let's take a look at what main() does:

    000103d8 <main>:
       103d8: e52de004  push {lr}  ; (str lr, [sp, #-4]!)
       103dc: e3002630  movw r2, #1584 ; 0x630
       103e0: e3402001  movt r2, #1
       103e4: e24dd014  sub sp, sp, #20
       103e8: e3003638  movw r3, #1592 ; 0x638
       103ec: e3403001  movt r3, #1
       103f0: e3001600  movw r1, #1536 ; 0x600
       103f4: e3401001  movt r1, #1
       103f8: e58d200c  str r2, [sp, #12]
       103fc: e3000628  movw r0, #1576 ; 0x628
       10400: e3400001  movt r0, #1
       10404: e58d3008  str r3, [sp, #8]
       10408: e3a02003  mov r2, #3
       1040c: e3a03002  mov r3, #2
       10410: e58d2004  str r2, [sp, #4]
       10414: e58d3000  str r3, [sp]
       10418: e3002620  movw r2, #1568 ; 0x620
       1041c: e3402001  movt r2, #1
       10420: e3a03001  mov r3, #1
       10424: eb00004c  bl 1055c <my_func>
       10428: e3a00000  mov r0, #0
       1042c: e28dd014  add sp, sp, #20
       10430: e49df004  pop {pc}  ; (ldr pc, [sp], #4)

Looks like a bunch of stores to stack ptr: + 0 bytes; + 4 bytes; + 8 bytes; + 12 bytes.

[Edit: should have passed __LINE__ instead of hardcoded 1, but that doesn't change the assembly.]

That "WE MADE HISTORY" at the end definitely should be "WE REPEATED HISTORY".

Indeed. I also recall a number of pretty cool Max Payne Matrix mods.

I had a similar thought - profile guided optimizations (PGO).

> That's not `\n`. That's how acme displays long lines.

Oh, yes, sure. I just didn't know how to show the line break, so just "embedded" \n-s. I realize that there are no \n-s there.

Pretty interesting, that mail utility didn't bother to wrap the words correctly. Notice

    .. BSD and o\nther ..
    .. persons i\nn ..
    .. give a\nn ..

and so on.

My assumption was that those security "challenges" were related to expansion (wordexp()) per se; not to the way wordexp() was implemented in this particular case.