diff options
Diffstat (limited to 'ollama')
| -rwxr-xr-x | ollama/llm.py | 28 | ||||
| -rw-r--r-- | ollama/mail | 184 | ||||
| -rw-r--r-- | ollama/preambel | 62 | ||||
| -rw-r--r-- | ollama/requirements.txt | 1 | ||||
| -rw-r--r-- | ollama/response | 5 | ||||
| -rw-r--r-- | ollama/shell.nix | 7 |
6 files changed, 0 insertions, 287 deletions
diff --git a/ollama/llm.py b/ollama/llm.py deleted file mode 100755 index d6ea059c..00000000 --- a/ollama/llm.py +++ /dev/null @@ -1,28 +0,0 @@ -from ollama import chat, ChatResponse -from re import sub -from os import listdir, path - -model : str = "deepseek-r1:70b" -directory : str = "../results/scraper/mailinglist" - -with open("preambel", "r") as file: - preambel = file.read() - -for name in listdir(directory): - with open(path.join(directory, name)) as file: - content = preambel + "\n" + file.read() - - response : ChatResponse = chat( - model=model, messages=[ - { - 'role': 'user', - 'content': content, - } - ] - ) - - no_think_response : str = sub(r'<think>(.|\n)*</think>\n\n', '', response.message.content) - - print(no_think_response) - print("\n") - exit() diff --git a/ollama/mail b/ollama/mail deleted file mode 100644 index 6a329756..00000000 --- a/ollama/mail +++ /dev/null @@ -1,184 +0,0 @@ -We have this gitlab issue for the project qemu. This is a semantic mistranslation bug: ----- -x86 BLSMSK semantic bug -Host environment - -Operating system: Windows 10 20H2 -OS/kernel version: WSL2 Ubuntu 20.04.4 LTS (GNU/Linux 5.10.102.1-microsoft-standard-WSL2 x86_64) -Architecture: x86 -QEMU flavor: qemu-x86_64 -QEMU version: 7.1.90 (v7.2.0-rc0) -QEMU command line: qemu-x86_64 -cpu max a.out - -Emulated/Virtualized environment - -Operating system: None -OS/kernel version: None -Architecture: x86 - -Description of problem -The result of instruction BLSMSK is different with from the CPU. The value of CF is different. - -Steps to reproduce - -Compile this code - -void main() { - asm("mov rax, 0x65b2e276ad27c67"); - asm("mov rbx, 0x62f34955226b2b5d"); - asm("blsmsk eax, ebx"); -} - -Execute and compare the result with the CPU. -CPU CF = 0 -QEMU CF = 1 ----- - -This issue results in the following toml file: ----- -id = 1371 -title = "x86 BLSMSK semantic bug" -state = "closed" -created_at = "2022-12-16T06:43:29.794Z" -closed_at = "2023-03-01T01:08:38.844Z" -url = "https://gitlab.com/qemu-project/qemu/-/issues/1371" -host-os = "Windows 10 20H2" -host-arch = "x86" -qemu-version = "7.1.90 (v7.2.0-rc0)" -guest-os = "None" -guest-arch = "x86" -description = """The result of instruction BLSMSK is different with from the CPU. The value of CF is different.""" -reproducer = """ -void main() { - asm("mov rax, 0x65b2e276ad27c67"); - asm("mov rbx, 0x62f34955226b2b5d"); - asm("blsmsk eax, ebx"); -} -""" -additional = "n/a" -semantic_bug = "yes" ----- - -For the following mails you have to give me a toml file with the variables 'title, state, created_at, closed_at, host-os, host-arch, qemu-version, guest-os, guest-arch, description, reproducer, semantic_bug'. 'semantic_bug' can either be "yes" or "no". If the information for one variable is not provided, set it to "n/a". Output only the toml without reasoning: ----- -[Bug] x86 EFLAGS refresh is not happening correctly - -Hello, -I'm posting this here instead of opening an issue as it is not clear to me if this is a bug or not. -The issue is located in function "cpu_compute_eflags" in target/i386/cpu.h -( -https://gitlab.com/qemu-project/qemu/-/blob/master/target/i386/cpu.h#L2071 -) -This function is exectued in an out of cpu loop context. -It is used to synchronize TCG internal eflags registers (CC_OP, CC_SRC, etc...) with the CPU eflags field upon loop exit. -It does: -  eflags -|= -cpu_cc_compute_all -( -env -, -CC_OP -) -| -( -env --> -df -& -DF_MASK -); -Shouldn't it be: -   -eflags -= -cpu_cc_compute_all -( -env -, -CC_OP -) -| -( -env --> -df -& -DF_MASK -); -as eflags is entirely reevaluated by "cpu_cc_compute_all" ? -Thanks, -Kind regards, -Stevie - -On 05/08/21 11:51, Stevie Lavern wrote: -Shouldn't it be: -eflags = cpu_cc_compute_all(env, CC_OP) | (env->df & DF_MASK); -as eflags is entirely reevaluated by "cpu_cc_compute_all" ? -No, both are wrong. env->eflags contains flags other than the -arithmetic flags (OF/SF/ZF/AF/PF/CF) and those have to be preserved. -The right code is in helper_read_eflags. You can move it into -cpu_compute_eflags, and make helper_read_eflags use it. -Paolo - -On 05/08/21 13:24, Paolo Bonzini wrote: -On 05/08/21 11:51, Stevie Lavern wrote: -Shouldn't it be: -eflags = cpu_cc_compute_all(env, CC_OP) | (env->df & DF_MASK); -as eflags is entirely reevaluated by "cpu_cc_compute_all" ? -No, both are wrong. env->eflags contains flags other than the -arithmetic flags (OF/SF/ZF/AF/PF/CF) and those have to be preserved. -The right code is in helper_read_eflags. You can move it into -cpu_compute_eflags, and make helper_read_eflags use it. -Ah, actually the two are really the same, the TF/VM bits do not apply to -cpu_compute_eflags so it's correct. -What seems wrong is migration of the EFLAGS register. There should be -code in cpu_pre_save and cpu_post_load to special-case it and setup -CC_DST/CC_OP as done in cpu_load_eflags. -Also, cpu_load_eflags should assert that update_mask does not include -any of the arithmetic flags. -Paolo - -Thank for your reply! -It's still a bit cryptic for me. -I think i need to precise that I'm using a x86_64 custom user-mode,base on linux user-mode, that i'm developing (unfortunately i cannot share the code) with modifications in the translation loop (I've added cpu loop exits on specific instructions which are not control flow instructions). -If my understanding is correct, in the user-mode case 'cpu_compute_eflags' is called directly by 'x86_cpu_exec_exit' with the intention of synchronizing the CPU env->eflags field with its real value (represented by the CC_* fields). -I'm not sure how 'cpu_pre_save' and 'cpu_post_load' are involved in this case. - -As you said in your first email, 'helper_read_eflags' seems to be the correct way to go. -Here is some detail about my current experimentation/understanding of this "issue": -With the current implementation -     -eflags |= cpu_cc_compute_all(env, CC_OP) | (env->df & DF_MASK); -if I exit the loop with a CC_OP different from CC_OP_EFLAGS, I found that the resulting env->eflags may be invalid. -In my test case, the loop was exiting with eflags = 0x44 and CC_OP = CC_OP_SUBL with CC_DST=1, CC_SRC=258, CC_SRC2=0. -While 'cpu_cc_compute_all' computes the correct flags (ZF:0, PF:0), the result will still be 0x44 (ZF:1, PF:1) due to the 'or' operation, thus leading to an incorrect eflags value loaded into the CPU env. -In my case, after loop reentry, it led to an invalid branch to be taken. -Thanks for your time! -Regards -Stevie - -On Thu, Aug 5, 2021 at 1:33 PM Paolo Bonzini < -pbonzini@redhat.com -> wrote: -On 05/08/21 13:24, Paolo Bonzini wrote: -> On 05/08/21 11:51, Stevie Lavern wrote: ->> ->> Shouldn't it be: ->> eflags = cpu_cc_compute_all(env, CC_OP) | (env->df & DF_MASK); ->> as eflags is entirely reevaluated by "cpu_cc_compute_all" ? -> -> No, both are wrong. env->eflags contains flags other than the -> arithmetic flags (OF/SF/ZF/AF/PF/CF) and those have to be preserved. -> -> The right code is in helper_read_eflags. You can move it into -> cpu_compute_eflags, and make helper_read_eflags use it. -Ah, actually the two are really the same, the TF/VM bits do not apply to -cpu_compute_eflags so it's correct. -What seems wrong is migration of the EFLAGS register. There should be -code in cpu_pre_save and cpu_post_load to special-case it and setup -CC_DST/CC_OP as done in cpu_load_eflags. -Also, cpu_load_eflags should assert that update_mask does not include -any of the arithmetic flags. -Paolo ----- diff --git a/ollama/preambel b/ollama/preambel deleted file mode 100644 index d2d498f2..00000000 --- a/ollama/preambel +++ /dev/null @@ -1,62 +0,0 @@ -We have this gitlab issue for the project qemu. This is a semantic mistranslation bug: ----- -x86 BLSMSK semantic bug -Host environment - -Operating system: Windows 10 20H2 -OS/kernel version: WSL2 Ubuntu 20.04.4 LTS (GNU/Linux 5.10.102.1-microsoft-standard-WSL2 x86_64) -Architecture: x86 -QEMU flavor: qemu-x86_64 -QEMU version: 7.1.90 (v7.2.0-rc0) -QEMU command line: qemu-x86_64 -cpu max a.out - -Emulated/Virtualized environment - -Operating system: None -OS/kernel version: None -Architecture: x86 - -Description of problem -The result of instruction BLSMSK is different with from the CPU. The value of CF is different. - -Steps to reproduce - -Compile this code - -void main() { - asm("mov rax, 0x65b2e276ad27c67"); - asm("mov rbx, 0x62f34955226b2b5d"); - asm("blsmsk eax, ebx"); -} - -Execute and compare the result with the CPU. -CPU CF = 0 -QEMU CF = 1 ----- - -This issue results in the following toml: ----- -id = 1371 -title = "x86 BLSMSK semantic bug" -state = "closed" -created_at = "2022-12-16T06:43:29.794Z" -closed_at = "2023-03-01T01:08:38.844Z" -url = "https://gitlab.com/qemu-project/qemu/-/issues/1371" -host-os = "Windows 10 20H2" -host-arch = "x86" -qemu-version = "7.1.90 (v7.2.0-rc0)" -guest-os = "None" -guest-arch = "x86" -description = """The result of instruction BLSMSK is different with from the CPU. The value of CF is different.""" -reproducer = """ -void main() { - asm("mov rax, 0x65b2e276ad27c67"); - asm("mov rbx, 0x62f34955226b2b5d"); - asm("blsmsk eax, ebx"); -} -""" -additional = """This bug is discovered by research conducted by KAIST SoftSec.""" -semantic = "yes" ----- - -For the following mailing thread, output only a toml with the corresponding variables. If an information cannot be gathered, put "n/a" instead. But you have to determine, if it is a semantic bug or not: diff --git a/ollama/requirements.txt b/ollama/requirements.txt deleted file mode 100644 index 403abba6..00000000 --- a/ollama/requirements.txt +++ /dev/null @@ -1 +0,0 @@ -ollama diff --git a/ollama/response b/ollama/response deleted file mode 100644 index 6ea789a4..00000000 --- a/ollama/response +++ /dev/null @@ -1,5 +0,0 @@ -The mailing list thread describes an issue where the EFLAGS register isn't correctly updated when exiting the translation loop in QEMU. This leads to incorrect values for flags like ZF and PF, affecting program execution. - -**Answer:** - -Yes, this is a semantic bug because it causes incorrect CPU state handling, leading to deviations in program behavior such as invalid branches. diff --git a/ollama/shell.nix b/ollama/shell.nix deleted file mode 100644 index e052a86d..00000000 --- a/ollama/shell.nix +++ /dev/null @@ -1,7 +0,0 @@ -{ pkgs ? (import <nixpkgs> {}).pkgs }: -with pkgs; -mkShell { - buildInputs = [ - python312Packages.ollama - ]; -} |