Re: [Factor-talk] Disassembly

2018-01-17 Thread Alexander Ilin 
Hello, Björn! Thanks for the explanation! I've already lost hope of seeing a reply to that, but you appeared out of nowhere and saved the day. Thank you! Are you saying there was a different (better?) optimizer in the previous Factor releases? What happened to it? 17.01.2018, 22:25, "Björn Lindqvist" : r14 contains the datastack top pointer. It is incremented by 0x10 which is 16 bytes or 2 cells. Your code was supposed to put two items on the stack, but then the optimizer did a great job and noticed that the values didn't have to be put on the stack but could be kept in registers. But it didn't optimize away the stack increment/decrement. Possibly, the optimizer in 0.96 or 0.97 did a better job at optimizing code like that.  ---=---Александр --
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] Secure Memory

2018-01-17 Thread Alexander Ilin 
Doug and Björn, I'd like to point out the following use case for your consideration, and then you can tell me if the selective zeroing of sensitive memory buffers by the GC makes sense. Some sensitive data is stored in a networked application (let's say, a Web Server with its security certificates).The data in the application is surrounded with some `with-destructors` combinators that will clear it when it's no longer needed.But - the GC comes along and relocates the sensitive data in memory by copying it and not erasing it in the old place. The old location is marked as free memory. Now I assume that there is a way in Factor to allocate a `byte-array` without initializing the memory. This means that by requesting enough "free" memory from the runtime we will at some point get a hold of the block containing the released copy of the sensitive data. This is a problem, especially if our application is downloading and running scripts from the network, like, say, a Web Browser would do all the time. That combination of not clearing the memory on release and not clearing the memory on allocation (both expensive things to do if you do them all the time) creates the potential for the leakage.Adding a single bit flag that would tell GC to zero a particular object's memory on release (or reallocation) would be a great security feature, I think. Not a global command-line argument, but a per-object-instance flag.What do you think? Does it make sense? Is it difficult to implement? As to the Java finalizers argument - I'm not suggesting to rely on GC for the cleanup, as indeed it may never happen. I'd only want it not to leave old copies of some specific buffers hanging around when it's done its invisible (to the application code) magic. 17.01.2018, 22:40, "Doug Coleman" :We actually had a command-line argument to the vm to optionally zero the gc after collection but we removed the feature somewhere around when we dropped BSD support. It's probably better than nothing but if they could read your memory after a gc why not just read it before gc instead? Doug On Wed, Jan 17, 2018 at 1:34 PM Björn Lindqvist  wrote:Factor when run in debug mode actually clears memory. See bump_allocator.hpp. Unfortunately clearing memory is slow as hell. The time complexity of copying gc is proportional to the number of surviving objects. But if you want to clear memory too it becomes proportional to the total number of allocated objects.  Plus, relying on the gc to zero out sensitive memory is a bad idea. You never know when the gc runs or if it runs at all. That's why it is considered bad practice in Java to use finalizers. I think it would be better to use the destructors vocab to implement zeroing out of sensitive memory.     2018-01-16 23:17 GMT+01:00 Alexander Ilin :Hello!  I was reading a manual on the `8th` language, and noticed an interesting feature.  Apparently, it's possible to call a word on a memory buffer and thereby mark it as "sensitive information".  GC would zero the memory upon release.  Zeroing every bit of memory on release would add a lot of overhead (as I understand), but selectively clearing it like this could help with security applications that deal with certificates and passwords and stuff. This is especially useful, because in Factor GC can relocate (= copy) objects in memory. Does it clean up the memory it copied?  Do we have such a feature? Is it difficult to implement?  Bjourne, you've seen a lot of the runtime, can you comment?---=--- Александр--Check out the vibrant tech community on one of the world's mostengaging tech sites, Slashdot.org! http://sdm.link/slashdot___Factor-talk mailing listFactor-talk@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/factor-talk  --mvh/best regards Björn Lindqvist--Check out the vibrant tech community on one of the world's mostengaging tech sites, Slashdot.org! http://sdm.link/slashdot___Factor-talk mailing listFactor-talk@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/factor-talk,--Check out the vibrant tech community on one of the world's mostengaging tech sites, Slashdot.org! http://sdm.link/slashdot,___Factor-talk mailing listFactor-talk@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/factor-talk  ---=---Александр --
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Factor-talk mailing list

