asus n56vz HCL update

71 views
Skip to first unread message

Oleg Artemiev

unread,
Feb 20, 2017, 8:59:33 PM2/20/17
to qubes...@googlegroups.com
------------------------------------------
Qubes release 3.2 (R3.2)

Brand: ASUSTeK COMPUTER INC.
Model: N56VZ
BIOS: XXXXX

Xen: 4.6.1
Kernel: 4.4.14-11

RAM: 16 Gigabytes

CPU:
Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz
Chipset:
Intel Corporation 3rd Gen Core processor DRAM Controller [XXXX:XXXX] (rev XX)
VGA:
Intel Corporation 3rd Gen Core processor Graphics Controller
[XXXX:XXXX] (rev XX) (prog-if XX [VGA controller])
NVIDIA Corporation XXXXXX [GeForce GT 650M] [XXXX:XXX] (rev XX)
(prog-if XX [VGA controller])

Net:
Intel Corporation Centrino Wireless-N XXXX (rev XX)
Qualcomm Atheros AR8161 Gigabit Ethernet (rev XX)

SCSI:
STXXXXXXXXX XXXXX Rev: XXXXX - 1 terabyte

HVM: Active
I/O MMU: Not active
HAP/SLAT: Yes
TPM: Device not found
------------------------------------------


works - yes, but no VT-d, still worse linux driver for build in NIC;

thanks for a good work to Qubes team - Qubes 3.2 is much better
from user experience. :)

Attached file has more details. As usually I've replaced some
potentially unique numbers w/ XXXXXX.


--
Bye.Olli.
gpg --search-keys grey_olli , use key w/ fingerprint below:
Key fingerprint = 9901 6808 768C 8B89 544C 9BE0 49F9 5A46 2B98 147E
Blog keys (the blog is mostly in Russian): http://grey-olli.livejournal.com/tag/
Qubes-HCL-ASUSTeK_COMPUTER_INC_-N56VZ-20170220-202310.yml

Zrubi

unread,
Feb 21, 2017, 3:34:53 AM2/21/17
to Oleg Artemiev, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/21/2017 02:59 AM, Oleg Artemiev wrote:

> Attached file has more details. As usually I've replaced some
> potentially unique numbers w/ XXXXXX.
>

FYI:


The things you are hiding are NOT unique to your device. Instead they
are the exact device TYPE identifiers. Without those you can't even
tell what device you are using. Means without those ids the HCL is
pretty useless.


Details:

BIOS: what you are masked is the BIOS version.
Different BIOS versions may affect some very important things like
vt-d, vt-x, TMP

VGA: you masked the PCI ID. It is the only real identification of the
device:
http://pci-ids.ucw.cz/

NET: same as above. Without the proper masked ID you are not even able
to cheese the right driver.

SCSI: same again the masked id is the type number of your disk.
However this is actually not relevant in Qubes.


Of course you can still decide to not share those - it is up to you.
I just wanted to make it clear to avoid confusion.


- --
Zrubi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJYq/udAAoJEH7adOMCkunmJscP/3dk1W+v+hwen9YWGVrbK/kC
Xuy8OZqE+bbYVG3p8LMFvBW1BdaMbW5WJAU96t7/BtvOetmYmocfc0stvefrxTHz
sMAHWV+/Xl2g7KGqO8k8QffU4mZHfOT/kb9k79yP2iPPztWmDHD0kmHW1i5h2J4U
4acNs0I+a0NRjoNaQAnHVwr4gva0g083Djhndw7rNGuIvrVmOu6qyscXJ/QaXhNV
I1kwqSMRzcOO0CBAP9buhK2XLcoXC/CLjgZyzZpznibr1rtI/E+xc8rgtCBXnmvr
Zdy+L78F5DYYdxBfREQuvVR96AuheXprLXW26cwNUv10/JEqYvm24MPEZSzhdhM3
qqv9pWril+M8FvxAWH3h9PssK26rHKveUGEiF5mfXHam3SX4J153E69TTY20N2mx
73Lig13e6I8269cs9Xby8pX222fAT8vE5wdw9+iVnloLiXjaLwikcp7x4eyBRjho
y8wCQTdsxR6X6ds2UeKDD/+qCaIr/lIkFcJhzZ7SfkOXniGj/BjaoqHNu79eknS/
FPFq89jp7GOlIE6XldT6k7gWHEzRYKTTRVebUkvhh2OzbgfbsCzlHm7MYyAmEytA
0m4ehah2byAvsRIV8JQJ5xgD1AKDyOt7Hfb6R8xpjvO2DXnhEjnOplOz6SRmXiQq
DaiaIo1o7sdJDftriIcO
=RnoV
-----END PGP SIGNATURE-----

