Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #111404

Re: Constant Stack Canaries

Show all headers | View raw

On 2025-04-01 5:21 p.m., BGB wrote:
> On 3/31/2025 11:58 PM, Robert Finch wrote:
>> On 2025-03-31 4:52 p.m., MitchAlsup1 wrote:
>>> On Mon, 31 Mar 2025 18:56:32 +0000, BGB wrote:
>>>
>>>> On 3/31/2025 1:07 PM, MitchAlsup1 wrote:
>>> -------------
>>>>>> Another option being if it could be a feature of a Load/Store 
>>>>>> Multiple.
>>>>>>
>>>>>> Say, LDM/STM:
>>>>>>    6b Hi (Upper bound of register to save)
>>>>>>    6b Lo (Lower bound of registers to save)
>>>>>>    1b LR (Flag to save Link Register)
>>>>>>    1b GP (Flag to save Global Pointer)
>>>>>>    1b SK (Flag to generate a canary)
>>
>> Q+3 uses a bitmap of register selection with four more bits selecting 
>> overlapping groups. It can work with up to 17 registers.
>>
> 
> OK.
> 
> If I did LDM/STM style ops, not sure which strategy I would take.
> 
> The possibility of using a 96-bit encoding with an Imm64 holding a bit- 
> mask of all the registers makes some sense...
> 
> 
>>>>>
>>>>> ENTER and EXIT have 2 of those flags--but also note use of SP and CSP
>>>>> are implicit.
>>>>>
>>>>>> Likely (STM):
>>>>>>    Pushes LR first (if bit set);
>>>>>>    Pushes GP second (if bit set);
>>>>>>    Pushes registers in range (if Hi>=Lo);
>>>>>>    Pushes stack canary (if bit set).
>>>>>
>>>>> EXIT uses its 3rd flag used when doing longjump() and THROW()
>>>>> so as to pop the call-stack but not actually RET from the stack
>>>>> walker.
>>>>>
>>>>
>>>> OK.
>>>>
>>>> I guess one could debate whether an LDM could treat the Load-LR as 
>>>> "Load
>>>> LR" or "Load address and Branch", and/or have separate flags (Load 
>>>> LR vs
>>>> Load PC, with Load PC meaning to branch).
>>>>
>>>>
>>>> Other ABIs may not have as much reason to save/restore the Global
>>>> Pointer all the time. But, in my case, it is being used as the primary
>>>> way of accessing globals, and each binary image has its own address
>>>> range here.
>>>
>>> I use constants to access globals.
>>> These comes in 32-bit and 64-bit flavors.
>>>
>>>> PC-Rel not being used as PC-Rel doesn't allow for multiple process
>>>> instances of a given loaded binary within a shared address space.
>>>
>>> As long as the relative distance is the same, it does.
>>>
>>>> Vs, say, for PIE ELF binaries where it is needed to load a new copy for
>>>> each process instance because of this (well, excluding an FDPIC style
>>>> ABI, but seemingly still no one seems to have bothered adding FDPIC
>>>> support in GCC or friends for RV64 based targets, ...).
>>>>
>>>> Well, granted, because Linux and similar tend to load every new process
>>>> into its own address space and/or use CoW.
>>>
>>> CoW and execl()
>>>
>>> --------------
>>>>>> Other ISAs use a flag bit for each register, but this is less viable
>>>>>> with an ISA with a larger number of registers, well, unless one 
>>>>>> uses a
>>>>>> 64 or 96 bit LDM/STM encoding (possible). Merit though would be not
>>>>>> needing multiple LDM's / STM's to deal with a discontinuous register
>>>>>> range.
>>>>>
>>>>> To quote Trevor Smith:: "Why would anyone want to do that" ??
>>>>>
>>>>
>>>> Discontinuous register ranges:
>>>> Because pretty much no ABI's put all of the callee save registers in a
>>>> contiguous range.
>>>>
>>>> Granted, I guess if someone were designing an ISA and ABI clean, they
>>>> could make all of the argument registers and callee save registers
>>>> contiguous.
>>>>
>>>> Say:
>>>>    R0..R3: Special
>>>>    R4..R15: Scratch
>>>>    R16..R31: Argument
>>>>    R32..R63: Callee Save
>>>> ....
>>>>
>>>> But, invariably, someone will want "compressed" instructions with a
>>>> subset of the registers, and one can't just have these only having
>>>> access to argument registers.
>>>
>>> Brian had little trouble using My 66000 ABI which does have contiguous
>>> register groupings.
>>>
>>>>>> Well, also excluding the possibility where the LDM/STM is essentially
>>>>>> just a function call (say, if beyond certain number of registers 
>>>>>> are to
>>>>>> be saved/restored, the compiler generates a call to a save/restore
>>>>>> sequence, which is also generates as-needed). Granted, this is 
>>>>>> basically
>>>>>> the strategy used by BGBCC. If multiple functions happen to save/ 
>>>>>> restore
>>>>>> the same combination of registers, they get to reuse the prior
>>>>>> function's save/restore sequence (generally folded off to before the
>>>>>> function in question).
>>>>>
>>>>> Calling a subroutine to perform epilogues is adding to the number of
>>>>> branches a program executes. Having an instruction like EXIT means
>>>>> when you know you need to exit, you EXIT you don't branch to the exit
>>>>> point. Saving instructions.
>>>>>
>>>>
>>>> Prolog needs a call, but epilog can just be a branch, since no need to
>>>> return back into the function that is returning.
>>>
>>> Yes, but this means My 66000 executes 3 fewer transfers of control
>>> per subroutine than you do. And taken branches add latency.
>>>
>>>> Needs to have a lower limit though, as it is not worth it to use a
>>>> call/branch to save/restore 3 or 4 registers...
>>>>
>>>> But, say, 20 registers, it is more worthwhile.
>>>
>>> ENTER saves as few as 1 or as many as 32 and remains that 1 single
>>> instruction. Same for EXIT and exit also performs the RET when LDing
>>> R0.
>>>
>>>>
>>>>>> Granted, the folding strategy can still do canary values, but 
>>>>>> doing so
>>>>>> in the reused portions would limit the range of unique canary values
>>>>>> (well, unless the canary magic is XOR'ed with SP or something...).
>>>>>>
>>> Canary values are in addition to ENTER and EXIT not part of them
>>> IMHO.
>>
>> In Q+3 there are push and pop multiple instructions. I did not want to 
>> add load and store multiple on top of that. They work great for ISRs, 
>> but not so great for task switching code. I have the instructions 
>> pushing or popping up to 17 registers in a group. Groups of registers 
>> overlap by eight. The instructions can handle all 96 registers in the 
>> machine. ENTER and EXIT are also present.
>>
>> It is looking like the context switch code for the OS will take about 
>> 3000 clock cycles to run. Not wanting to disable interrupts for that 
>> long, I put a spinlock on the system’s task control block array. But I 
>> think I have run into an issue. It is the timer ISR that switches 
>> tasks. Since it is an ISR it pushes a subset of registers that it uses 
>> and restores them at exit. But when exiting and switching tasks it 
>> spinlocks on the task control block array. I am not sure this is a 
>> good thing. As the timer IRQ is fairly high priority. If something 
>> else locked the TCB array it would deadlock. I guess the context 
>> switching could be deferred until the app requests some other 
>> operating system function. But then the issue is what if the app gets 
>> stuck in an infinite loop, not calling the OS? I suppose I could make 
>> an OS heartbeat function call a requirement of apps. If the app does 
>> not do a heartbeat within a reasonable time, it could be terminated.
>>
>> Q+3 progresses rapidly. A lot of the stuff in earlier versions was 
>> removed. The pared down version is a 32-bit machine. Expecting some 
>> headaches because of the use of condition registers and branch registers.
>>
> 
> OK.
> 
> Ironically, I seem to have comparably low task-switch cost...
> However, each system call is essentially 2 task switches, and it is 
> still slow enough to negatively effect performance if they happen at all 
> frequently.
> 
System calls for Q+ are slightly faster (but not much) than task 
switches. I just have the system saving state on the stack. I don't 
bother saving the FP registers or some of the other system registers 
that the OS controls. So, it is a little bit shorter than the task 
switch code.

The only thing that can do a task switch in the system is the time-slicer.

> So, say, one needs to try to minimize the number of unnecessary system 
> calls (say, don't implement "fputs()" by sending 1 byte at a time, ...).
> 
> 
> 
> 
> 
> Unlike on a modern PC, one generally needs to care more about efficiency.
> 
> Hence, all the fiddling with low bit-depth graphics formats, and things 
> like my recent fiddling with 2-bit ADPCM audio.
> 
> And, online, one is (if anything) more likely to find people complaining 
> about how old/obsolescent ADPCM is (and/or arguing that people should 
> store all their sound effects as Ogg/Vorbis or similar; ...).
> 
> 
Im not one much for music, although I play the tunes ocassionally. I'm 
little hard of hearing.
> 
> Then again, I did note that I may need to find some other "quality 
> metric" for audio, as RMSE isn't really working...
> 
> At least going by RMSE, the "best" option would be to use 8-bit PCM and 
> then downsample it.
> 
> Say, 4kHz 8-bit PCM has a lower RMSE score than 2-bit ADPCM, but 
> subjectively the 2-bit ADPCM sounds significantly better.
> 
> Say: for 16kHz, and a test file (using a song here):
>    PCM8, 16kHz     : 121 (128 kbps)
>    A-Law, 16kHz    : 284 (128 kbps)
>    IMA 4bit, 16kHz : 617 (64 kbps)
>    IMA 2bit, 16kHz : 1692 (32 kbps, *)
>    ADLQ 2bit, 16kHz: 2000 (32 kbps)
>    PCM8, 4kHz      : 242  (32 kbps)
> 
> However, 4kHz PCM8 sounds terrible vs either 2-bit IMA or ADLQ.
>    Basically sounds muffled, speech is unintelligible.
>    But, it would be the "best" option if going solely by RMSE.
> 
> Also A-Law sounds better than PCM8 (at the same sample rate).
>    Even with the higher RMSE score.
> 
> Seems like it could be possible to do RMSE on A-Law samples as a metric, 
> but if anything this is just kicking the can down the road slightly.
> 
> Granted, A-Law sounds better than 4-bit IMA, and 4-bit IMA sounds better 
> than the 2-bit ADPCM's at least...
> 
> 
> *: Previously it was worse, around 4500, but the RMSE score dropped 
> after switching it to using a similar encoder strategy to ADLQ, namely 
> doing a brute-force search over the next 3 samples to find the values 
> that best approximate the target samples.
> 
> Though, which is "better", or whether or not even lower RMSE "improves" 
> quality here, is debatable (the PCM8 numbers clearly throw using RMSE as 
> a quality metric into question for this case).
> 
> Ideally I would want some metric that better reflects hearing perception 
> and is computationally cheap.
> 
> ...
> 

Back to comp.arch | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Constant Stack Canaries Robert Finch <robfi680@gmail.com> - 2025-03-30 08:16 -0400
  Re: Constant Stack Canaries BGB <cr88192@gmail.com> - 2025-03-30 12:47 -0500
    Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-03-30 20:14 +0000
      Re: Constant Stack Canaries Robert Finch <robfi680@gmail.com> - 2025-03-30 21:26 -0400
      Re: Constant Stack Canaries BGB <cr88192@gmail.com> - 2025-03-31 01:34 -0500
      Re: Constant Stack Canaries Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-03-31 09:04 -0700
        Re: Constant Stack Canaries BGB <cr88192@gmail.com> - 2025-03-31 12:17 -0500
          Re: Constant Stack Canaries Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-03-31 10:57 -0700
          Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-03-31 18:07 +0000
            Re: Constant Stack Canaries BGB <cr88192@gmail.com> - 2025-03-31 13:56 -0500
              Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-03-31 20:52 +0000
                Re: Constant Stack Canaries Robert Finch <robfi680@gmail.com> - 2025-04-01 00:58 -0400
                Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-04-01 18:51 +0000
                Re: Constant Stack Canaries Robert Finch <robfi680@gmail.com> - 2025-04-01 18:06 -0400
                Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-04-01 23:24 +0000
                Re: Constant Stack Canaries Robert Finch <robfi680@gmail.com> - 2025-04-01 20:07 -0400
                Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-04-02 01:47 +0000
                Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-04-04 21:07 +0000
                Re: Constant Stack Canaries BGB <cr88192@gmail.com> - 2025-04-01 16:21 -0500
                Re: Constant Stack Canaries Robert Finch <robfi680@gmail.com> - 2025-04-01 18:19 -0400
                Re: Constant Stack Canaries BGB <cr88192@gmail.com> - 2025-04-01 23:04 -0500
                Re: Constant Stack Canaries BGB <cr88192@gmail.com> - 2025-04-01 14:34 -0500
                Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-04-01 23:21 +0000
                Re: Constant Stack Canaries Stefan Monnier <monnier@iro.umontreal.ca> - 2025-04-01 22:55 -0400
                Re: Constant Stack Canaries BGB <cr88192@gmail.com> - 2025-04-01 23:19 -0500
                Re: Constant Stack Canaries Stefan Monnier <monnier@iro.umontreal.ca> - 2025-04-03 10:09 -0400
                Re: Constant Stack Canaries BGB <cr88192@gmail.com> - 2025-04-03 12:22 -0500
                Re: Constant Stack Canaries Robert Finch <robfi680@gmail.com> - 2025-04-03 23:49 -0400
                Re: Constant Stack Canaries BGB <cr88192@gmail.com> - 2025-04-04 12:41 -0500
                Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-04-04 21:13 +0000
                Re: Constant Stack Canaries Robert Finch <robfi680@gmail.com> - 2025-04-04 23:45 -0400
                Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-04-05 16:37 +0000
                Re: Constant Stack Canaries scott@slp53.sl.home (Scott Lurndal) - 2025-04-05 18:31 +0000
                Re: Constant Stack Canaries Robert Finch <robfi680@gmail.com> - 2025-04-05 17:57 -0400
                Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-04-05 23:11 +0000
                Re: Constant Stack Canaries scott@slp53.sl.home (Scott Lurndal) - 2025-04-06 14:21 +0000
                Re: Constant Stack Canaries Robert Finch <robfi680@gmail.com> - 2025-04-06 15:01 -0400
                Re: Constant Stack Canaries scott@slp53.sl.home (Scott Lurndal) - 2025-04-07 14:04 +0000
                Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-04-05 23:06 +0000
                Re: Constant Stack Canaries scott@slp53.sl.home (Scott Lurndal) - 2025-04-06 14:32 +0000
                Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-04-07 00:51 +0000
                Re: Constant Stack Canaries scott@slp53.sl.home (Scott Lurndal) - 2025-04-07 14:09 +0000
                Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-04-09 00:23 +0000
                Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-04-15 00:43 +0000
                Re: Constant Stack Canaries scott@slp53.sl.home (Scott Lurndal) - 2025-04-15 14:02 +0000
                Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-04-15 20:46 +0000
                Re: Constant Stack Canaries scott@slp53.sl.home (Scott Lurndal) - 2025-04-16 14:07 +0000
                Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-04-16 21:13 +0000
                Virtualization layers (was: Constant Stack Canaries) Stefan Monnier <monnier@iro.umontreal.ca> - 2025-04-16 17:48 -0400
                Re: Virtualization layers mitchalsup@aol.com (MitchAlsup1) - 2025-04-16 22:12 +0000
                Re: Virtualization layers (was: Constant Stack Canaries) scott@slp53.sl.home (Scott Lurndal) - 2025-04-17 00:49 +0000
                Re: Constant Stack Canaries Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-04-16 15:26 -0700
                Re: Constant Stack Canaries scott@slp53.sl.home (Scott Lurndal) - 2025-04-17 00:57 +0000
                Re: virtualization, Constant Stack Canaries John Levine <johnl@taugh.com> - 2025-04-17 01:04 +0000
                Re: virtualization, Constant Stack Canaries Stefan Monnier <monnier@iro.umontreal.ca> - 2025-04-16 21:07 -0400
                Re: virtualization, Constant Stack Canaries Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-04-16 23:30 -0700
                Re: virtualization, Constant Stack Canaries scott@slp53.sl.home (Scott Lurndal) - 2025-04-17 13:32 +0000
                Re: virtualization, Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-04-17 18:22 +0000
                Re: virtualization, Constant Stack Canaries scott@slp53.sl.home (Scott Lurndal) - 2025-04-17 20:10 +0000
                Re: virtualization, Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-04-17 21:45 +0000
                Re: Constant Stack Canaries scott@slp53.sl.home (Scott Lurndal) - 2025-04-17 00:47 +0000
                Re: Constant Stack Canaries BGB <cr88192@gmail.com> - 2025-04-02 00:43 -0500

csiph-web