Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Newsgroups | comp.arch |
| Subject | Re: Constant Stack Canaries |
| Date | 2025-04-01 23:04 -0500 |
| Organization | A noiseless patient Spider |
| Message-ID | <vsid3u$sput$1@dont-email.me> (permalink) |
| References | (6 earlier) <vseojq$112f7$1@dont-email.me> <62b5c4a25d917c5bab64a815189de826@www.novabbs.org> <vsfrqk$28q7o$1@dont-email.me> <vshlfk$32p7$1@dont-email.me> <vshoop$3sqf$2@dont-email.me> |
On 4/1/2025 5:19 PM, Robert Finch wrote:
> 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.
>
In my case, task switch happens by capturing and restoring all of the
registers (of which there are 64 main registers, and a few CR's).
No separate FPU or vector registers (the BJX GPR space, and RISC-V X+F
spaces, being mostly equivalent).
The interrupt handlers only have access to physical addresses, and will
block all other interrupts when running, so there is a need to get
quickly from the user-program task to the syscall handler task, and then
back again once done (though, maybe not immediately, as it may instead
send the results back to the caller task, and then transfer control to a
different task).
Timer interrupt can do scheduling, but mostly avoids doing so unless
there is no other option (TestKern being mostly lacking in mutexes,
which makes timer-driven preemptive multitasking a bit risky). However,
usually programs will use system calls often enough that it is possible
to schedule tasks this way, and generally a system call will not be made
inside of a critical section.
>> 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.
Not so much for music here, but more for storing sound-effects.
I can note I seem to have a form of reverse-slope hearing impairment...
Not a new thing, I have either always been this way, or it has happened
very slowly.
I can seemingly hear most stuff OK though.
Except, IRL, I can't hear tuning forks.
Nor car engines.
I don't hear the engines.
I do hear the tires rolling on the ground.
Nor refrigerators (mostly).
I sometimes hear the relays when they start/stop,
or a crackling sound from the radiator coil.
Using phones sucks hard, can't hear crap...
Not terribly musically inclined.
But, instruments don't sound much different from "noise" sounds.
My ability to hear low-frequencies is a bit weird:
Square or triangle waves, I hear these well;
Sine waves, weakly, but I hear them in headphones if volume is high.
If the volume isn't very high, sine waves become silent.
Seemingly, these are harder to hear IRL.
I seem most sensitive to frequencies between around 2 to 8 kHz. Upper
end of hearing seems to be around 17 kHz (lower end around 1kHz for pure
sine waves). The lower ("absolute" limit seems to be around 8Hz, but
more because at this point, a square wave turns from a "tone" into a
series of discrete pops, 8-20 Hz being sort of a meta-range between
being tonal and discrete pops).
Have noted that in YouTube videos where someone is messing with a CRT
TV, I can still sometimes hear the squeal, particularly if the camera is
close to the TV. Not seen a CRT IRL in a while though; no obvious sound
from a VGA CRT monitor though (but, then again, I am using it ATM on an
old rack server, which sounds kinda like a vacuum cleaner, so might be
masking it if it is making a noise).
Have noted that I still understand speech fine with a 2-8 kHz bandpass
(with steep fall-off). I don't understand speech at all with a 2kHz
low-pass. So, whichever parts I use for intelligibility seem to be
between 2 and 8kHz. Had noted if I split it into 2-4 or 4-8 kHz bands,
either works, though individually each has a notably worse quality than
combined 2-8 kHz.
The 1-2 kHz range can be heard, but doesn't seem to contain much as far
as intelligibility goes, but its presence or absence does seem to alter
vowel sounds slightly.
A 1-8 kHz bandpass sounds mostly natural to me. Though, cats seem to
respond unfavorably to band-passed audio (if cats are neutral to the
original, but tense up and dig in their claws if I play band-passed
audio, it seems they hear a difference).
Although, I was using music as test-cases mostly as they can give a
better idea of the relative audio quality than a short sound effect.
But, for things that are going to be embedded into an EXE or DLL,
generally these are ideally kept at a few kB or less.
For long form audio, there is more reason to care about audio quality,
but for something like a notification ding, not as much. Do preferably
want it to not sound like "broken crap" though. And, if any speech is
present, ideally it needs to be intelligible.
In terms of being small and "not sounding like crap":
ADPCM:
Works well enough, but can't go below 2 bits per sample.
Delta-Signma:
1 bit per sample, but sounds horrid much under 64 kHz.
MP3 and Vorbis work well at 96 to 128 kbps, but:
Are complex and expensive formats to decode;
Don't give acceptable results much below around 40 kbps.
At lower bitrates, the artifacts from MP3 and Vorbis can become rather
obnoxious (lots of squealing and whistling and sounds like broken glass
being shaken in a steel can).
I actually much prefer the sound of ADPCM for low bitrates. Muffled and
gritty is still preferable to "rattling a steel can full of broken
glass" (simple loss of quality rather than the addition of other more
obnoxious artifacts).
From what I gather, the telephone network used 8kHz as a standard
sampling rate, with one of several formats:
u-Law, in the US
A-Law, in Europe
4-bit ADPCM, for lower-priority long-distance links;
When not using u-Law or A-Law.
2-bit ADPCM, for "overflow" links (*).
*: Apparently, if there were too many long distance calls over a given
long-distance link, they would drop to a 2-bit ADPCM (running at 16 kbps).
I was testing with 16kHz 2-bit ADPCM, as while both 16kHz 2-bit and 8kHz
4-bit ADPCM are both 32 kbps, the 16kHz sounds better to me (and
intelligibility is higher).
Though, if spoken language is not used, it makes sense to drop to 8kHz.
Using 8kHz as standard is weak as intelligibility is a lot worse.
But, I guess the thinking was "minimum where you can still 'mostly' hear
what they are saying...".
Even if 8kHz was standard on the telephone network, I can't easily
understand what anyone is saying over the phone (speech is often very
muffled and there is often a loud/obnoxious hiss).
Actually, weirdly, actual phone quality is somehow *worse* than my
experiments with low bitrate ADPCM. Like, the low-bit depth ADPCM mostly
just sounds "gritty" (without any obvious hiss). Like, the phone adds
extra levels of badness beyond just any compression issues (probably
also crappy microphones and speakers, etc, as well).
Using headphones with a phone is "slightly" better, but there is often
still a rather loud/annoying hiss, even when the sound is coming from an
artificial source.
Poor quality ADPCM, by itself, does not have this particular issue
(actually, it almost seems as if the ADPCM somehow "enhances" the audio
and compensates slightly for the low sample rate, making details easier
to hear compared with "cleaner" PCM audio versions).
For sound-effects, could drop to 4kHz, but there is fairly significant
distortion. Like, if you have a notification ding, it doesn't really
sound like a bell anymore.
So, say (ADPCM modes):
16kHz 4-bit: Mostly Good, but needs 64 kbps.
16kHz 2-bit: Slightly muffled, gritty, 32 kbps.
8kHz 4-bit: More obvious muffling (but not gritty);
8kHz 2-bit: Muffled and gritty (16 kbps);
4kHz 4-bit: Serious muffle / distortion, 16 kbps.
4kHz 2-bit: Muffle + distortion + grit, 8 kbps.
Possible merit of 4kHz 2-bit is that it allows putting a bell sound
effect in around 500 bytes. Downside is that it is no longer
particularly recognizable as a bell (and goes more from "ding" to "plong").
At 4 kHz, speech is basically almost entirely unintelligible, but can
still hear that speech is present (its "shape" can still be heard; but
words are still recognizable; sort of like the muffling when people are
talking in a different room, but one can still hear that they are saying
"something").
At 2 kHz; it is barely recognizable as being speech (it sounds almost
more like wind). Percussive sounds are still recognizable though (so,
music is turned into "howling wind with drums").
Early 90s games (such as Doom) mostly used 11 kHz as standard.
IMHO, 16kHz is a better quality/space tradeoff.
Where, 22/32/44 can sound better, but may not be worth the overhead.
Sample rates above 44 kHz are overkill though.
I, personally, can't hear the difference between 44 and 48 kHz audio.
I suspect anything 48kHz and beyond is likely needless overkill.
>>
>> 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
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