Oleg Artemiev

unread,
Feb 22, 2017, 12:32:15 AM2/22/17
to Zrubi, qubes...@googlegroups.com
On Tue, Feb 21, 2017 at 3:34 AM, Zrubi <ma...@zrubi.hu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 02/21/2017 02:59 AM, Oleg Artemiev wrote:
>
>> Attached file has more details. As usually I've replaced some
>> potentially unique numbers w/ XXXXXX.
> FYI:
>
>
> The things you are hiding are NOT unique to your device. Instead they
> are the exact device TYPE identifiers. Without those you can't even
> tell what device you are using. Means without those ids the HCL is
> pretty useless.
> Details:
>
> BIOS: what you are masked is the BIOS version.
> Different BIOS versions may affect some very important things like
> vt-d, vt-x, TMP
in my case chipset doesn't support it, not bios, thus no need to publish this.
(this information is available via link on dicscussion that realtes to
my old report, nothing has changed).

> VGA: you masked the PCI ID. It is the only real identification of the
> device:
> http://pci-ids.ucw.cz/
> NET: same as above. Without the proper masked ID you are not even able
> to cheese the right driver.
> SCSI: same again the masked id is the type number of your disk.
Any of these as a single entry are not identifying.

Combination of those could be enough to split target set from
thousands to single hundred .

That is not exact identify for law enforcement, but enough
identification for targeted attack in "spotter" terms .
At least combining that data razes ease of targeting a single computer
from distribution center.
That is enough reason for me not to post this information even when I
trust Qubes team.

> However this is actually not relevant in Qubes.
Why then this is sent to HCL? Shouldn't we avoid unnecessary
information like HDD details at all (or
just ask for amount of free space (approximate, not exact, as exact
value on system partition may
help identify install) on assigned partitions)?

> Of course you can still decide to not share those - it is up to you.
Yes, I still do - see 'my reasons' below.

> I just wanted to make it clear to avoid confusion.
Thank you.I'll look for details on identification of devices w/ PCI ID.

As about my reasons:

There's difference between identification of a person from:

*) vendor site (any vendor that has made some software ether running
on my laptop)
*) from some government agency like fbi/nsa/fsb/whatever
*) from abilities that give just internet search for any curious hacker.

It's not a big deal to publish that info, since I trust Qubes team and
think I'm not that interesting person to spend time catching my
personal data - that is
probably useless for most of other people .

Though I do not trust Microsoft, but I use their OS for gaming. I do
not trust Google but I use a few android devices. I do not trust lots
of other non-evil-by-intent organizations.
Why? Lets imagine, that once, I become a person to catch by whatever
reason. Then what?

Then any information that I 've sent to the net is ready to use,
stored for the hunter pleasure and I cannot erase anything that once
has been sent to the net . Period.

I see no reason to allow technical reports w/ my personal hardware
details to any vendor (including Qubes) - all vendors usually operate
on more info than them
really need. HDD information sent via HCL seem to be useless to
decide "is this laptop good enough to be able to Qubes?" Why not to
remove it?

We have a proverbial in Russia - "word is not a bird - once flew - no
chance to catch". Information you reveal into public should be
organized correctly independently to their
current importance level ,

My idea is that if Qubes team wants to get additional information from
users about spare parts - the HCL should get divided by at least two
parts:

1) laptop model compatibility list (w/ less information about details
(I guess within one model the hardware set is similar)).

2) hardware compatibility list w/ spare part list.

I.e. if we want to know about some laptop model - one case, if we
want to get a list of compatible boards, network adapters, etc. -
another case.