Re: [Factor-talk] Secure Memory

2018-01-17 Thread Doug Coleman 
We actually had a command-line argument to the vm to optionally zero the gc
after collection but we removed the feature somewhere around when we
dropped BSD support. It's probably better than nothing but if they could
read your memory after a gc why not just read it before gc instead?

Doug

On Wed, Jan 17, 2018 at 1:34 PM Björn Lindqvist  wrote:

> Factor when run in debug mode actually clears memory. See
> bump_allocator.hpp. Unfortunately clearing memory is slow as hell. The time
> complexity of copying gc is proportional to the number of surviving
> objects. But if you want to clear memory too it becomes proportional to the
> total number of allocated objects.
>
> Plus, relying on the gc to zero out sensitive memory is a bad idea. You
> never know when the gc runs or if it runs at all. That's why it is
> considered bad practice in Java to use finalizers. I think it would be
> better to use the destructors vocab to implement zeroing out of sensitive
> memory.
>
> 2018-01-16 23:17 GMT+01:00 Alexander Ilin :
>
>> Hello!
>>
>>   I was reading a manual on the `8th` language, and noticed an
>> interesting feature.
>>   Apparently, it's possible to call a word on a memory buffer and thereby
>> mark it as "sensitive information".
>>   GC would zero the memory upon release.
>>
>>   Zeroing every bit of memory on release would add a lot of overhead (as
>> I understand), but selectively clearing it like this could help with
>> security applications that deal with certificates and passwords and stuff.
>> This is especially useful, because in Factor GC can relocate (= copy)
>> objects in memory. Does it clean up the memory it copied?
>>
>>   Do we have such a feature? Is it difficult to implement?
>>   Bjourne, you've seen a lot of the runtime, can you comment?
>>
>> ---=---
>>  Александр
>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Factor-talk mailing list
>> Factor-talk@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/factor-talk
>>
>
>
>
> --
> mvh/best regards Björn Lindqvist
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] Secure Memory

2018-01-17 Thread Björn Lindqvist 
Factor when run in debug mode actually clears memory. See
bump_allocator.hpp. Unfortunately clearing memory is slow as hell. The time
complexity of copying gc is proportional to the number of surviving
objects. But if you want to clear memory too it becomes proportional to the
total number of allocated objects.

Plus, relying on the gc to zero out sensitive memory is a bad idea. You
never know when the gc runs or if it runs at all. That's why it is
considered bad practice in Java to use finalizers. I think it would be
better to use the destructors vocab to implement zeroing out of sensitive
memory.

2018-01-16 23:17 GMT+01:00 Alexander Ilin :

> Hello!
>
>   I was reading a manual on the `8th` language, and noticed an interesting
> feature.
>   Apparently, it's possible to call a word on a memory buffer and thereby
> mark it as "sensitive information".
>   GC would zero the memory upon release.
>
>   Zeroing every bit of memory on release would add a lot of overhead (as I
> understand), but selectively clearing it like this could help with security
> applications that deal with certificates and passwords and stuff. This is
> especially useful, because in Factor GC can relocate (= copy) objects in
> memory. Does it clean up the memory it copied?
>
>   Do we have such a feature? Is it difficult to implement?
>   Bjourne, you've seen a lot of the runtime, can you comment?
>
> ---=---
>  Александр
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>



-- 
mvh/best regards Björn Lindqvist
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] Disassembly

