HCL - 4.3 alpha ASRock B850 Pro-A / Ryzen 7600 / RTX 3090

User Support HCL Reports
1 
---
layout:
  'hcl'
type:
  'Desktop'
hvm:
  'yes'
iommu:
  'yes'
slat:
  'yes'
tpm:
  '2.0'
remap:
  'yes'
brand: |
  ASRock
model: |
  B850 Pro-A
bios: |
  3.30
cpu: |
  AMD Ryzen 5 7600 6-Core Processor
cpu-short: |
  FIXME
chipset: |
  Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Root Complex [1022:14d8]
chipset-short: |
  FIXME
gpu: |
  NVIDIA Corporation GA102 [GeForce RTX 3090] [10de:2204] (rev a1) (prog-if 00 [VGA controller])
  Advanced Micro Devices, Inc. [AMD/ATI] Raphael [1002:164e] (rev c6) (prog-if 00 [VGA controller])
gpu-short: |
  FIXME
network: |
  Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller [10ec:8125] (rev 05)
memory: |
  97367
scsi: |

usb: |
  4
certified:
  'no'
versions:
  - works:
      'FIXME:yes|no|partial'
    qubes: |
      R4.3-alpha
    xen: |
      4.19.2
    kernel: |
      6.12.35-1
    remark: |
      FIXME
    credit: |
      FIXAUTHOR
    link: |
      FIXLINK

Remarks

Before beginning report, I always wanted to appreciate qubes developers passionately implementating new security measures, such as 1) new gui for ‘device assignments’ which is added recently and 2) disposable vm from standalonevm, ‘prohibit start’, and etc.

although i’m not 100% sure of the reason, while starting 4.3 alpha for the first time, i could hear inside the dorm that somebody shotguns the wall regardless what he felt, but regarding my continuous claim of the ‘physical monitoring’ along with constant cyberattacks from regulatory administration, the reason would be fairly obvious.

anyway, i had to workaround two things :

  1. clocksync problem always appears. and this is the reason why i had always failed to install new 4.3 alpha iso on my desktop(and laptop). also known as ‘libxenlight’ issue or ‘freeze in ‘setup networking’’, i had managed to run saltstack in order to configure my setup.
  2. this is critical, i had figured out why my iso keep ‘freezing’ after the first reboot, this is related to ‘plymouth.ignore-serial-consoles’ parameter in the dom0 side.

i’m not sure why. perhaps my adversarial actors had managed to inject unwanted code inside the ISO, or, maybe just the default configuration is not perfect enough, but i’m pretty sure of the fact that it’ll highly likely former one.

saying the reason, i’m now relying on mullvadvpn’s DAITA in order to mitigate bandwidth restriction(often caused by machine-learning packet inspection), alongside i2p. i’ve tried tor, but whonix and tor proxy(e.g. : orbot in android) alone are NOT ENOUGH for mitigating MITM attack and packet inspection. so i suppose since the ‘shotguns’ had stopped after i started dom0 update(yes, update has been not proceeding while i’m connecting to repo via whonix), i’m not sure whether my adminvm has been modified.

also, i’m trying to install anti-evil-maid with guides inside my qubes desktop, but since default configuration has encrypted each logical volume with LUKS, i’ve seen inside the anti-evil-maid docs that i have to encrypt full disk before installing anti evil maid

So, in conclusion, i’d love to see mitigation from network cyberattack - say MITM - or more options on anonymity such as sys-i2pd for dom0 update, and full LUKS disk encryption available, but i suppose it consumes way too much resource for developers - so i would like to see such things implemented in future.

Attachments

Qubes-HCL-ASRock-B850-Pro-A.yml (936 Bytes)

1 Like