And very important - the second case is subject for anonymization -
it should be hard to make a direct link between an exact spare part
and a user reported it.
Better even have in HCL a FIXME "Yes I'm okay for public link between
my person and data from this report". If this is not what a user want
- publish report anonymously.
BTW, I'm okay for current link from HCL page to a thread - anyone can
get my email and find out what a crappy hardware I use. ;)

Currently reporter is directly pointed via link to google group
discussion (if he/she agreed on that).

I'm okay to send more details on my hardware once I'm sure:

*) details are not easily traceable to my one laptop from

*) reporter is not easily traceable from reported entry by vendor

Zrubi

unread,
Feb 22, 2017, 3:29:47 AM2/22/17
to Oleg Artemiev, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/22/2017 06:32 AM, Oleg Artemiev wrote:
> On Tue, Feb 21, 2017 at 3:34 AM, Zrubi <ma...@zrubi.hu> wrote:

>> Of course you can still decide to not share those - it is up to
>> you.
> Yes, I still do - see 'my reasons' below.

There is no argue against this decision for sure.



> My idea is that if Qubes team wants to get additional information
> from users about spare parts - the HCL should get divided by at
> least two parts:
>
> 1) laptop model compatibility list (w/ less information about
> details (I guess within one model the hardware set is similar)).

Unfortunately this is not the case in reality.

All the manufacturers are releasing completely different hardware with
the same model name.

I was working closely with several vendors before, so I have some bad
real life experience with this.

So I'm still stating that without exact spare part list, the HCL has
not even worth the effort to collect and publish.


About anonymity:

It is your choice again. But that choice should be done before even
posting anything on these lists :)

The reason behind the current manual and voluntary HCL info gathering
is to give you the choice. If you send any data or not, if you using
your real name or not.


- --
Zrubi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJYrUvtAAoJEH7adOMCkunmjl0P/3Xo3PiB0JxhbjdWpS0G5QIo
aAxX2TCc0/zRW7U3WsUL18CPPXUQGsQtaxcaz90QRnAwI5UVNFRUw9LvVUBkaBmK
g0JpzHVTRub6pOb8Bu79HSVVtI7YRokoIjQ50xykvQyh3QhQNDWUzd3v3nl33QD7
n7DTzFsCwH83KJ1rWUPHME2e2TFozbaaxwFId30fCL3RwwPgkxCmcwcBOf3dpX8c
AZZkYkPEUKvPtwb5DL5XX7JPwWwxW8vbNoKMkeexWT7qmW3XjfXxvDVTVx14r5Lw
VdKcu9W9Wfn9lEuWIHgipyG4VmaU3jSHkf9s5g1RFX3ht8DF+nQqF60V/Dnk3QCl
QKhrqnnKAAZ8cXwgHdUc0vomdAR5OW3igEUWqPAlMLd3Rg7cUrQotAI5nd+GDDh6
t5fkBO/LZ0gEGSedH6O22/S87PzO6Fbj1N9ex2ojKgSLvhnv3TMwS1mYbb/5bsJP
dJVxNPkiC6QiSSWd2JF0FwIrlTUX0hwInVeq6s8PmnZmrdtmMj/X7DOzIWL7E1E1
GcBrbKVDk9iccAIkkB8/YWdn2tIY7TEUz3IeWU0iYppDX+ZjVaUkmjNKttMJcL2P
SK5tt1MuXRrbvENqNBFhdo0Bj6S+cS2RX63+We0Qq0xeYYPHPfg2oR/GvShMgh26
LtbNRIP/hEDjgVZ+jEVk
=/cH0
-----END PGP SIGNATURE-----

Chris Laprise

unread,
Feb 22, 2017, 12:33:11 PM2/22/17
to Zrubi, Oleg Artemiev, qubes...@googlegroups.com
On 02/22/2017 03:29 AM, Zrubi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 02/22/2017 06:32 AM, Oleg Artemiev wrote:
>> On Tue, Feb 21, 2017 at 3:34 AM, Zrubi <ma...@zrubi.hu> wrote:
>>> Of course you can still decide to not share those - it is up to
>>> you.
>> Yes, I still do - see 'my reasons' below.
> There is no argue against this decision for sure.
>
>
>
>> My idea is that if Qubes team wants to get additional information
>> from users about spare parts - the HCL should get divided by at
>> least two parts:
>>
>> 1) laptop model compatibility list (w/ less information about
>> details (I guess within one model the hardware set is similar)).
> Unfortunately this is not the case in reality.
>
> All the manufacturers are releasing completely different hardware with
> the same model name.
>

Since this is an update of his Qubes R2 report already in the HCL, I
have enough info to include it for R3.2. I have the CPU model (from the
body of Oleg's first message), the chipset model, graphics, etc. But I
agree the report file itself should have included a bare minimum with
the CPU.

Chris

Oleg Artemiev

unread,
Feb 22, 2017, 6:15:30 PM2/22/17
to Zrubi, qubes...@googlegroups.com
On Wed, Feb 22, 2017 at 3:29 AM, Zrubi <ma...@zrubi.hu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>> My idea is that if Qubes team wants to get additional information
>> from users about spare parts - the HCL should get divided by at
>> least two parts:
>> 1) laptop model compatibility list (w/ less information about
>> details (I guess within one model the hardware set is similar)).
> Unfortunately this is not the case in reality.
>
> All the manufacturers are releasing completely different hardware with
> the same model name.
>
> I was working closely with several vendors before, so I have some bad
> real life experience with this.
:(


Okay, but what for should HCL contain info about HDD details?
Ever anyone had problem w/ disk firmware w/ fedora?

From my understanding, disk stuff is below sata driver - once fedora under Xen
works w/ sata for some chipset - the HDD shouldn't be a problem - isn't it?

> So I'm still stating that without exact spare part list, the HCL has
> not even worth the effort to collect and publish.
You mean that single device information w/o other parts is not
interested at all and second idea - ability to anonymously report
spare parts
is useless?

> About anonymity:
>
> It is your choice again. But that choice should be done before even
> posting anything on these lists :)
Agree. I'm not hiding that much as I should. )

> The reason behind the current manual and voluntary HCL info gathering
> is to give you the choice. If you send any data or not, if you using
> your real name or not.
Yep, I voluntary agreed to publish this hardware a few years before
using my real name. =)
I don't keep any interesting secrects on a notebook that I use in dual
boot configuration.
At least I think so )

Oleg Artemiev

unread,
Feb 22, 2017, 6:15:38 PM2/22/17
to Chris Laprise, Zrubi, qubes...@googlegroups.com
On Wed, Feb 22, 2017 at 12:32 PM, Chris Laprise <tas...@openmailbox.org> wrote:

> Since this is an update of his Qubes R2 report already in the HCL, I have
> enough info to include it for R3.2. I have the CPU model (from the body of
> Oleg's first message), the chipset model, graphics, etc.
Okay, please do.

I don't remember exactly what I've already revealed about this peace
of [cansored] that doesn't support VT-d. =)
Next time when I'll decide to spend 1-2k$ for a laptop I'll look
closer to Qubes requirements - last time I just bought and found it's
not what I need half year later when got time to switch to Qubes.
(very nice that usb stick option is available out of the box). Got a
look into 4.0 hardware requirement - found that I have to buy a laptop
when when 4.0 will appear in downloads.

The only things changed since last report - I probably got either end
of life for my ssd drive after last full rewrite or tools unaware
about SSD made it report so strange things to dumb UEFI, that it
disabled the primary sata channel. (to get a clue I need to check both
alternatives: *) boot into windows and try to check w/ proprietary
software *) check it in some other PC that has no stupid EFI bios
pretending to be clever when I don't want it to)

> But I agree the report file itself should have included a bare minimum with the CPU.
I vote for an option to show HCL info in 2 or 3 variants by user option:

1) as it is now with all details
2) with minumum requirement: model name, cpu info, chipset info, bios
version, built in video info - all w/o exact IDs, no other info
3) just CPU, motherboard, bios information.

And also I think, that ability to send _anonymous_ data about all
parts w/ user only confirmation required is good thing. When
anonymising report I'd stress on the following:
*) send via .onion service w/o full unique identificators (optionally
use crypto via temporary created at install time keys (and deleted
right after encryption finished))
*) send one by one each hardware detail w/ random timeout within 24-96
hours(not within one hour!) to a fully automated receiver at vendor
site (continue if rebooted before sending finished)

Zrubi noted 2) and 3) as mostly useless, IIUC .
Reply all
Reply to author
Forward
0 new messages