2018-01-17 Thread Björn Lindqvist 
The mov [rip-0x117cfdf], eax instruction is indeed peculiar. It actually is
polling a safe point. When ctrl-c is pressed, the running thread is ordered
to stop as quickly as possible. It can't just halt anywhere but must
continue to execute until it comes to a point where it is safe to halt -- a
safe point. Meanwhile, the VM has set the memory page at address rip-0x117cfdf
to write protected which makes it so the instruction triggers a page
fault.  You can see how it is handled in the memory_signal_handler_impl()
function in errors.cpp This page explains safe points in more detail:

http://psy-lob-saw.blogspot.se/2014/03/where-is-my-safepoint.html

r14 contains the datastack top pointer. It is incremented by 0x10 which is
16 bytes or 2 cells. Your code was supposed to put two items on the stack,
but then the optimizer did a great job and noticed that the values didn't
have to be put on the stack but could be kept in registers. But it didn't
optimize away the stack increment/decrement. Possibly, the optimizer in
0.96 or 0.97 did a better job at optimizing code like that.



2017-10-12 23:32 GMT+02:00 Alexander Ilin :

>
> Hello!
>
>   I'm trying to make sense of some disassembled code. Could someone help
> me out here?
>
> ```
> IN: scratchpad [ 256  [ drop ] each ] disassemble
> 001a8dbcdfc0: 89053a30e8fe  mov [rip-0x117cfc6], eax !
> What's this?
> 001a8dbcdfc6: b80001mov eax, 0x100
> 001a8dbcdfcb: 31db  xor ebx, ebx
> 001a8dbcdfcd: 4983c610  add r14, 0x10
> 001a8dbcdfd1: e90900jmp 0x1a8dbcdfdf (( gensym ) + 0x1f)
> 001a8dbcdfd6: 48ffc3inc rbx
> 001a8dbcdfd9: 89052130e8fe  mov [rip-0x117cfdf], eax !
> What's this?
> 001a8dbcdfdf: 4839c3cmp rbx, rax
> 001a8dbcdfe2: 0f8ceeff  jl dword 0x1a8dbcdfd6 (( gensym ) + 0x16)
> 001a8dbcdfe8: 4983ee10  sub r14, 0x10
> 001a8dbcdfec: 89050e30e8fe  mov [rip-0x117cff2], eax !
> What's this?
> 001a8dbcdff2: c3ret
> 001a8dbcdff3:   add [rax], al
> 001a8dbcdff5:   add [rax], al
> 001a8dbcdff7:   add [rax], al
> 001a8dbcdff9:   add [rax], al
> 001a8dbcdffb:   add [rax], al
> 001a8dbcdffd:   add [rax], al
> 001a8dbcdfff: 00invalid
> ```
>
>   The lines like `mov [rip-0x117cfdf], eax` I read as "copy the contents
> of the EAX register to a memory location pointed to by a memory address
> relative to the current Instruction Pointer register (rIP)". Am I right? If
> so, why is that being done inside the loop, and twice at the procedure
> entry and exit?
>
>   Also, why is the register r14 incremented by 0x10 on entry, and
> decremented on exit? What is r14 used for?
>
> ---=---
>  Александр
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>



-- 
mvh/best regards Björn Lindqvist
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] FUNCTION:

2018-01-17 Thread Björn Lindqvist 
You can use the dlsym? word: "func_name" "lib_name" dlsym? For functions in
user32.dll, I think you should use "func_name" f dlsym?

2017-08-23 12:25 GMT+02:00 Alexander Ilin :

>
> 23.08.2017, 05:14, "John Benediktsson" :
> > I'm not aware of any easy method. Maybe some other windows dev can
> comment. In macOS we check for the presence of a selector before calling.
> And in other places we version check before making an API call. Maybe that
> is what you need to do? If it's easy to determine what version ranges it
> was provided in.
>
>   OK, thanks for the reply.
>
> ---=---
>  Александр
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>



-- 
mvh/best regards Björn Lindqvist
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk